March 2006 - Wine-Devel - list.winehq.org

Re: Prevent the use of windowsx.h with Wine source.

by Jacek Caban

Robert Shearman wrote: > Mike McCormack wrote: > > >> +#ifdef __WINESRC__ >> +/* This file contains macros that cause warnings on gcc 4.1, so avoid it. */ >> +#error Please avoid use of windowsx.h in Wine source code. >> +#endif >> + >> >> > > Why don't we fix the macros as suggested by Francois, rather than > preventing its use? It seems like a big waste of time to have submitted > all of the patches to the files using windowsx.h when fixing the macros > is necessary for Winelib anyway. > There is one more solution that wasn't mentioned here. How about using a form like: (void)ListView_GetItem(...); It's a fix on the caller side, but it's really a minimal change and it could be even done by a script. BTW I agree that code like that looks ugly. Jacek

March 18, 2006

Re: shlwapi: Fix compilaction with GCC 4.1.

by Jacek Caban

Robert Shearman wrote: > Jacek Caban wrote: > > >> Without this patch GCC 4.1 fails with message >> string.c:531: undefined reference to `strncmpW' >> >> >> > > That would seem to be a bug in GCC 4.1. I'm no expert on the C spec, but > if the compiler can't inline the function, as it can't here when a > function pointer is used then I think it should include the static > version of the function in the object file. > Yeah, that's what I'd expect gcc should do, but if there is a bug in official release of gcc that is easy to workaround, we should do it in Wine IMO. Can anyone confirm that it's really a bug in gcc (I'm not C spec expert too)? Jacek

March 18, 2006

Re: shlwapi: Fix compilaction with GCC 4.1.

by Robert Shearman

Jacek Caban wrote: >Without this patch GCC 4.1 fails with message >string.c:531: undefined reference to `strncmpW' > > That would seem to be a bug in GCC 4.1. I'm no expert on the C spec, but if the compiler can't inline the function, as it can't here when a function pointer is used then I think it should include the static version of the function in the object file. -- Rob Shearman

March 18, 2006

Re: WINEFILE: Eliminate use of windowsx.h

by Robert Shearman

Mike McCormack wrote: > > Martin Fuchs wrote: > >> "Eliminating" windowsx.h sounds like you consider this header file a >> bad thing. >> I don't think so - it provides a bunch of very usefull type safe >> macro definitions. >> (SelectFont, ListBox_SetSel, Button_SetCheck, ...) >> >> I understand you want to eliminate some useless warnings printed by >> newer GCC versions. Wouldn't it be better to correct the wrong warnings >> of GCC instead? > I agree with this comment that we shouldn't remove the uses of these macros, but I have to disagree with them being typesafe - they aren't. > > Please see my previous email for a discussion of the problem: > > http://www.winehq.org/pipermail/wine-devel/2006-March/045250.html > > Despite containing some useful macros, those macros are somewhat > broken as they are ignorant of UNICODE, so cannot be "fixed" by simple > conversion to inline functions. Unicode isn't a problem as "void *" could simply be used, but there are other compatibility reasons why inline functions shouldn't be used. -- Rob Shearman

March 18, 2006

Re: Prevent the use of windowsx.h with Wine source.

by Robert Shearman

Mike McCormack wrote: >+#ifdef __WINESRC__ >+/* This file contains macros that cause warnings on gcc 4.1, so avoid it. */ >+#error Please avoid use of windowsx.h in Wine source code. >+#endif >+ > Why don't we fix the macros as suggested by Francois, rather than preventing its use? It seems like a big waste of time to have submitted all of the patches to the files using windowsx.h when fixing the macros is necessary for Winelib anyway. -- Rob Shearman

March 18, 2006

Re: How hard would it be to support Java?

by Christoph

Dan Kegel schrieb: > Quite a few apps use embedded JVM's. > Case in point: SPSS, one of the apps requested by Munich. WTF? There is a JVM for Linux available. To my mind contact the manufacture of your software and explain to them that Java is platform independent ... > > So I played around a bit with Sun's latest 1.5 JRE. > It can run trivial apps, so I closed > http://bugs.winehq.org/show_bug.cgi?id=2953 > (ok, maybe that was premature, since the bug was for Sun's 1.4 JRE). > > But it can't run applets; first, it runs into a nasty glx error, > http://bugs.winehq.org/show_bug.cgi?id=4143 > > Once you patch your way past that, it complains about not finding > a native method, see > http://bugs.winehq.org/show_bug.cgi?id=4873 > > And it doesn't show up in Firefox's about:plugins by default, see > http://bugs.winehq.org/show_bug.cgi?id=4860 > > Can anyone shed some light on these, especially bug 4143? > Thanks, > Dan > > -- > Wine for Windows ISVs: http://kegel.com/wine/isv > >

