- Wine-Devel - list.winehq.org

Re: Shell32: fix DllGetVersion for newer callers
by Robert Shearman Sept. 15, 2004

Sept. 15, 2004

Juan Lang wrote: >A bit better than my last version, load the version >resource from the file for DllGetVersion, and update >the version of the file to produce the same output as >before. > >ChangeLog: add support for DLLVERSIONINFO2 in >DllGetVersion, and get version info from file > >--Juan > > ... >--- dlls/shell32/Makefile.in 11 Aug 2004 23:59:07 -0000 1.84 >+++ dlls/shell32/Makefile.in 14 Sep 2004 17:16:37 -0000 >@@ -4,7 +4,7 @@ > SRCDIR = @srcdir@ > VPATH = @srcdir@ > MODULE = shell32.dll >-IMPORTS = shlwapi comctl32 user32 gdi32 advapi32 kernel32 >+IMPORTS = shlwapi comctl32 user32 gdi32 advapi32 kernel32 version > DELAYIMPORTS = ole32 > EXTRALIBS = -luuid $(LIBUNICODE) > This is *really* ugly. Create a header file with just the version numbers defined and import it from the resource file and the file that implements the DllGetVersion function and problem solved. Rob

2 2

IUnknown_Release_Proxy leading to exception
by James Hawkins Sept. 15, 2004

Sept. 15, 2004

This is the final debug output when I run ICQ: wine: Unhandled exception (thread 0023), starting debugger... fixme:console:SetConsoleCtrlHandler (0x405fbab0,1) - no error checking or testing yet WineDbg starting on pid 0x24 Unhandled exception: page fault on read access to 0x00000000 in 32-bit code (0x40ab8695). In 32 bit mode. q0x40ab8695 IUnknown_Release_Proxy [/home/truiken/wine/dlls/rpcrt4/cproxy.c:330] in rpcrt4: movl 0x0(%eax),%edx 330 return IUnknown_Release(This->pUnkOuter); 330 return IUnknown_Release(This->pUnkOuter); Wine-dbg>l syntax error Wine-dbg>list 330 return IUnknown_Release(This->pUnkOuter); 331 #endif 332 } 333 in reading the comments, the interface refcounting is commented out and object refcounting is what is being used. i added a refCount variable to cproxy.c and did refCount++ and refCount-- in IUnknown_Release_Proxy and IUnknown_AddRef_Proxy with additional trace statements that show the value of refCount. right before the exception, a trace shows refCount to be -1. This is the log of trace+relay,ole: 045:Call kernel32.InterlockedDecrement(41277154) ret=00405614 0045:Ret kernel32.InterlockedDecrement() retval=0000000b ret=00405614 0045:Call kernel32.InterlockedDecrement(00637d80) ret=0040561b 0045:Ret kernel32.InterlockedDecrement() retval=00000042 ret=0040561b trace:ole:ObjectStubless (0x4311b3c4)->(5)([4 bytes]) ret=143db323 fixme:ole:RPCRT4_NdrClientCall2 (pStubDec == ^0x2476aa98,pFormat = ^0x2476a626,...): stub 0045:Call rpcrt4.IUnknown_Release_Proxy(4311b3c4) ret=00484779 trace:ole:IUnknown_Release_Proxy refCount: -1 trace:ole:IUnknown_Release_Proxy (0x4311b3c0)->Release() MIBDBCovnert 0045:Call kernel32.UnhandledExceptionFilter(406cdd6c) ret=4090f2b8 Any thoughts? -- James Hawkins

3 2

wine / dlls / itss / itss.c -> ICOM_THIS() macro is defined where ?
by Belxjander Serechai Sept. 15, 2004

Sept. 15, 2004

I have currently for the last several days been attempting to update my local installation of wine and found that I get blocked by this... Apparently where this macro is used causes errors, is this a possible regression or something was missed at somepoint? Thanks in advance, Jeremy

2 1

include/wine/port.h and socklen_t breakage
by Gerald Pfeifer Sept. 15, 2004

Sept. 15, 2004

The following change to include/wine/port.h revision 1.58 date: 2004/09/03 18:30:28; author: julliard; state: Exp; lines: +3 -0 Added configure check for socklen_t. +#ifndef HAVE_SOCKLEN_T +typedef unsigned int socklen_t; +#endif causes the following build failure on an old version of FreeBSD 5.1, and probably other systems as well. gmake[1]: Entering directory `/home/gerald/wine/loader' /usr/bin/gcc -c -I. -I. -I../include -I../include -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o kthread.o kthread.c In file included from kthread.c:41: /usr/include/sys/socket.h:77: error: redefinition of `socklen_t' ../include/wine/port.h:65: error: `socklen_t' previously declared here gmake[1]: *** [kthread.o] Error 1 The issue here is that socklen_t is defined in /usr/include/sys/socket.h, but ac_include_default in the configure script does not contain this dir. Which means that HAVE_SOCKLEN_T will be undefined, but once you include /usr/include/sys/socket.h, you'll get the conflict with our port.h. Gerald

