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 17, 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 17, 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 17, 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 17, 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 17, 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 17, 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 17, 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 17, 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

A few apps Munich was interested in

by Dan Kegel

I've been trying to figure out why Munich doesn't like Wine for some time. Here's what I've learned: In 2004 six apps were briefly tested by ITOMIG under both plain Wine and Crossover Office 3.0.1 as part of initial studies for the Munich migration to Linux. The test results aren't especially important (wine has progressed since then), but it's interesting to know which apps were tested. Here's a list of the apps, along with links to related Wine bugs. SPSS11 - statistics http://spss.com (free trial!) Bugs: http://bugs.winehq.org/show_bug.cgi?id=3038 (multiple problems) http://bugs.winehq.org/show_bug.cgi?id=2953 (Sun's JVM crashes on trivial app, fixed?) http://bugs.winehq.org/show_bug.cgi?id=4860 (Sun's JVM doesn't work for applet, not really related, but an indication that java isn't happy) Keeptool5-Hora - Entity Relationship diagrammer, SQL debugger http://keeptool.com/de/keeptool_hora.php (free trial!) Bugs: http://bugs.winehq.org/show_bug.cgi?id=4801 (app locks up on some systems?) http://bugs.winehq.org/show_bug.cgi?id=4802 (Oracle client library won't install) Frontpage2000 - Microsoft Office 2000's html editor Mephisto - a specialized app built using MS Access Darwin - a specialized app used in tourism offices; needs a dongle (For more info, contact stefan.munz at itomig.de.) Until apps like these work well under Wine, cities like Munich are unlikely to use Wine as part of their migration to Linux desktops. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

March 17, 2006

Re: My two cents about winetools and the suggestions I read in Issue 308

by Dan Kegel

On 3/17/06, Joachim von Thadden <thadden(a)web.de> wrote: > Am Do, Mär 16, 2006 at 11:41:53 -0800 schrieb Dan Kegel: > > Instead, it should just be a couple of checkboxes for > > optional things like dcom98 and IE6, shouldn't it? > > I think this is not enough. After you installed IE6 how do you want to > disable it? Many apps are looking directly for it. They will behave > different in that case. Or did I misunderstood? Once you've installed IE6 or dcom98, they're there for good. I just want to make sure you don't encourage users to install them. One other thing we need is an easy way to defeat those checks for particular versions of IE. For instance, many apps check one registry key, and some apps check for one particular DLL (it can be zero size, even!). Wine itself should probably come with a shell script that creates these, and wineconf and/or your tool should provide an easy way to run it... - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

March 17, 2006

Wine and RDPRINT

by Frederico Bertucci

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 -- Frederico Bertucci e-mail / msn: fred(a)netbil.com.br www.netbil.com.br NetBil - Redes e Internet 18-3659-2444 XxX Linux for work Linux for fun XxX ________________________________________________ :: NetBil :: :: A escolha certa em Internet ::

March 17, 2006

Re: Add a test for bitmap font metrics to ensure that they match the Windows ones

by Dmitry Timoshkov

"Huw Davies" <huw(a)codeweavers.com> wrote: >> Looks like it's a sfnt2fnt bug and not a fontforge or FreeType problem. >> >> This patch tests bitmap font metrics to ensure that they match the Windows >> ones. The patch discovers a bug in sfnt2fnt which causes Courier font to >> have wrong ascent and descent values (13/0 instead of 11/2). courier.ttf >> generated by fontforge from courier.sfd has correct values, but courier-*.fnt >> files have wrong values. > > Well we get the ascent from the height of the Aring glyph. As far as > I can tell this is 11 in fontforge. So somewhere between fontforge's > export as a ttf and sfnt2fnt reading that ttf (using FreeType) the > value has changed to 13. Hence my comment that either fontforge or > FreeType is doing something odd. I was going to point out that I tried to replace in tools/sfnt2fnt.c ascent = face->glyph->metrics.height >> 6; by ascent = face->size->metrics.ascender >> 6; which is what is used in dlls/gdi/freetype.c,get_bitmap_text_metrics(), but that breaks MS Sans Serif bitmap fonts. It looks like fontforge doesn't allow to have a different font header for each different bitmap size in the bitmap font. -- Dmitry.