March 18, 2006

Re: rpaths not working?

by Alexandre Julliard

Mike Hearn <mike(a)plan99.net> writes: > And sure enough the .dll.so files don't have an $ORIGIN/../ runpath in them. > This seems like winebuild magic, at least, I didn't see any obvious places > in the build system to add the flags. Any idea what's going wrong here? AFAIK the rpath of the main binary is supposed to apply to dependencies too, not sure why it doesn't in your case. What libc version is that? -- Alexandre Julliard julliard(a)winehq.org

March 18, 2006

Re: PATCH: GetDevCaps() bitdepth flag

by pagefault

Updated again, this should be the final patch. Sorry for spamming. :) On 3/18/06, pagefault <pagefault(a)gmail.com> wrote: > Updated my patch. I had placed it in the wrong function, this is a lot > lower in the pipeline and should not conflict with other code. Please > test. > > --- dlls/gdi/dc2.c 2006-03-18 00:46:11.000000000 -0500 > +++ dlls/gdi/dc.c 2006-03-15 09:50:32.000000000 -0500 > @@ -905,11 +905,6 @@ > } > GDI_ReleaseObj( hdc ); > } > - > - // Windows returns a 32-bit depth (24-bit effective) > - > - if (caps == BITSPIXEL && ret == 24) ret = 32; > - > return ret; > } > > > On 3/18/06, pagefault <pagefault(a)gmail.com> wrote: > > Ok, this is rather odd. Do those apps work properly when the patch is > > not applied? Also do you know if these apps are using DirectDraw? > > > > On 3/18/06, pagefault <pagefault(a)gmail.com> wrote: > > > Thanks for testing it out. I will try to get a copy of these apps and > > > figure out whats going on. > > > > > > On 3/18/06, pagefault <pagefault(a)gmail.com> wrote: > > > > Thanks for testing it out. I will try to get a copy of these apps and > > > > figure out whats going on. > > > > > > > > On 3/17/06, Willie Sippel <willie(a)zeitgeistmedia.net> wrote: > > > > > Am Freitag, 17. März 2006 20:12 schrieb pagefault: > > > > > > Hi there, I work on ZSNES and I was trying to get it working > under > > > > > > wine and I ran into a small bug when running under a 32 bit > > desktop. > > > > > > > > > > > > This fixed a bug in the DeviceGetCaps() function used to return > the > > > > > > current bitdepth of the desktop. It is my understanding that X11 > > > > > > returns "24" as the bitdepth while running a 32 bit framebuffer. > I > > > > > > have seen in the code where it does change the 24 to 32, but I > have > > > > > > discovered a spot where this has been missed. > > > > > > > > > > > > The following is the changes I made, it simply returns 32 if the > > user > > > > > > has a 24 bit desktop. > > > > > > > > > > > With your patch applied, two applications I tested (Newtek Aura and > > Bauhaus/ > > > > > TVPaint Mirage) show an odd bug. Only the window background gets > > drawn, but > > > > > all the widgets are missing, or, more precisely, invisible. Both > > applications > > > > > use their own toolkit - Mirage is infact Aura's successor, so their > > drawing > > > > > code should be very similar. But Aura's used to work, while > Mirage's > > always > > > > > produced borked results - painting stuff blue and distorted instead > of > > gray. > > > > > > > > > > -- > > > > > Willie Sippel > > > > > > > > > > //////// | Tritium Studios > > > > > // | ______________________________ > > > > > //// /// | http://www.tritium-studios.com > > > > > > > > > > <willie(a)froq.net> > > > > > > > > > > > > > > > > > > > > > > > > >

March 18, 2006

Re: PATCH: GetDevCaps() bitdepth flag

by pagefault