1 0

Directx9
by Ann and Jason Edmeades Sept. 15, 2004

Sept. 15, 2004

Hello, I've spoken with the wine-d3d people and noone is currently doing anything on directx9 support. Originally Raphael was trying to merge things into a new library, wined3d, using an interface which ddraw could also use. This has not happened, and as we stand there is no progress being made. Now, I know nothing about d3d9 support - I have started to see what would be the easiest way to implement this, and have come up with a couple of options, and am after some advice.... 1. (My preference) d3d8 and d3d9 are very similar in lots of respects. I would like to move all the GL code into the wined3d library, effectively factorizing d3d8 and d3d9. However, this would mean extra function call overhead for dx8 and I really dont know how common they will be. Obviously d3d8 will change during such a transition 2. I could implement d3d9 from scratch. This would have the advantage of being a standalone library and wont affect d3d8, but a disadvantage of having to fix anything twice, and probably they will get out of sync really quickly. Also, d3d8 still has parts missing, and I'd prefer a single implementation if possible. If we did this, wined3d could be deleted and a huge code duplication would be required (or 3.... Do nothing, and see if anyone else takes up the gauntlet.) Now, I am not a 3d graphics programmer - I learnt d3d8 as I implemented it (for wine) out of interest to see how things were done. I am happy to try to do the same for d3d9, and would prefer approach (1). I have a few concerns though - Mostly I havent done enough research to know if its possible, and I may end up having a shared library with 2 implementations anyway... I havent found any major stumbling block yet, but I havent researched it far enough either. My other concern is if I start doing it and have to give up due to work or other pressures, I could leave a half migrated setup. I assume its relavitevly easy with cvs to back out changes if this occurs, and I hope it wont, but it is a concern. I'd appreciate thoughts before I start (especially Lionels, AJ's etc) - I'm only just getting back into wine programming again hence my interest. Jason

9 16

Re: Re: Directx9
by brettholcomb＠charter.net Sept. 14, 2004

Sept. 14, 2004

You're right - even MS can't do it - witness SP 2 for XP <G>. The important apps are core apps - Office, IE, etc., some of the more important apps like the big name games - Half Life <G>. However, it would be nice to know that if I'm running stable release xyz and I upgrade to stable xyz + 1 the apps it would run will still run or at least the chance of breakage is much much less than now. Right now if I run a release, then move to the next many things break. Things will always break to some extent but it seems to have gotten worse lately. I guess what really bothered me is the comment about breaking things and users would just have to live with it until it got fixed whenever. As I said, my objective is to move as much as I can off Windows and I have run wine-cvs and submitted some bugs and data to help debug the regression and I understand wine isn't ready for real use yet. Unfortunately, I don't have the time to do a lot of that so I've essentially dropped Wine and f! igure I'll either wait until someday I can have a release that doesn't break too much between updates or stay with Windows. This is probably what many others have done, too. Don't get me wrong - the Wine team has a very difficult task and has done very well and been responsive but the let 'em use it broke or eat cake approach is not so good. It would help to have a list like you suggest. That would at least let me know that if I have app z which is not on the list and want to run it then it's my problem if the next release breaks. > > From: Lionel Ulmer <lionel.ulmer(a)free.fr> > Date: 2004/09/14 Tue PM 04:32:52 GMT > To: brettholcomb(a)charter.net > CC: wine-devel(a)winehq.com > Subject: Re: Re: Directx9 > > > To be honest, Wine isn't going to be very useful and adopted until > > there is something that a user can install and know that if I have to update > > to a current verson and I pick the stable version that my apps that are > > running will continue to run. > > Well, you perfectly summed up the 'tragedy' of Wine: nobody ever knows what > YOUR applications are... There are so many Win32 applications that Wine > might run one day and so many Win32 APIs and interactions between them that

1 0

Re: Correct ConvertSidToStringSidW with test
by Alexandre Julliard Sept. 14, 2004

Sept. 14, 2004