March 17, 2006

Re: Add a test for bitmap font metrics to ensure that they match the Windows ones

by Huw Davies

On Fri, Mar 17, 2006 at 02:01:41PM +0800, Dmitry Timoshkov wrote: > "Huw D M Davies" <h.davies1(a)physics.ox.ac.uk> wrote: > > > Looks like this might be a fontforge or FreeType problem. Windows > > courier at 13 ppem should have an ascent of 11 and a descent of 2, > > which is what we have in the .sfd. Now, when I run sfnt2fnt on the > > generated .ttf I get an ascent of 13, ppem of 13 and hence a descent > > of 0. > > > > I'm not going to have time to look into this soon, so please feel free > > to investigate more. > > Looks like it's a sfnt2fnt bug and not a fontforge or FreeType problem. > > This patch tests bitmap font metrics to ensure that they match the Windows > ones. The patch discovers a bug in sfnt2fnt which causes Courier font to > have wrong ascent and descent values (13/0 instead of 11/2). courier.ttf > generated by fontforge from courier.sfd has correct values, but courier-*.fnt > files have wrong values. Well we get the ascent from the height of the Aring glyph. As far as I can tell this is 11 in fontforge. So somewhere between fontforge's export as a ttf and sfnt2fnt reading that ttf (using FreeType) the value has changed to 13. Hence my comment that either fontforge or FreeType is doing something odd. Huw. -- Huw Davies huw(a)codeweavers.com

March 17, 2006

Re: opengl32: make the old code before the "sync the dibsection to its pixmap" patch be selectable at runtime

by Mike Hearn

There's a new patch to try here: http://plan99.net/~mike/files/glteb.patch Does that work any better?

March 17, 2006

Re: riched20: add EM_EXSETSEL conformance tests and fixes bug 4462

by brianch＠seas.ucla.edu

Indeed. Thanks for pointing that out. The modifications will be made and posted. > On Thu, 16 Mar 2006 22:31:40 -0800 (PST) > Brian Chang <brianch(a)seas.ucla.edu> wrote: > >> + /* get the current selection and text length */ >> + RichEditANSIWndProc(hWnd, EM_GETSEL, (WPARAM) &start, (LPARAM) >> &end); >> + textlen = RichEditANSIWndProc(hWnd, WM_GETTEXTLENGTH, 0, 0); > > This looks strange... Why not use ME_GetSelection() and > ME_GetTextLength()? > > -- Ph. > >

March 17, 2006

Re: riched20: add EM_EXSETSEL conformance tests and fixes bug 4462

by Brian Chang

Hi Dan, Thanks again for the suggestions. I did indeed run the conformance tests on Windows -- passes with no problem. The conformance tests confirm that the return value is not the range. Good catch for the limiting of cpMax, it simplified the return logic. I also fixed the whitespace violations I found. Brian Dan Kegel wrote: >Nice touch including the link to the bug! > >Did you run the new test on Windows? > >+ if(range.cpMin < 0) >+ { >+ range.cpMin = end; >+ range.cpMax = end; >+ } >+ ... >+ >+ return (range.cpMax < textlen+1 ? range.cpMax : textlen+1) ; > >MSDN says the return value is the range, not just cpMax. Are they really wrong? >Also, I suspect you want to limit cpMax at the same time as you do cpMin, >not after the fact... otherwise aren't you passing an invalid cpMax to >ME_SetSelection() ? > >Finally, there are trivial whitespace style violations, I think >(missing space between if and the open paren). >- Dan > >-- >Wine for Windows ISVs: http://kegel.com/wine/isv > >

