June 2003 - Wine-Devel - list.winehq.org

About NtDelayExecution & Sleep

by Sylvain Petreolle

Seems we will have a drastic performance improvement :) : Programs that used to hang into (Nt)WaitForMultipleObjects were a lot. http://www.winehq.org/hypermail/wine-cvs/2003/06/0260.html http://www.winehq.org/hypermail/wine-cvs/2003/06/0274.html ===== Sylvain Petreolle (spetreolle_at_users_dot_sourceforge_dot_net) ICQ #170597259 alias upsf='false ; while [ $? -ne 0 ] ; do cvs update -APd ; done 2>&1 |tee cvslog' "What if tomorrow the War could be over ?" Morpheus, in "Reloaded". ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

June 30, 2003

Re: wine.texinfo.diff

by Alexandre Julliard

Tom Wickline <twickline(a)skybest.com> writes: > Changelog > > Change Copyright from 1997,1998 to 1997-2003 There's no reason to do that, this file hasn't really changed in a long time. -- Alexandre Julliard julliard(a)winehq.com

June 30, 2003

Re: Don't set stacking order against unvisible windows

by Alexandre Julliard

Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes: > Changelog: > dlls/x11drv/window.c: X11DRV_sync_whole_window_position > Don't specify a stacking order agains unvisible windows This will break other things. The right fix is to make the desktop option work correctly across processes. -- Alexandre Julliard julliard(a)winehq.com

June 30, 2003

Re: still many warnings from Mesa

by Lionel Ulmer

> There is no such thing that is widely known as the "Linux ABI" _and_ > that mandates things like this. > > Do you refer to http://oss.sgi.com/projects/ogl-sample/ABI/ ? Yes. > If we're nitpicking, this has nothing to do with an ABI, but with an API. Well, the documentation is called an ABI so I take their naming conventions even if in the case of header file definitions I agree with you. > If we are not nitpicking, this problem still exists with Mesa-5.0.1, so > it would be nice to address it (as Raphaël once suggested). Well, feel free to do so, this is a can of worm that I do not particularly like to open (and it works for me (tm)). But I will post a mail on the Mesa-devel mailing list about the glXGetProcAddressARB issue, we will see what I get for an answer :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/

June 30, 2003

Re: still many warnings from Mesa

by Lionel Ulmer

> So i prefer to do fixes to not have more any problems with "not corrects > headers" than waiting for corrects one (or if you prefer you can put correct > headers on wine source tree). Well, you are free to fix those warnings if you wish (I won't do it as it works perfectly well on my system so I cannot test with what I consider broken headers). If you do so, change also the 'make_opengl' Perl script as I would prefer not to always come behind people comitting direct fixes to the auto-generated files as soon as I want to update the files. Lionel -- Lionel Ulmer - http://www.bbrox.org/

June 30, 2003

Re: Loader fix for pathes differing by extra backslashes

by David Laight

> Even if windows treats these as seperate modules, then we still have a > problem, because dlopen works with unix pathes, and filenames differing > by a backslash still have the same unix path. dlopen will almost certainly do a device/inode_number check on the open file, rather than any comparison of the names. David -- David Laight: david(a)l8s.co.uk

June 30, 2003

Re: [dx61] d3d9 guid + d3d9 header fixes

by Raphaël Junqueira

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Le Lundi 30 Juin 2003 22:51, Alexandre Julliard a écrit : > Raphaël Junqueira <fenix(a)club-internet.fr> writes: > > Yes, they are here for "16bit drivers". But for me its more easier to > > play that way than with LARGE_INTEGERs. > > > > I'll fix it when the code will work. > > I'm not sure I like that idea, I'm worried that if code starts > depending on that it will be a pain to fix later on. If you want to > write the code using 16-bit fields you can do that locally, but I'd > prefer that you then fix it before submitting, so that we don't need > to put wrong headers in CVS. ok ok, i'll fix it on next patch Regards, Raphael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/AKZdp7NA3AmQTU4RAng4AJ9Km80wb+5oR8kgX4cX7GjY0Z7/GQCfTdn0 gCHwLEKAcKc1sT7AV3ybC5w= =ZCIS -----END PGP SIGNATURE-----

June 30, 2003

Re: [dx61] d3d9 guid + d3d9 header fixes

by Alexandre Julliard

Raphaël Junqueira <fenix(a)club-internet.fr> writes: > Yes, they are here for "16bit drivers". But for me its more easier to play > that way than with LARGE_INTEGERs. > > I'll fix it when the code will work. I'm not sure I like that idea, I'm worried that if code starts depending on that it will be a pain to fix later on. If you want to write the code using 16-bit fields you can do that locally, but I'd prefer that you then fix it before submitting, so that we don't need to put wrong headers in CVS. -- Alexandre Julliard julliard(a)winehq.com

June 30, 2003

Re: [dx61] d3d9 guid + d3d9 header fixes

by Raphaël Junqueira

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Le Lundi 30 Juin 2003 20:13, Alexandre Julliard a écrit : > Raphaël Junqueira <fenix(a)club-internet.fr> writes: > > Index: include/d3d9types.h > > =================================================================== > > RCS file: /home/wine/wine/include/d3d9types.h,v > > retrieving revision 1.2 > > diff -u -r1.2 d3d9types.h > > --- include/d3d9types.h 24 Jun 2003 19:26:51 -0000 1.2 > > +++ include/d3d9types.h 27 Jun 2003 22:14:40 -0000 > > @@ -1131,8 +1131,10 @@ > > typedef struct _D3DADAPTER_IDENTIFIER9 { > > char Driver[MAX_DEVICE_IDENTIFIER_STRING]; > > char Description[MAX_DEVICE_IDENTIFIER_STRING]; > > - char DeviceName[32]; /* Device name for GDI (ex. > > \\.\DISPLAY1) */ - LARGE_INTEGER DriverVersion; > > + char DeviceName[32]; > > + DWORD DriverVersionLowPart; > > + DWORD DriverVersionHighPart; > > + > > Isn't DriverVersionLow/HighPart supposed to be for 16-bit code? Why > do you need to use that instead of DriverVersion? Hi Alexandre, Yes, they are here for "16bit drivers". But for me its more easier to play that way than with LARGE_INTEGERs. I'll fix it when the code will work. Regards, Raphael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/AJ4Pp7NA3AmQTU4RAgXBAJ95odyutmGomMkjPlqUEUf9YlNLOgCfRvID lz41UJRDBvVm9c0W9895dJM= =5qR1 -----END PGP SIGNATURE-----

June 30, 2003

Re: still many warnings from Mesa

by Raphaël Junqueira

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, > > Well, the Linux ABI tells this : > > There is no such thing that is widely known as the "Linux ABI" _and_ > that mandates things like this. > > Do you refer to http://oss.sgi.com/projects/ogl-sample/ABI/ ? > > > " 4.4. glx.h must include the prototype of the glXGetProcAddressARB > > extension described above. > > If we're nitpicking, this has nothing to do with an ABI, but with an API. > > If we are not nitpicking, this problem still exists with Mesa-5.0.1, so > it would be nice to address it (as Raphaël once suggested). Well, For what i have seen, too few headers are "ABI correct" (only some SGI and HP headers). So i prefer to do fixes to not have more any problems with "not corrects headers" than waiting for corrects one (or if you prefer you can put correct headers on wine source tree). Regards, Raphael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/AJ1Hp7NA3AmQTU4RAg7bAJ9wVIHvKEjGpomjZhKFbdjBu0wkoACgltdz a/yhXUQB89VUOxXx9qDbLzg= =+vkY -----END PGP SIGNATURE-----

June 30, 2003