Juan Lang <juan_lang(a)yahoo.com> writes: > ChangeLog: fix ConvertSidToStringSidW for all expected > values, and add tests The tests fail for me on XP SP1 (I added some debug output): security.c:85: Test failed: failed to parse sid string S-1-860116326 err 1337 security.c:85: Test failed: failed to parse sid string S-1-16909060 err 1337 security.c:87: Test failed: string sid didn't parse to expected value security.c:85: Test failed: failed to parse sid string S-1-66051 err 1337 security.c:87: Test failed: string sid didn't parse to expected value security.c:85: Test failed: failed to parse sid string S-1-258 err 1337 security.c:87: Test failed: string sid didn't parse to expected value security.c:85: Test failed: failed to parse sid string S-1-2 err 1337 -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: Re: Directx9
by brettholcomb＠charter.net Sept. 14, 2004

Sept. 14, 2004

As a user watching this thread here's my comments - Mike is correct. I understand Wine is not to 1.0 yet (close at .9 <G>) but we need something that is stable and that we can run while development is done in the unstable branch. To be honest, Wine isn't going to be very useful and adopted until there is something that a user can install and know that if I have to update to a current verson and I pick the stable version that my apps that are running will continue to run. At one time Wine was like this but in the last year it's gotten so that things that work don't anymore. I have submitted bugs and done some regression testing but let's be honest - most don't have the skills, time or desire to do that but they want to move apps to Linux. If anyone wants to use Wine for serious work to run apps they need then they won't use Wine. Some may go to Crossover, others will just drop it and either go Windows for those systems or forget about Wine or it's derivatives. As a user comments about letting things break and that users just have to put up with ituntil they are eventually fixed scare me! Many projects have stable source that is intended for users and those who want to actually do something useful with the application and then they also have CVS which is for those who want to try out the latest, help fix bugs, etc. > > From: Mike Hearn <m.hearn(a)signal.QinetiQ.com> > Date: 2004/09/14 Tue PM 12:59:45 GMT > I don't think it's about features. It's more about buggyness, and having > popular apps work. Having a stabilisation period where only regression > fixes are allowed on a particular branch could help with that. > > > After all I don't think our Wine CVS is THAT broken/problematic (the > > test suite should help here, too! Why not improve that one for a change?), > > and if people want that extra bit of stability, then they're very > > well-advised to go with CXO (or do you want to deprive CodeWeavers > > of their well-earned money? ;-)). > > Hehe, of course not :) I'm not volunteering to do any of this, at least > not right now! If Jeremy wanted to push Wine 0.9/1.0 forward then yes > I'd be happy to work on it but right now I don't have the time, and what > time I do have all goes on bugfixes and stabilisation for CrossOver. > > Anyway. The fact that CrossOver is a successful product perhaps says > something about the value of stable releases. > > > Even just thinking of the extra 700MB compiled code on my HDD resulting from > > two branches worries me a bit. ;-) > > Nobody is saying you have to use it, I'm sure most kernel developers > don't have both 2.4 and 2.6 installed at once. > > > Not to mention that I believe that the kernel and KDE projects have a > > drastically larger developer audience than Wine, so they can easily afford > > having some people do the branch maintenance. > > No, it's just a matter of willpower. Even small projects can do > stable/unstable releases. Indeed, KDE basically is just a collection of > smaller projects. > > > So at this point in time I still think that doing stable/unstable branching > > would be the entirely wrong thing to do. > > What point in time would it be the right thing to do? > > For me, the right time is "whenever Jeremy says it is" :) But, with my > community hat on, it's something that should be addressed at some point.

2 1

Re: Add IconsDir entry to config
by Marcus Meissner Sept. 14, 2004

Sept. 14, 2004

On Tue, Sep 14, 2004 at 11:53:53AM -0400, Vincent Béron wrote: > Marcus patch for winemenubuilder has been commited, but for almost all > users the icons will end up in c:\windows\temp for a lack of an IconsDir > entry in config. I don't find that location suitable for long-term > storage of icons. > This is still not perfect as most new users don't use config anymore. wineshelllink will copy them out I guess, won't it? Ciao, Marcus

1 0

Re: MLANG: use Interlocked* in AddRef and Release
by Daniel Remenak Sept. 14, 2004

Sept. 14, 2004

On Tue, 14 Sep 2004 18:56:40 +0900, Mike McCormack <mike(a)codeweavers.com> wrote: > > ChangeLog: > * use Interlocked* functions in AddRef and Release > <snip> > > static ULONG WINAPI fnIEnumCodePage_Release( > IEnumCodePage* iface) > { > ICOM_THIS_MULTI(EnumCodePage_impl, vtbl_IEnumCodePage, iface); > - ULONG ref = --This->ref; > + ULONG ref = InterlockedIncrement(&This->ref); operator-- changed to InterlockedIncrement instead of InterlockedDecrement. Is that intentional? --Daniel

1 0