December 2005 - Wine-Devel - list.winehq.org

Re: CVSROOT/. loginfo

by Alexandre Julliard

Martin Fuchs <fuchs.martin(a)gmail.com> writes: > While searching for good examples I good even more comfortable with > the second idea: The changelog can be quite long, and only displaying > some truncated part of it may not be that good. Using the mail subject > instead is better because the patch writer already had the possibility > to condense the change into some meaningfull one line-comment. Yes, I think that's the way to go. -- Alexandre Julliard julliard(a)winehq.org

Dec. 4, 2005

Re: opengl support in wine

by Tomas Carnecky

Mike McCormack wrote: > >> eg. use RTLD_NEXT instead of the real libGL handle. This would make it >> possible to preload my own library but wouldn't change the weak >> linking. In fact, that's how I've modified my local wine copy, and it >> worked. > > > Well, you have the patch now, so all you need to do is submit it ;) > boils down to a one-line patch. RTLD_NEXT doesn't work, I have to use RTLD_DEFAULT to make wine (or the dynamic loader) use my functions. tom

Dec. 4, 2005

Re: opengl support in wine

by Tomas Carnecky

Mike McCormack wrote: > Mike Hearn wrote: > >> On Thu, 01 Dec 2005 16:12:47 +0000, Tomas Carnecky wrote: >> >>> I've had a discussion with someone through this list about wine and >>> libGL.so. It was about wine using dlopen("libGL.so") instead of linking >>> directly with libGL.so. >> >> >> >> IIRC this was done so CodeWeavers can ship a GL enabled build. I don't >> see >> any reason to change it. Weak linking is usually a good thing. > > > ddraw.dll uses dlopen on libGL, because there's code in ddraw that can > work without libGL being present, and that is needed for some programs > (eg. IE6) to run. dlopen'ing means Wine compiled on a machine with > libGL can be run on a machine without libGL. > > opengl32.dll is directly linked with libGL, since it's not useful > without it. > > If you're implementing your own shared library, you can probably try > dlopen'ing the functions you need from that first, then falling back to > dlopening from libGL. > At least you could do: glHandle = dlopen("libGL.so", ...) but later: glXSwapBuffers_Ptr = dlsym(RTLD_NEXT, "glXSwapBuffers"); eg. use RTLD_NEXT instead of the real libGL handle. This would make it possible to preload my own library but wouldn't change the weak linking. In fact, that's how I've modified my local wine copy, and it worked. tom

Dec. 4, 2005

Re: opengl support in wine

by Mike McCormack

> eg. use RTLD_NEXT instead of the real libGL handle. This would make it > possible to preload my own library but wouldn't change the weak linking. > In fact, that's how I've modified my local wine copy, and it worked. Well, you have the patch now, so all you need to do is submit it ;) Mike

Dec. 4, 2005

Re: Make check failure

by Dustin Navea