Updated my patch. I had placed it in the wrong function, this is a lot lower in the pipeline and should not conflict with other code. Please test. --- dlls/gdi/dc2.c 2006-03-18 00:46:11.000000000 -0500 +++ dlls/gdi/dc.c 2006-03-15 09:50:32.000000000 -0500 @@ -905,11 +905,6 @@ } GDI_ReleaseObj( hdc ); } - - // Windows returns a 32-bit depth (24-bit effective) - - if (caps == BITSPIXEL && ret == 24) ret = 32; - return ret; } On 3/18/06, pagefault <pagefault(a)gmail.com> wrote: > Ok, this is rather odd. Do those apps work properly when the patch is > not applied? Also do you know if these apps are using DirectDraw? > > On 3/18/06, pagefault <pagefault(a)gmail.com> wrote: > > Thanks for testing it out. I will try to get a copy of these apps and > > figure out whats going on. > > > > On 3/18/06, pagefault <pagefault(a)gmail.com> wrote: > > > Thanks for testing it out. I will try to get a copy of these apps and > > > figure out whats going on. > > > > > > On 3/17/06, Willie Sippel <willie(a)zeitgeistmedia.net> wrote: > > > > Am Freitag, 17. März 2006 20:12 schrieb pagefault: > > > > > Hi there, I work on ZSNES and I was trying to get it working under > > > > > wine and I ran into a small bug when running under a 32 bit > desktop. > > > > > > > > > > This fixed a bug in the DeviceGetCaps() function used to return the > > > > > current bitdepth of the desktop. It is my understanding that X11 > > > > > returns "24" as the bitdepth while running a 32 bit framebuffer. I > > > > > have seen in the code where it does change the 24 to 32, but I have > > > > > discovered a spot where this has been missed. > > > > > > > > > > The following is the changes I made, it simply returns 32 if the > user > > > > > has a 24 bit desktop. > > > > > > > > > With your patch applied, two applications I tested (Newtek Aura and > Bauhaus/ > > > > TVPaint Mirage) show an odd bug. Only the window background gets > drawn, but > > > > all the widgets are missing, or, more precisely, invisible. Both > applications > > > > use their own toolkit - Mirage is infact Aura's successor, so their > drawing > > > > code should be very similar. But Aura's used to work, while Mirage's > always > > > > produced borked results - painting stuff blue and distorted instead of > gray. > > > > > > > > -- > > > > Willie Sippel > > > > > > > > //////// | Tritium Studios > > > > // | ______________________________ > > > > //// /// | http://www.tritium-studios.com > > > > > > > > <willie(a)froq.net> > > > > > > > > > > > > > > > > > >

March 18, 2006

Re: PATCH: GetDevCaps() bitdepth flag

by pagefault

Ok, this is rather odd. Do those apps work properly when the patch is not applied? Also do you know if these apps are using DirectDraw? On 3/18/06, pagefault <pagefault(a)gmail.com> wrote: > Thanks for testing it out. I will try to get a copy of these apps and > figure out whats going on. > > On 3/18/06, pagefault <pagefault(a)gmail.com> wrote: > > Thanks for testing it out. I will try to get a copy of these apps and > > figure out whats going on. > > > > On 3/17/06, Willie Sippel <willie(a)zeitgeistmedia.net> wrote: > > > Am Freitag, 17. März 2006 20:12 schrieb pagefault: > > > > Hi there, I work on ZSNES and I was trying to get it working under > > > > wine and I ran into a small bug when running under a 32 bit desktop. > > > > > > > > This fixed a bug in the DeviceGetCaps() function used to return the > > > > current bitdepth of the desktop. It is my understanding that X11 > > > > returns "24" as the bitdepth while running a 32 bit framebuffer. I > > > > have seen in the code where it does change the 24 to 32, but I have > > > > discovered a spot where this has been missed. > > > > > > > > The following is the changes I made, it simply returns 32 if the user > > > > has a 24 bit desktop. > > > > > > > With your patch applied, two applications I tested (Newtek Aura and Bauhaus/ > > > TVPaint Mirage) show an odd bug. Only the window background gets drawn, but > > > all the widgets are missing, or, more precisely, invisible. Both applications > > > use their own toolkit - Mirage is infact Aura's successor, so their drawing > > > code should be very similar. But Aura's used to work, while Mirage's always > > > produced borked results - painting stuff blue and distorted instead of gray. > > > > > > -- > > > Willie Sippel > > > > > > //////// | Tritium Studios > > > // | ______________________________ > > > //// /// | http://www.tritium-studios.com > > > > > > <willie(a)froq.net> > > > > > > > > > > > >

March 18, 2006

Re: PATCH: GetDevCaps() bitdepth flag