March 17, 2006

Re: wglMakeCurrent

by Raphael

On Thursday 16 March 2006 10:21, Wino Rojo wrote: > Hi Raphael, > > >No it's use the "best visual" who match asked capacities > > - is this "best visual" the same as the one returned by "glxinfo -b" ? no the best matching caps asked by wine init (see X11DRV_setup_opengl_visual on x11drv/opengl.c and x11drv/x11drv_main.c) > - the capacities asked by who? at this point we haven't call > ChoosePixelFormat or SetPixelFormat yet Yes, but wine init need to setup a default visual at startup :( (and too many times it'll not compatible with future created visuals) > >No your problem don't seems to be here. > >can you send you glxinfo output. I presume you don't have glx1.3 support > >In this case wine don't be able to get a fb config compatible with wine > >window > >(one day we'll fix the wine init ...) > > This is the output of my glxinfo: > > According to this, I do have glx 1.3 Strange ... need to investigate what happened :( > Thanks, > > W. > Regards, Raphael > > PS. Guys, I'm sorry if I'm asking too many basic questions. I know about > OpenGL and some X-Window programming, but I'm just learning wine, and I'd > like to contribute to this amazing project, especially with the OpenGL/3D > graphics stuff. No problem, it's always good to see more people working on wine (specially directX/Opengl) :) I have no time to improve wine now but i have little time sufficient for mails :p

March 17, 2006

Re: My two cents about winetools and the suggestions I read in Issue 308

by Joachim von Thadden

Am Do, Mär 16, 2006 at 11:41:53 -0800 schrieb Dan Kegel: > Instead, it should just be a couple of checkboxes for > optional things like dcom98 and IE6, shouldn't it? I think this is not enough. After you installed IE6 how do you want to disable it? Many apps are looking directly for it. They will behave different in that case. Or did I misunderstood? Regards Joachim von Thadden -- "Never touch a running system! Never run a touching system? Never run a touchy system!!!"

March 17, 2006

re: riched20: add EM_EXSETSEL conformance tests and fixes bug 4462

by Dan Kegel

Nice touch including the link to the bug! Did you run the new test on Windows? + if(range.cpMin < 0) + { + range.cpMin = end; + range.cpMax = end; + } + ... + + return (range.cpMax < textlen+1 ? range.cpMax : textlen+1) ; MSDN says the return value is the range, not just cpMax. Are they really wrong? Also, I suspect you want to limit cpMax at the same time as you do cpMin, not after the fact... otherwise aren't you passing an invalid cpMax to ME_SetSelection() ? Finally, there are trivial whitespace style violations, I think (missing space between if and the open paren). - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

March 17, 2006

Re: My two cents about winetools and the suggestions I read in Issue 308

by Dan Kegel

On 3/16/06, Joachim von Thadden <thadden(a)web.de> wrote: > > >This is exactly what we try to have with the next version of WineTools. > > > > Right, but Mike meant "without installing any Microsoft libraries". > > Sure, that's why we integrate a "native Wine" mode. > > I think we are looking in the same direction now. Now you're talking! But I think it shouldn't really be a mode. Instead, it should just be a couple of checkboxes for optional things like dcom98 and IE6, shouldn't it? - Dan

March 17, 2006

Re: My two cents about winetools and the suggestions I read in Issue 308

by Joachim von Thadden

Am Do, Mär 16, 2006 at 05:13:15 -0800 schrieb Dan Kegel: > Joachim wrote: > >> IMO, the best thing for Wine would be to have a simple front end with a > >> list of freely downloadable applications that work "out of the box" with > >> no configuration changes. > >> > >> Click -> Download application -> Install -> Run > > > >This is exactly what we try to have with the next version of WineTools. > > Right, but Mike meant "without installing any Microsoft libraries". Sure, that's why we integrate a "native Wine" mode. I think we are looking in the same direction now. Regards Joachim von Thadden -- "Never touch a running system! Never run a touching system? Never run a touchy system!!!"

March 17, 2006

Re: riched20: add EM_EXSETSEL conformance tests and fixes bug 4462

by Phil Krylov

On Thu, 16 Mar 2006 22:31:40 -0800 (PST) Brian Chang <brianch(a)seas.ucla.edu> wrote: > + /* get the current selection and text length */ > + RichEditANSIWndProc(hWnd, EM_GETSEL, (WPARAM) &start, (LPARAM) &end); > + textlen = RichEditANSIWndProc(hWnd, WM_GETTEXTLENGTH, 0, 0); This looks strange... Why not use ME_GetSelection() and ME_GetTextLength()? -- Ph.

March 17, 2006

re: My two cents about winetools and the suggestions I read in Issue 308

by Dan Kegel

Joachim wrote: >> IMO, the best thing for Wine would be to have a simple front end with a >> list of freely downloadable applications that work "out of the box" with >> no configuration changes. >> >> Click -> Download application -> Install -> Run > >This is exactly what we try to have with the next version of WineTools. Right, but Mike meant "without installing any Microsoft libraries". - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

March 16, 2006

Re: wglMakeCurrent

by Jesse Allen

On 3/16/06, Wino Rojo <winorojo(a)hotmail.com> wrote: > Interesting... according to your log file, it seems you are using Mesa > instead of any ATI accelerated driver. > > It is accelerated, and it uses Mesa too. If it wasn't, it would say indirect renderer.

March 16, 2006

Re: opengl32: make the old code before the "sync the dibsection to its pixmap" patch be selectable at runtime

by Mike Hearn

On Thu, 16 Mar 2006 09:27:42 +0100, Leon Freitag wrote: > I'm getting undefined references to `___tls_get_addr' when trying to build > with this patch. However my ld has this symbol for sure... Odd. Worked for me, but it's probably something to do with the Wine build system. Here's a version that properly uses the TEB. Does it work any better? diff --git a/dlls/opengl32/Makefile.in b/dlls/opengl32/Makefile.in diff --git a/dlls/opengl32/wgl.c b/dlls/opengl32/wgl.c index 56c8ad1..71f7511 100644 --- a/dlls/opengl32/wgl.c +++ b/dlls/opengl32/wgl.c @@ -31,6 +31,8 @@ #include "winerror.h" #include "winreg.h" #include "wingdi.h" +#include "winternl.h" +#include "winnt.h" #include "wgl_ext.h" #include "opengl_ext.h" @@ -82,6 +84,7 @@ typedef struct wine_glcontext { XVisualInfo *vis; GLXFBConfig fb_conf; GLXContext ctx; + BOOL do_escape; struct wine_glcontext *next; struct wine_glcontext *prev; } Wine_GLContext; @@ -96,18 +99,13 @@ static inline Wine_GLContext *get_contex void enter_gl(void) { - GLXContext gl_ctx; - Wine_GLContext *ctx; - enum x11drv_escape_codes escape = X11DRV_SYNC_PIXMAP; - - wine_tsx11_lock_ptr(); - gl_ctx = glXGetCurrentContext(); - if(!gl_ctx) return; - ctx = get_context_from_GLXContext(gl_ctx); - wine_tsx11_unlock_ptr(); /* unlock before calling GDI apis */ - - if(ctx && GetObjectType(ctx->hdc) == OBJ_MEMDC) - ExtEscape(ctx->hdc, X11DRV_ESCAPE, sizeof(escape), (LPCSTR)&escape, 0, NULL); + Wine_GLContext *curctx = (Wine_GLContext *) NtCurrentTeb()->glContext; + + if (curctx && curctx->do_escape) + { + enum x11drv_escape_codes escape = X11DRV_SYNC_PIXMAP; + ExtEscape(curctx->hdc, X11DRV_ESCAPE, sizeof(escape), (LPCSTR)&escape, 0, NULL); + } wine_tsx11_lock_ptr(); return; @@ -541,6 +539,7 @@ BOOL WINAPI wglMakeCurrent(HDC hdc, ENTER_GL(); if (hglrc == NULL) { ret = glXMakeCurrent(default_display, None, NULL); + NtCurrentTeb()->glContext = NULL; } else { Wine_GLContext *ctx = (Wine_GLContext *) hglrc; Drawable drawable = get_drawable( hdc ); @@ -571,8 +570,12 @@ BOOL WINAPI wglMakeCurrent(HDC hdc, } TRACE(" make current for dis %p, drawable %p, ctx %p\n", ctx->display, (void*) drawable, ctx->ctx); ret = glXMakeCurrent(ctx->display, drawable, ctx->ctx); + NtCurrentTeb()->glContext = ctx; if(ret && type == OBJ_MEMDC) + { + ctx->do_escape = TRUE; glDrawBuffer(GL_FRONT_LEFT); + } } LEAVE_GL(); TRACE(" returning %s\n", (ret ? "True" : "False"));

March 16, 2006

rpaths not working?

by Mike Hearn

Hi Alexandre, On my system at least it seems DLLs need the rpaths too, from a clean build of HQ git tree I get this when starting: 8697: file=/opt/wine/lib/wine/ntdll.dll.so [0]; needed by /opt/wine/bin/../lib/libwine.so.1 [0] 8697: file=/opt/wine/lib/wine/ntdll.dll.so [0]; generating link map 8697: dynamic: 0x7ffd52dc base: 0x7ff63000 size: 0x0007cb58 8697: entry: 0x7ff6f000 phdr: 0x7ff63034 phnum: 5 8697: 8697: 8697: file=libwine_unicode.so.1 [0]; needed by /opt/wine/lib/wine/ntdll.dll.so [0] 8697: 8697: file=/opt/wine/lib/wine/ntdll.dll.so [0]; destroying link map wine: failed to initialize: libwine_unicode.so.1: cannot open shared object file: No such file or directory 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? thanks -mike

March 16, 2006

getwinegit.sh 0.3 released!

by Christian Lachner

Weehaa, my getwinegit.sh-script now reached a next major version-step! It's not perfect but it should do it's job very smoothly. Here's, what has changed: 0.3_Yea, new features and some fixes ;) - Mode 4: installs an already compiled source - fixed a bug when mode was 3 and the target-dir was _not_ found - Now uses PID-Files to ensure, that getwinegit.sh does not run twice - very small enhancements in logger - Logfile is now stored at /var/log/ as default - small stuff I don't remember... again... - Granatenstark, Hoschi! ;) (who of you german speakings know bill and ted?) This release is meant to be a stable-version. IF there are bugs, then post them to wine-users. Questions? PLEASE read the readme-file and if you really can't sort things out, post to wine-users. Ok, that's it for now. greets, chris

March 16, 2006

re: riched20: implement EM_FINDWORDBREAK and its tests

by Dan Kegel

Brian Chang wrote: > ... > +#include <wctype.h> http://www.winehq.org/pipermail/wine-devel/2006-March/045373.html says: You can't use anything from wctype.h in Wine. Use the functions from wine/unicode.h instead. >+ /* Windows returns 0 if start is negative and len+1 if start is >= len */ >+ if(code != WB_ISDELIMITER) >+ { >+ if(start < 0) >+ return 0; >+ if(start > len) >+ return len+1; >+ } Do you test that in your conformance test? If not, please do. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

March 16, 2006

fonts

by Mihael Simonic

I am test to install Google Earth. It is work, but fonts not show. problem 1: how I configure fonts problem 2: not file (library) /system32/psapi.dll Greetings, Miha

March 16, 2006

Re: GDI32: Fix logical error of italic,bold determination

by Byeong-Sik Jeon

2006-03-15 (수), 14:50 +0000, Huw D M Davies 쓰시길: > On Mon, Mar 13, 2006 at 04:10:04AM +0900, Byeong-Sik Jeon wrote: > > ChangeLog: > > Fix the logical error of the italic, bold determination. > > > > Index: dlls/gdi/freetype.c > > =================================================================== > > RCS file: /home/wine/wine/dlls/gdi/freetype.c,v > > retrieving revision 1.114 > > diff -u -u -r1.114 freetype.c > > --- dlls/gdi/freetype.c 9 Mar 2006 12:30:52 -0000 1.114 > > +++ dlls/gdi/freetype.c 12 Mar 2006 10:01:22 -0000 > > + for(i = 0; !face && i < 4; ++i) { > > best = NULL; > > LIST_FOR_EACH(face_elem_ptr, &family->faces) { > > face = LIST_ENTRY(face_elem_ptr, Face, entry); > > - if((csi.fs.fsCsb[0] & (face->fs.fsCsb[0] | face->fs_links.fsCsb[0])) || !csi.fs.fsCsb[0]) { > > + if((!(face->Italic ^ it) ^ ((i >> 1) & 1)) && (!(face->Bold ^ bd) ^ (i & 1)) && > > + ((csi.fs.fsCsb[0] & (face->fs.fsCsb[0] | face->fs_links.fsCsb[0])) || !csi.fs.fsCsb[0])) { > > > It doesn't seem right to compare these with 'i', the order of the faces is random. > > The right way to do this is to rewrite all this font matching code so > that we loop through the families and faces once and score each one. > At the end we pick the one with the lowest score. > > Huw. Hi. I'm late... A B A xor B 0 0 0 0 1 1 1 0 1 1 1 0 ===> 0 ^ A == A ^ 0 == A, 1 ^ A == A ^ 1 == !A This code is just a compression of my old patch [3/5]. but, this dirty code did not satisfy me too. I will rework this and others(FT_Bitmap_Convert, FT_Sfnt_Name). Thanks your advice. :)

March 16, 2006

Re: build stand alone binaries

by Tom Wickline

On 3/16/06, Dimi Paun <dimi(a)lattica.com> wrote: > From: "Benjamin Zeller" <zeller.benjamin(a)web.de> > > is it possible to build real elf binaries with winelib? > > If i go through the tutorial on winehq.org i get only a appname.exe.so > > and i have to invoke wine to start the application. > > Is it possible to compile a binary wich can run stand alone? > > No, you would still need the DLLs. It's like having a Win32 binary > that includes _all_ the DLLs that come with Windows. Also: http://winehq.org/site/docs/wine-faq/index See 9.4 Tom > > -- > Dimi Paun <dimi(a)lattica.com> > Lattica, Inc. > > >

March 16, 2006

Re: build stand alone binaries

by Dimi Paun

From: "Benjamin Zeller" <zeller.benjamin(a)web.de> > is it possible to build real elf binaries with winelib? > If i go through the tutorial on winehq.org i get only a appname.exe.so > and i have to invoke wine to start the application. > Is it possible to compile a binary wich can run stand alone? No, you would still need the DLLs. It's like having a Win32 binary that includes _all_ the DLLs that come with Windows. -- Dimi Paun <dimi(a)lattica.com> Lattica, Inc.

March 16, 2006

Re: wglMakeCurrent

by Wino Rojo

Interesting... according to your log file, it seems you are using Mesa instead of any ATI accelerated driver. >From: "Jesse Allen" <the3dfxdude(a)gmail.com> >To: "Wino Rojo" <winorojo(a)hotmail.com> >Subject: Re: wglMakeCurrent >Date: Wed, 15 Mar 2006 11:45:16 -0700 > > > > > > > Jesse, I can't access your log at that page (I got an error). Could you > > please send it to me? > > > > Thanks, > > > > W > >attachment ><< logfile >> _________________________________________________________________ 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 16, 2006