Michael Jung wrote: > Hi, > > On Sunday 04 December 2005 04:35, James Hawkins wrote: > >>On 12/3/05, Dustin Navea <speeddymon(a)gmail.com> wrote: >> >>>make[3]: Entering directory `/home/speeddy/wine/dlls/advapi32/tests' >>>../../../tools/runtest -q -P wine -M advapi32.dll -T ../../.. -p >>>advapi32_test.exe.so crypt.c && touch crypt.ok >>>crypt.c:710: Test failed: expected 234, got 0 >>> >> >>I'll work on it when I get home. > > > Just wanted to note that this only seems to happen if you run the test for the > first time with a pristine .wine directory. It succeeds for me if I run it a > second time. > > Bye, Please see the take 2 email, as the same happened to me. As a side note, the first time I ran it, the 2.6.14.x header capi.h wouldnt compile, but was found by configure.. The 2nd time, I had renamed that header so it wouldnt be found, and recompiled, and it succeeded.. Either way, whether that header caused it or not (which it seems it didnt now), it shouldnt fail the first time, and we need to figure out why. Dustin

Dec. 4, 2005

Re: ConfigureNotify messages queuing up

by Mike McCormack

> > I mean like this, say the message queue looks like this: > > ConfigureNotify > other message > ConfigureNotify > > With the "oldest" at the bottom. The code will then search for newer > ConfigureNotify messages in the queue, and find it (the one at the top) > and deliver that to the application. So it will be delivered before the > "other message", whatever that might be, even though the other message > happened before. > > I don't know in which cases or which kind of messages that could > possible end up like this and if it could cause problems. I'm thinking I > could use XCheckIfEvent to go through the list and only apply the > tactics only if there are several ConfigureNotify in a row, not if there > are other messages in between. But I haven't tried this out yet. I already wrote a patch to fix this problem. It works by getting the actual position of the window on each ConfigureNotify, and throwing it away if the location in the message doesn't match. Alexandre considers it a hack, and didn't apply it to Wine when I submitted it (quite some time ago). I've attached the patch; if somebody has the energy to get something like this accepted into Wine, that would be great. Mike Index: dlls/x11drv/winpos.c =================================================================== RCS file: /cvstrees/crossover/office/wine/dlls/x11drv/winpos.c,v retrieving revision 1.1.1.48 retrieving revision 1.84 diff -u -r1.1.1.48 -r1.84 --- dlls/x11drv/winpos.c 30 Nov 2005 13:24:09 -0000 1.1.1.48 +++ dlls/x11drv/winpos.c 30 Nov 2005 14:52:06 -0000 1.84 @@ -1184,6 +1431,25 @@ 0, 0, &x, &y, &child ); wine_tsx11_unlock(); } + + /* HACK: find out the real window position... if it doesn't match ignore the ConfigureNotify */ + if (data->toplevel) + { + Window ignore_root; + int ignore_x, ignore_y, height, width, ignore_depth, ignore_border; + + wine_tsx11_lock(); + XGetGeometry(event->display, data->whole_window, &ignore_root, + &ignore_x, &ignore_y, &width, &height, &ignore_border, &ignore_depth); + wine_tsx11_unlock(); + + if ( (width!=event->width) || (height!=event->height ) ) + { + TRACE("Discarding old ConfigureNotify message for hwnd %p\n",hwnd); + return; + } + } + rect.left = x; rect.top = y; rect.right = x + event->width;

Dec. 4, 2005

Re: opengl support in wine

by Mike McCormack

Mike Hearn wrote: > On Thu, 01 Dec 2005 16:12:47 +0000, Tomas Carnecky wrote: > >>I've had a discussion with someone through this list about wine and >>libGL.so. It was about wine using dlopen("libGL.so") instead of linking >>directly with libGL.so. > > > IIRC this was done so CodeWeavers can ship a GL enabled build. I don't see > any reason to change it. Weak linking is usually a good thing. ddraw.dll uses dlopen on libGL, because there's code in ddraw that can work without libGL being present, and that is needed for some programs (eg. IE6) to run. dlopen'ing means Wine compiled on a machine with libGL can be run on a machine without libGL. opengl32.dll is directly linked with libGL, since it's not useful without it. If you're implementing your own shared library, you can probably try dlopen'ing the functions you need from that first, then falling back to dlopening from libGL. Mike

Dec. 4, 2005

make errors in $WINE/dlls/wininet/netconnection.c

by Colin Wright

After a clean and cvs -PAd I get the following errors during make netconnection.c: In function `sock_get_error': netconnection.c:205: error: `EINTR' undeclared (first use in this function) netconnection.c:205: error: (Each undeclared identifier is reported only once netconnection.c:205: error: for each function it appears in.) netconnection.c:206: error: `EBADF' undeclared (first use in this function) netconnection.c:207: error: `EPERM' undeclared (first use in this function) netconnection.c:208: error: `EACCES' undeclared (first use in this function) netconnection.c:209: error: `EFAULT' undeclared (first use in this function) netconnection.c:210: error: `EINVAL' undeclared (first use in this function) netconnection.c:211: error: `EMFILE' undeclared (first use in this function) netconnection.c:212: error: `EWOULDBLOCK' undeclared (first use in this function) netconnection.c:213: error: `EINPROGRESS' undeclared (first use in this function) netconnection.c:214: error: `EALREADY' undeclared (first use in this function) netconnection.c:215: error: `ENOTSOCK' undeclared (first use in this function) netconnection.c:216: error: `EDESTADDRREQ' undeclared (first use in this function) netconnection.c:217: error: `EMSGSIZE' undeclared (first use in this function) netconnection.c:218: error: `EPROTOTYPE' undeclared (first use in this function) netconnection.c:219: error: `ENOPROTOOPT' undeclared (first use in this function) netconnection.c:220: error: `EPROTONOSUPPORT' undeclared (first use in this function) netconnection.c:221: error: `ESOCKTNOSUPPORT' undeclared (first use in this function) netconnection.c:222: error: `EOPNOTSUPP' undeclared (first use in this function) netconnection.c:223: error: `EPFNOSUPPORT' undeclared (first use in this function) netconnection.c:224: error: `EAFNOSUPPORT' undeclared (first use in this function) netconnection.c:225: error: `EADDRINUSE' undeclared (first use in this function) netconnection.c:226: error: `EADDRNOTAVAIL' undeclared (first use in this function) netconnection.c:227: error: `ENETDOWN' undeclared (first use in this function) netconnection.c:228: error: `ENETUNREACH' undeclared (first use in this function) netconnection.c:229: error: `ENETRESET' undeclared (first use in this function) netconnection.c:230: error: `ECONNABORTED' undeclared (first use in this function) netconnection.c:231: error: `EPIPE' undeclared (first use in this function) netconnection.c:232: error: `ECONNRESET' undeclared (first use in this function) netconnection.c:233: error: `ENOBUFS' undeclared (first use in this function) netconnection.c:234: error: `EISCONN' undeclared (first use in this function) netconnection.c:235: error: `ENOTCONN' undeclared (first use in this function) netconnection.c:236: error: `ESHUTDOWN' undeclared (first use in this function) netconnection.c:237: error: `ETOOMANYREFS' undeclared (first use in this function) netconnection.c:238: error: `ETIMEDOUT' undeclared (first use in this function) netconnection.c:239: error: `ECONNREFUSED' undeclared (first use in this function) netconnection.c:240: error: `ELOOP' undeclared (first use in this function) netconnection.c:241: error: `ENAMETOOLONG' undeclared (first use in this function) netconnection.c:242: error: `EHOSTDOWN' undeclared (first use in this function) netconnection.c:243: error: `EHOSTUNREACH' undeclared (first use in this function) netconnection.c:244: error: `ENOTEMPTY' undeclared (first use in this function) netconnection.c:260: error: `errno' undeclared (first use in this function) netconnection.c:260: warning: implicit declaration of function `perror' netconnection.c: In function `NETCON_create': netconnection.c:279: error: `errno' undeclared (first use in this function) netconnection.c: In function `NETCON_close': netconnection.c:315: error: `errno' undeclared (first use in this function) netconnection.c: At top level: netconnection.c:321: error: syntax error before '*' token netconnection.c: In function `NETCON_connect': netconnection.c:436: error: `errno' undeclared (first use in this function) netconnection.c: In function `NETCON_send': netconnection.c:461: error: `errno' undeclared (first use in this function) netconnection.c: In function `NETCON_recv': netconnection.c:495: error: `errno' undeclared (first use in this function) netconnection.c: In function `NETCON_getNextLine': netconnection.c:585: error: `errno' undeclared (first use in this function) netconnection.c: At top level: netconnection.c:322: warning: `check_hostname' defined but not used Although I've probably wasting my time and there's simply a missing header file or netconnection.c shouldn't even be there I've found that the constants EINTR, EBADF, EPERM, EACCES, EFAULT, EINVAL, EMFILE, EPIPE, ENAMETOOLONG and ENOTEMPTY are all defined in $WINE/include/msvcrt/errno.h and the rest only have WSA\1 constants in $WINE/include/winsock.h. -- Colin Wright cdonline(a)tesco.net