by pagefault

Thanks for testing it out. I will try to get a copy of these apps and figure out whats going on. On 3/18/06, pagefault <pagefault(a)gmail.com> wrote: > Thanks for testing it out. I will try to get a copy of these apps and > figure out whats going on. > > On 3/17/06, Willie Sippel <willie(a)zeitgeistmedia.net> wrote: > > Am Freitag, 17. März 2006 20:12 schrieb pagefault: > > > Hi there, I work on ZSNES and I was trying to get it working under > > > wine and I ran into a small bug when running under a 32 bit desktop. > > > > > > This fixed a bug in the DeviceGetCaps() function used to return the > > > current bitdepth of the desktop. It is my understanding that X11 > > > returns "24" as the bitdepth while running a 32 bit framebuffer. I > > > have seen in the code where it does change the 24 to 32, but I have > > > discovered a spot where this has been missed. > > > > > > The following is the changes I made, it simply returns 32 if the user > > > has a 24 bit desktop. > > > > > With your patch applied, two applications I tested (Newtek Aura and Bauhaus/ > > TVPaint Mirage) show an odd bug. Only the window background gets drawn, but > > all the widgets are missing, or, more precisely, invisible. Both applications > > use their own toolkit - Mirage is infact Aura's successor, so their drawing > > code should be very similar. But Aura's used to work, while Mirage's always > > produced borked results - painting stuff blue and distorted instead of gray. > > > > -- > > Willie Sippel > > > > //////// | Tritium Studios > > // | ______________________________ > > //// /// | http://www.tritium-studios.com > > > > <willie(a)froq.net> > > > > > > >

March 18, 2006

Re: PATCH: GetDevCaps() bitdepth flag

by Willie Sippel

Am Freitag, 17. März 2006 20:12 schrieb pagefault: > Hi there, I work on ZSNES and I was trying to get it working under > wine and I ran into a small bug when running under a 32 bit desktop. > > This fixed a bug in the DeviceGetCaps() function used to return the > current bitdepth of the desktop. It is my understanding that X11 > returns "24" as the bitdepth while running a 32 bit framebuffer. I > have seen in the code where it does change the 24 to 32, but I have > discovered a spot where this has been missed. > > The following is the changes I made, it simply returns 32 if the user > has a 24 bit desktop. > With your patch applied, two applications I tested (Newtek Aura and Bauhaus/ TVPaint Mirage) show an odd bug. Only the window background gets drawn, but all the widgets are missing, or, more precisely, invisible. Both applications use their own toolkit - Mirage is infact Aura's successor, so their drawing code should be very similar. But Aura's used to work, while Mirage's always produced borked results - painting stuff blue and distorted instead of gray. -- Willie Sippel //////// | Tritium Studios // | ______________________________ //// /// | http://www.tritium-studios.com <willie(a)froq.net>

March 18, 2006

How hard would it be to support Java?

by Dan Kegel

Quite a few apps use embedded JVM's. Case in point: SPSS, one of the apps requested by Munich. So I played around a bit with Sun's latest 1.5 JRE. It can run trivial apps, so I closed http://bugs.winehq.org/show_bug.cgi?id=2953 (ok, maybe that was premature, since the bug was for Sun's 1.4 JRE). But it can't run applets; first, it runs into a nasty glx error, http://bugs.winehq.org/show_bug.cgi?id=4143 Once you patch your way past that, it complains about not finding a native method, see http://bugs.winehq.org/show_bug.cgi?id=4873 And it doesn't show up in Firefox's about:plugins by default, see http://bugs.winehq.org/show_bug.cgi?id=4860 Can anyone shed some light on these, especially bug 4143? Thanks, Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

March 18, 2006

Re: PATCH: GetDevCaps() bitdepth flag

by Willie Sippel

Am Samstag, 18. März 2006 02:33 schrieb Tony Lambregts: > pagefault wrote: > > Hi there, I work on ZSNES and I was trying to get it working under > > wine and I ran into a small bug when running under a 32 bit desktop. > > > > This fixed a bug in the DeviceGetCaps() function used to return the > > current bitdepth of the desktop. It is my understanding that X11 > > returns "24" as the bitdepth while running a 32 bit framebuffer. I > > have seen in the code where it does change the 24 to 32, but I have > > discovered a spot where this has been missed. > > > > The following is the changes I made, it simply returns 32 if the user > > has a 24 bit desktop. > > > > I could also post code which exposes this bug if needed. > > > > *** dlls/x11drv/init.c 2006-03-17 13:05:59.000000000 -0500 > > --- dlls/x11drv/init.diff 2006-03-17 12:18:05.000000000 -0500 > > *************** > > *** 190,196 **** > > case VERTRES: > > return screen_height; > > case BITSPIXEL: > > ! return screen_depth; > > case PLANES: > > return 1; > > case NUMBRUSHES: > > --- 190,196 ---- > > case VERTRES: > > return screen_height; > > case BITSPIXEL: > > ! return (screen_depth == 24) ? 32 : screen_depth; > > case PLANES: > > return 1; > > case NUMBRUSHES: > > > > > > > > Thanks. > > does this actually fix it so that some program works that did not before? > > I'm not the expert for this area (X-11) but here are a couple of comments. > Patches for wine are in "diff -u format and if you want it included to wine > it is best submit it to wine-patches(a)winehq.org with a change log. IE: > > Change log: Fix GetDevCaps for 32 bit screen depth. Well, I know at least one problem this patch might fix - with DAZ|Studio. It worked with WINVER=win98, but with w2k or xp, an error message popped up ("DAZ|Studio requires 32bit color depth" or something"), and the program exited. I think more recent versions of DAZ|Studio still give the error message but continue to load. Haven't tested the program in the last few months, though (it's unusable as it uses OpenGL viewports)... -- Willie Sippel //////// | Tritium Studios // | ______________________________ //// /// | http://www.tritium-studios.com <willie(a)froq.net>

March 18, 2006

Re: PATCH: GetDevCaps() bitdepth flag

by Tony Lambregts

pagefault wrote: > Hi there, I work on ZSNES and I was trying to get it working under > wine and I ran into a small bug when running under a 32 bit desktop. > > This fixed a bug in the DeviceGetCaps() function used to return the > current bitdepth of the desktop. It is my understanding that X11 > returns "24" as the bitdepth while running a 32 bit framebuffer. I > have seen in the code where it does change the 24 to 32, but I have > discovered a spot where this has been missed. > > The following is the changes I made, it simply returns 32 if the user > has a 24 bit desktop. > > I could also post code which exposes this bug if needed. > > *** dlls/x11drv/init.c 2006-03-17 13:05:59.000000000 -0500 > --- dlls/x11drv/init.diff 2006-03-17 12:18:05.000000000 -0500 > *************** > *** 190,196 **** > case VERTRES: > return screen_height; > case BITSPIXEL: > ! return screen_depth; > case PLANES: > return 1; > case NUMBRUSHES: > --- 190,196 ---- > case VERTRES: > return screen_height; > case BITSPIXEL: > ! return (screen_depth == 24) ? 32 : screen_depth; > case PLANES: > return 1; > case NUMBRUSHES: > > > > Thanks. > > > does this actually fix it so that some program works that did not before? I'm not the expert for this area (X-11) but here are a couple of comments. Patches for wine are in "diff -u format and if you want it included to wine it is best submit it to wine-patches(a)winehq.org with a change log. IE: Change log: Fix GetDevCaps for 32 bit screen depth.

March 18, 2006

Re: kernel32: fix last error result on CreateFile

by Mike McCormack

Víctor Manuel Álvarez García wrote: > If CreateFile is called with CREATE_ALWAYS or > OPEN_ALWAYS flags, and the file already exists, the > function should success but the result of GetLastError > after the call must be ERROR_ALREADY_EXISTS. Wine was > not not setting the proper error code and GetLastError > just returned ERROR_SUCCESS. > > Wine is great, good work guys! > > Here goes my contribution, Thanks for the contribution! It would be great to write a test for this behaviour too, and add it to dlls/kernel/tests/file.c Mike

March 18, 2006

Re: WINEFILE: Eliminate use of windowsx.h

by Mike McCormack

Martin Fuchs wrote: > "Eliminating" windowsx.h sounds like you consider this header file a bad thing. > I don't think so - it provides a bunch of very usefull type safe macro definitions. > (SelectFont, ListBox_SetSel, Button_SetCheck, ...) > > I understand you want to eliminate some useless warnings printed by > newer GCC versions. Wouldn't it be better to correct the wrong warnings > of GCC instead? Please see my previous email for a discussion of the problem: http://www.winehq.org/pipermail/wine-devel/2006-March/045250.html Despite containing some useful macros, those macros are somewhat broken as they are ignorant of UNICODE, so cannot be "fixed" by simple conversion to inline functions. Mike

March 18, 2006

re: riched20: add EM_EXSETSEL conformance tests and fixes bug 4462 (revised)

by Dan Kegel

Brian wrote: + /* FIXME: EM_GETSEL needs to return proper ending value */ + todo_wine + { + ok(start == 0 && end == 18, "EM_EXSETSEL: expected (0,18) actual:(%d,%d)\n", start,end); + } What does EM_GETSEL return right now? It might be worth looking at that to see if you can fix it in the same patch, if it's easy. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

March 17, 2006

Re: Wine and RDPRINT

by Mariusz Kiełpiński

Dnia piątek, 17 marca 2006 14:35, Frederico Bertucci napisał: Hi > Good morning guys > > I did my system works with wine no problem, but when I try print using > then, doesnt work... if I print from any other aplication, works. > > I talked with my developer and he told me that are using a delphi componet > called RDPRINT, this in windows, to create better graphics. > > So, Are there any way to print in wine, using this RDPRINT ?? any dll, any > configuration > > I am using latest wine configured with winetools, the printer is a lx300. > > I am trying do this works since 2 weeks ago and not sucefull > > Tks guys > > try this patch ================================= wine.15.03.06.19.02.59.diff ? dlls/msvideo/Makefile ? dlls/win32s/Makefile ? dlls/winsock/Makefile ? dlls/winsock/libws2_32.def ? dlls/winsock/version.res ? dlls/winsock/tests/Makefile ? dlls/winsock/tests/testlist.c Index: dlls/gdi/printdrv.c =================================================================== RCS file: /home/wine/wine/dlls/gdi/printdrv.c,v retrieving revision 1.46 diff -u -p -1 -r1.46 printdrv.c --- dlls/gdi/printdrv.c 12 Sep 2005 10:30:06 -0000 1.46 +++ dlls/gdi/printdrv.c 15 Mar 2006 18:03:01 -0000 @@ -471,3 +471,3 @@ static int CreateSpoolFile(LPCSTR pszOut if (!psCmd[0] && !strncmp("LPR:",pszOutput,4)) - sprintf(psCmd,"|lpr -P%s",pszOutput+4); + sprintf(psCmd,"|lp -d'%s' ",pszOutput+4); =======================================

March 17, 2006

Re: WINEFILE: Eliminate use of windowsx.h

by Martin Fuchs

Hi, "Eliminating" windowsx.h sounds like you consider this header file a bad thing. I don't think so - it provides a bunch of very usefull type safe macro definitions. (SelectFont, ListBox_SetSel, Button_SetCheck, ...) I understand you want to eliminate some useless warnings printed by newer GCC versions. Wouldn't it be better to correct the wrong warnings of GCC instead? Regards, Martin

March 17, 2006

PATCH: GetDevCaps() bitdepth flag

by pagefault

Hi there, I work on ZSNES and I was trying to get it working under wine and I ran into a small bug when running under a 32 bit desktop. This fixed a bug in the DeviceGetCaps() function used to return the current bitdepth of the desktop. It is my understanding that X11 returns "24" as the bitdepth while running a 32 bit framebuffer. I have seen in the code where it does change the 24 to 32, but I have discovered a spot where this has been missed. The following is the changes I made, it simply returns 32 if the user has a 24 bit desktop. I could also post code which exposes this bug if needed. *** dlls/x11drv/init.c 2006-03-17 13:05:59.000000000 -0500 --- dlls/x11drv/init.diff 2006-03-17 12:18:05.000000000 -0500 *************** *** 190,196 **** case VERTRES: return screen_height; case BITSPIXEL: ! return screen_depth; case PLANES: return 1; case NUMBRUSHES: --- 190,196 ---- case VERTRES: return screen_height; case BITSPIXEL: ! return (screen_depth == 24) ? 32 : screen_depth; case PLANES: return 1; case NUMBRUSHES: Thanks.

March 17, 2006

Re: PATCH: Re: Problem with virtual memory rlimits

by Marcus Meissner

On Fri, Mar 17, 2006 at 06:10:40PM +0100, Alexandre Julliard wrote: > Marcus Meissner <meissner(a)suse.de> writes: > > > Got an idea... > > > > It helps if the process is started with the ADDR_COMPAT_LAYOUT personality > > flag set. > > We should still be reserving the high memory area, so it shouldn't > make any difference WRT ulimits. Something else must be going on here. Umm, I actually commented out this reservation in our RPMs *whistle innocently* :) If I add it back in the original behaviour (out of memory) is still there with or without my patch. Again I am out of ideas, short of writing WINEs own virtual memory manager. Ciao, Marcus

March 17, 2006

Re: PATCH: Re: Problem with virtual memory rlimits

by Alexandre Julliard

Marcus Meissner <meissner(a)suse.de> writes: > Got an idea... > > It helps if the process is started with the ADDR_COMPAT_LAYOUT personality > flag set. We should still be reserving the high memory area, so it shouldn't make any difference WRT ulimits. Something else must be going on here. -- Alexandre Julliard julliard(a)winehq.org

March 17, 2006

Re: wglMakeCurrent

by Wino Rojo

> >It is accelerated, and it uses Mesa too. If it wasn't, it would say >indirect renderer. oops, my mistake.. I missed the line "Direct Rendering: Yes" _________________________________________________________________ Powerful Parental Controls Let your child discover the best the Internet has to offer. http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=ht… Start enjoying all the benefits of MSN® Premium right now and get the first two months FREE*.

March 17, 2006

PATCH: Re: Problem with virtual memory rlimits

by Marcus Meissner

On Fri, Feb 24, 2006 at 02:12:46PM +0100, Marcus Meissner wrote: > Hi, > > I am having a problem with virtual ulimits/rlimits. > > If you limit the virtual memory size using "ulimit -v 1400000" for > instance, wine will only crash. > > The problem is, that VIRTUAL_alloc_teb() tries to allocate a memory > area within the acceptable userspace ... but it does so much mmap()s > that it runs out of available mmap space before. > > I was only able to reproduce this on AMD64 machines up to now, > which pass out memory starting from 0xf7fffffff somewhere. > > Any clue how to solve this? Got an idea... It helps if the process is started with the ADDR_COMPAT_LAYOUT personality flag set. So if we are running without it, we can just set the personality and execve ourselves. Btw, this trick might even help execshield and avoid the need for the preloader at all, but I do not have Fedora/Redhat here to test. Ciao, Marcus Changelog: Change to ADDR_COMPAT_LAYOUT personality to avoid problems with AMD64 memory layout and ulimits set. Index: loader/preloader.c =================================================================== RCS file: /home/wine/wine/loader/preloader.c,v retrieving revision 1.20 diff -u -r1.20 preloader.c --- loader/preloader.c 6 Feb 2006 13:35:58 -0000 1.20 +++ loader/preloader.c 17 Mar 2006 15:36:21 -0000 @@ -208,6 +208,14 @@ return SYSCALL_RET(ret); } +static inline int wld_personality( int perso ) +{ + int ret; + __asm__ __volatile__( "pushl %%ebx; movl %2,%%ebx; int $0x80; popl %%ebx" + : "=a" (ret) : "0" (SYS_personality), "r" (perso) ); + return SYSCALL_RET(ret); +} + static inline ssize_t wld_read( int fd, void *buffer, size_t len ) { int ret; @@ -226,6 +234,14 @@ return SYSCALL_RET(ret); } +static inline int wld_execve( const char * path, char **argv, char ** envp ) +{ + int ret; + __asm__ __volatile__( "pushl %%ebx; movl %2,%%ebx; int $0x80; popl %%ebx" + : "=a" (ret) : "0" (SYS_execve), "r" (path), "c" (argv), "d" (envp) ); + return SYSCALL_RET(ret); +} + static inline int wld_mprotect( const void *addr, size_t len, int prot ) { int ret; @@ -886,6 +902,7 @@ ElfW(auxv_t) new_av[12], delete_av[3], *av; struct wld_link_map main_binary_map, ld_so_map; struct wine_preload_info **wine_main_preload_info; + unsigned int perso; pargc = *stack; argv = (char **)pargc + 1; @@ -894,6 +911,14 @@ /* skip over the parameters */ p = argv + *pargc + 1; + perso = wld_personality(0xffffffff); + if (!(perso & 0x200000)) { + wld_personality(perso | 0x200000); + wld_execve(argv[0],argv,p); + fatal_error( "Failed execve %s\n", argv[0] ); + return NULL; + } + /* skip over the environment */ while (*p) {

March 17, 2006