Dec. 4, 2005

Re: ddraw: make some driver info not const

by Rein Klazes

On Sat, 3 Dec 2005 09:44:07 +0100, you wrote: >> This is wrong. No user program should modify our internal data. I think >> you need to copy this data into heap before passing it to the app. You >> should make simple test to check if the data returned on windows is >> within heap or not. > >Yeah, I agree with Vitaliy here... We were alread hit multiple times by this >bug in other cases: Wine should never send to the application actual private >data as many games expect to use these values to do actual processing. OK, I have tested this under Windows. The data is protected and the access violation is handled by DirectDrawEnumerate: Changelog: dlls/ddraw : main.c, Makefile.in Catch access violations when calling the DirectDrawEnumerateProc. Rein.

Dec. 4, 2005

Re: Make check failure

by Michael Jung

Hi, On Sunday 04 December 2005 04:35, James Hawkins wrote: > On 12/3/05, Dustin Navea <speeddymon(a)gmail.com> wrote: > > make[3]: Entering directory `/home/speeddy/wine/dlls/advapi32/tests' > > ../../../tools/runtest -q -P wine -M advapi32.dll -T ../../.. -p > > advapi32_test.exe.so crypt.c && touch crypt.ok > > crypt.c:710: Test failed: expected 234, got 0 > > > I'll work on it when I get home. Just wanted to note that this only seems to happen if you run the test for the first time with a pristine .wine directory. It succeeds for me if I run it a second time. Bye, -- Michael Jung mjung(a)iss.tu-darmstadt.de

Dec. 4, 2005