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

Re: ntdll: Fix Directory Searching when VFAT_IOCTL_READDIR_BOTH returns an invalid d_reclen

by Alexandre Julliard

Robert Shearman <rob(a)codeweavers.com> writes: > No, the file it is searching for exists, but doesn't seem to be > returned by the ioctl for some reason. It is likely a x86-64 kernel > bug, but we should still fix in our code IMHO. Yes, but falling through to readdir when we reach the end of the directory is not correct behavior, it will cause every directory to be searched twice. This needs more investigation. -- Alexandre Julliard julliard(a)winehq.org

March 8, 2006

Re: WINED3D: Implement GetCreationParameters

by Alexandre Julliard

Peter Beutner <p.beutner(a)gmx.net> writes: > Or look at it from the view of a user developing a winelib application. I'm sure > he will very much appreciate it when wine does a better parameter checking than MS > and returns an error instead of a crash backtrace ;) > Imo a library is supposed to validate given parameters as much as possible and > rather return an error to the caller than to crash. It's just the opposite actually. A good library (which the MS ones certainly aren't...) should crash on bad pointers, so that bugs can be found and fixed. Hiding bugs and trying to stumble along is the MS way, this is what leads to idiocy like having an exception handler in lstrlen(). So if in this case Windows doesn't have a check we certainly don't want one either. -- Alexandre Julliard julliard(a)winehq.org

March 8, 2006

Re: System wide registry

by Stefan Dösinger

Hi, > In WINE user guide I read int the System Administration Tips > about global registry files (f.i. /usr/local/etc/wine.systemreg) > But I can't find any code in WINE about it. It is obsoleted now? > Is it possible to use system wide registry now? I created an /etc/wine directory with a system.reg, userdef.reg and dosdevices file, owned by a user "wine". In the other users .wine directory, there's a individual user.reg file, and a symlink to the files in /etc/wine/. The virtual c drive is in /opt/windows, owned by wine:users This way, there's a system-wide system.reg file, and wine is more or less the admistrator. The Linux file permissions prevent others from writing to /opt/windows and system.reg. An user can modify HKLM, but the changes won't get written to disk and get lost after his wine process terminates. Theoretically, you can use the root account instead of a special user, but it's highly discoraged to run wine as root, due to security concernes. You have to be aware that many Windows apps require full access to system directories or their install directories, but that's a problem Wine can't solve, and Windows suffers from that too.

March 8, 2006

Re: WINED3D: Implement GetCreationParameters

by Andreas Mohr

Hi, On Wed, Mar 08, 2006 at 02:08:52PM +0100, Peter Beutner wrote: > Imo a library is supposed to validate given parameters as much as possible and > rather return an error to the caller than to crash. We're not a library. We're a very, very, very, very specific piece of software that is required to absolutely, positively fully emulate Windows to the closest extent possible (within practical limits, of course). As such debating whether to delay a crash by adding useless checks *that do not exist in Windows*(!) to *work around* strange behaviour most likely caused by our own non-conformant code is utterly pointless. If there's a problem that we need to be aware of, then we'd better get to know about it NOW, not 5 lines, not 3000 relay lines and not 10 minutes after it occurred and nobody ever remembers what the actual problem was. Andreas Mohr

March 8, 2006

Re: WINED3D: Implement GetCreationParameters

by Kuba Ober

> Or look at it from the view of a user developing a winelib application. I'm > sure he will very much appreciate it when wine does a better parameter > checking than MS and returns an error instead of a crash backtrace ;) Ooooh, don't I smell bait-and-switch here? :) Always good to learn from your adversaries, right? Kuba

March 8, 2006

System wide registry

by Vitaly Lipatov

In WINE user guide I read int the System Administration Tips about global registry files (f.i. /usr/local/etc/wine.systemreg) But I can't find any code in WINE about it. It is obsoleted now? Is it possible to use system wide registry now? -- Lav Vitaly Lipatov Saint-Petersburg, Etersoft www.etersoft.ru GNU! ALT Linux Team! WINE! LaTeX! LyX!

March 8, 2006

Re: ntdll: Fix Directory Searching when VFAT_IOCTL_READDIR_BOTH returns an invalid d_reclen

by Robert Shearman

Alexandre Julliard wrote: >Robert Shearman <rob(a)codeweavers.com> writes: > > > >>--- a/dlls/ntdll/directory.c >>+++ b/dlls/ntdll/directory.c >>@@ -1245,7 +1245,11 @@ static NTSTATUS find_file_in_dir( char * >> unix_name[pos - 1] = '/'; >> for (;;) >> { >>- if (!de[0].d_reclen) break; >>+ if (!de[0].d_reclen) >>+ { >>+ unix_name[pos - 1] = 0; >>+ break; >> >> > >We should probably have a 'goto not_found' here instead. > No, the file it is searching for exists, but doesn't seem to be returned by the ioctl for some reason. It is likely a x86-64 kernel bug, but we should still fix in our code IMHO. -- Rob Shearman

March 8, 2006

Re: WINED3D: Implement GetCreationParameters

by Peter Beutner

Francois Gouget schrieb: > * or the application does not pass a NULL here because it would cause > it to crash on Windows. But if we merely return an error the application > will merrily go on, only to crash or report that DirectX does not work a > while later. By then the source of the problem will be very hard to find > due to all that happened since this function call. > The point is that we need to fix the bug that causes the application > to pass a NULL to Wine in the first place. And the best way to spot it, > and thus fix it, is if Wine segfaults in the same way as Windows when > given a NULL. The whole point of my email was that a crash here doesn't help you to find the real problem. It only says you that the function was called with a NULL pointer as parameter. Well, grepping through the trace log where a DirectX function returned an error most probably will get you the same result. And with the ERR() message that was in the original patch it would have been even easier to spot. Anyway both cases do _not_ tell you where things went wrong in the first place. You have to work through the whole trace log before that call to check where something wrong could have been returned. It might be even a bug in the application itself (e.g. forgotten check after malloc), who knows ... Or look at it from the view of a user developing a winelib application. I'm sure he will very much appreciate it when wine does a better parameter checking than MS and returns an error instead of a crash backtrace ;) Imo a library is supposed to validate given parameters as much as possible and rather return an error to the caller than to crash. But as the patch already was commited, I think any further discussion is pointless.

March 8, 2006

Re: linking errors in Winelib code (version 0.9.9) on Solaris 10

by Robert Shearman

Arun Kumar Khandelwal wrote: >I am compiling Winelib (version 0.9.9) on Solaris 10 machine. I am >getting below linking errors: > >gcc -c -I. -I. -I../../include -I../../include -I/usr/include/libxml2 >-I/usr/include/libxml2 -D__WINESRC__ -DCOM_NO_WINDOWS_H -D_REENTRANT >-fPIC -Wall -pipe -fno-strict-aliasing -gstabs+ >-Wdeclaration-after-statement -Wpointer-arith -g -O2 -o main.o main.c > >Undefined first referenced > symbol in file >GetStartupInfoA ../../dlls/libwinecrt0.a(exe_main.o) >GetModuleHandleA ../../dlls/libwinecrt0.a(exe_main.o) >GetCommandLineA ../../dlls/libwinecrt0.a(exe_main.o) >WinMain ../../dlls/libwinecrt0.a(exe_main.o) >ld: warning: Symbol referencing errors > > >Please suggest how to get rid of these errors. > I think you should be using winegcc. I'm afraid I don't know much more than that about winelib and the documentation is out of date so I can't refer you there. -- Rob Shearman

March 8, 2006

Re: Can't run DirectX games on x86_64 biarch Linux

by Willie Sippel

[...] > > Second, some programs run fine with wine, e. g. pcAnywhere. And some > games do start up and show the title menu (like StarCraft or AOE2), but > crash when selecting a game. > > Third, as I said before, I've compiled wine from source on a Pentium II > Debian box which doesn't even know what x86_64 is, and copied the > installation directory /opt/wine-CVS... to my x86_64 box. But that > didn't help. I also used the setarch-utility to make the Wine configure > script see an i686-machine, and setting the -m32 flags for GCC by hand, > but the effect was the same. I also build Wine on an amd64 system (running gentoo/ amd64), no problems. But there's one thing I noticed a while ago: Wine continues to compile and install even if some of the DLLs won't compile. I had this a few times in the past, and ended up with a basically working Wine install that missed a few DLLs, mostly OpenGL-related stuff. Maybe something like that happens to you? Just check that all DLLs are built and in place, and make sure there were no errors during compile (like I said, with some DLLs, Wine just continues to build even though errors appear)... Ciao, Willie -- Willie Sippel //////// | Tritium Studios // | ______________________________ //// /// | http://www.tritium-studios.com <willie(a)froq.net>

March 8, 2006

linking errors in Winelib code (version 0.9.9) on Solaris 10

by Arun Kumar Khandelwal

I am compiling Winelib (version 0.9.9) on Solaris 10 machine. I am getting below linking errors: gcc -c -I. -I. -I../../include -I../../include -I/usr/include/libxml2 -I/usr/include/libxml2 -D__WINESRC__ -DCOM_NO_WINDOWS_H -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -gstabs+ -Wdeclaration-after-statement -Wpointer-arith -g -O2 -o main.o main.c Undefined first referenced symbol in file GetStartupInfoA ../../dlls/libwinecrt0.a(exe_main.o) GetModuleHandleA ../../dlls/libwinecrt0.a(exe_main.o) GetCommandLineA ../../dlls/libwinecrt0.a(exe_main.o) WinMain ../../dlls/libwinecrt0.a(exe_main.o) ld: warning: Symbol referencing errors Please suggest how to get rid of these errors. Thanks and Regards, Arun Khandelwal

March 8, 2006

Re: Can't run DirectX games on x86_64 biarch Linux

by H. Verbeet

On 08/03/06, Christoph Frick <frick(a)sc-networks.de> wrote: > the vertex-shader there goes nuts (rainbow cars) and about 2/3 of the > textures looks like only one pixel-row of the texture is scaled over the > whole polygone. > > the game used to work completly before that change - except the shadows > and the overlayed textures for the instruments. I think Roderick mentioned that shaders are currently broken in d3d8 and that he was working on fixing them. @Christian: For what it's worth, I'm on AMD64 as well and it seems to work just fine. As Stefan said, you should probably verify that it link against the correct libraries (although I'm not sure if trying to link against 64-bit libs would even compile).

March 8, 2006

Re: Can't run DirectX games on x86_64 biarch Linux

by Christian Schneider

Am Mittwoch, den 08.03.2006, 10:20 +0100 schrieb Stefan Dösinger: > Hi, > > > > About half a year ago I replaced my old desktop by an AMD64 box and my > > > > previous x86 Linux from Scratch (LFS) installation by a x86_64 multilib > > > > LFS. And since then I'm not able to run any DirectX title anymore that > > > > used to work before. > > I tried, but it didn't help. I've also tried different audio outputs > > (ALSA and OSS), but the error messages are the same. > > > > Anyways, thanks for your reply. > It looks to me that something went wrong with compilation. Roderic does DX > development on an AMD64 machine without problems. Are you sure that Wine is > compiled for 32 Bit? The question is quite obvious, but yes, I am sure its 32-bit. First, the output of the following command is empty, so there are no 64-bit binaries in the wine directory: $ file /opt/wine/lib/{,wine/}*.so /opt/wine/bin/* | grep "64-bit" Second, some programs run fine with wine, e. g. pcAnywhere. And some games do start up and show the title menu (like StarCraft or AOE2), but crash when selecting a game. Third, as I said before, I've compiled wine from source on a Pentium II Debian box which doesn't even know what x86_64 is, and copied the installation directory /opt/wine-CVS... to my x86_64 box. But that didn't help. I also used the setarch-utility to make the Wine configure script see an i686-machine, and setting the -m32 flags for GCC by hand, but the effect was the same. > Perhaps some problem with the 32 bit libraries? In general 32-bit apps work fine on my machine. I can run Opera, Firefox, VMware 4.5, Quake III Arena, UT2004 and much other binary software without any problems. Are there some libs known to cause trouble with Wine? How can I check this? Cheers, Christian Schneider

March 8, 2006

Re: Can't run DirectX games on x86_64 biarch Linux

by Christoph Frick

On Wed, Mar 08, 2006 at 11:01:06AM +0100, Christian Schneider wrote: > > > As you can see, the most common errors are err:seh:setup_exception > > > and err:ntdll:RtlpWaitForCriticalSection. I've also done some more > > > tests with other games like Revolt, Anno 1503, Half-Life 2, and > > > the errors all look alike. > > anno 1503 never ever worked for me (there where some discussion > > about apps like this that follow a pattern with ddraw and threads, > > that wine might be able to handle (ever)). > I know that it's not supposed to work, but don't you think it's > strange that I only get two types of error messages with any game, > regardless if it's known to work or not? like Stefan i would also consider this more like a problem with the installation? i also run all the games on a opteron box with 64bit gentoo and manual compiled wine. i had no problems as i switched last year from the 32bit platform other then the problems i had beforehand. although anno1503 is the only game you mentioned, that is also on my list - beside that i know the following games work: black mirror, nibiru (demo) il2 (stormovik, foreign battles, aces, pacific fighters), jagged alliance 2, grand prix legends, baldurs gate2, planescape torement - and i have problems running ankh, raven shield, richard burns rally. -- cu

March 8, 2006

ole:ITypeInfo_fnInvoke, failed to convert param 0

by Tomas Carnecky

I got this when the WoW patcher started: err:ole:CoGetClassObject class {4955dd33-b159-11d0-8fcf-00aa006bcc59} not registered err:ole:CoGetClassObject no class object {4955dd33-b159-11d0-8fcf-00aa006bcc59} could be created for for context 0x1 fixme:ole:CoCreateInstance no classfactory created for CLSID {4955dd33-b159-11d0-8fcf-00aa006bcc59}, hres is 0x80040154 err:ole:ITypeInfo_fnInvoke failed to convert param 0 to VT_VARIANT|VT_BYREF from VT_VARIANT|VT_BYREF and the last line doesn't make sense to me, the patcher runs fine though... tom

March 8, 2006

Re: Problem while compiling wine-0.9.9 source on solaris

by Francois Gouget

On Tue, 7 Mar 2006, Vikas Gera wrote: [...] > I tried to build Wine Library on Solaris 10 platform today. It gave > error while compiling dll/dxerr8 module. > The error message says "Don't know how to make target: install-lib" [...] > But similar error message is getting repeated for other modules as well. > I would like to fix it in one shot, probably a fix in the configure > script is needed. Has anybody faced this problem and fixed it? Please > suggest. Are you using GNU make or the standard make? Switching to GNU make may help. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ The last time religion ruled, it was called the dark ages.

March 8, 2006

Re: WINED3D: Implement GetCreationParameters

by Francois Gouget

On Tue, 7 Mar 2006, Peter Beutner wrote: [...] > Unless some app relies on this crashing behaviour(which I doubt), I don't think wine > should implement bugs just because MS does it. > Seems a bit obscure strategy to me to crash in case of an error instead of proper > error checking/reporting. This has been discussed many times before (but maybe not in the recent past). There are two cases to consider: * either some applications do pass NULL thus causing a segfault and then expect to catch that exception. As you said, this is pretty unlikely here but it has happened with other (non-DirectX) APIs. In this case, then Wine must segfault too otherwise the application will fail. * or the application does not pass a NULL here because it would cause it to crash on Windows. But if we merely return an error the application will merrily go on, only to crash or report that DirectX does not work a while later. By then the source of the problem will be very hard to find due to all that happened since this function call. The point is that we need to fix the bug that causes the application to pass a NULL to Wine in the first place. And the best way to spot it, and thus fix it, is if Wine segfaults in the same way as Windows when given a NULL. So segfaulting like Windows does is really the right thing to do. It may warrant a comment in the code though, especially if there is a test with a message right before. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ You can have my guns when you pry them from my kids cold, dead hands.

March 8, 2006

Re: Can't run DirectX games on x86_64 biarch Linux

by Christian Schneider

Am Mittwoch, den 08.03.2006, 09:46 +0100 schrieb Christoph Frick: > On Wed, Mar 08, 2006 at 12:09:28AM +0100, Christian Schneider wrote: > > > As you can see, the most common errors are err:seh:setup_exception and > > err:ntdll:RtlpWaitForCriticalSection. I've also done some more tests > > with other games like Revolt, Anno 1503, Half-Life 2, and the errors > > all look alike. > > anno 1503 never ever worked for me (there where some discussion about > apps like this that follow a pattern with ddraw and threads, that wine > might be able to handle (ever)). > I know that it's not supposed to work, but don't you think it's strange that I only get two types of error messages with any game, regardless if it's known to work or not? Regards, Christian Schneider

March 8, 2006

Re: Can't run DirectX games on x86_64 biarch Linux

by Christoph Frick

On Wed, Mar 08, 2006 at 10:18:32AM +0100, Stefan Dösinger wrote: > > anno 1503 never ever worked for me (there where some discussion > > about apps like this that follow a pattern with ddraw and threads, > > that wine might be able to handle (ever)). > Anno 1503 is not multi threaded, I had the demo running, but it was > VERY slow. But there might be other glx context bugs i guess i have tried running this game over a year now - everytime it crashes at the exact same place (choosing a flag and then switching to "3d-mode"). last week i tar:ed it and gave up - now you tell me it works ;) btw: for all the d3d8 -> wined3d gurus out there another demo, that make trouble: http://www.liveforspeed.net/ the vertex-shader there goes nuts (rainbow cars) and about 2/3 of the textures looks like only one pixel-row of the texture is scaled over the whole polygone. the game used to work completly before that change - except the shadows and the overlayed textures for the instruments. -- cu

March 8, 2006

Re: Can't run DirectX games on x86_64 biarch Linux

by Stefan Dösinger

Hi, > > > About half a year ago I replaced my old desktop by an AMD64 box and my > > > previous x86 Linux from Scratch (LFS) installation by a x86_64 multilib > > > LFS. And since then I'm not able to run any DirectX title anymore that > > > used to work before. > I tried, but it didn't help. I've also tried different audio outputs > (ALSA and OSS), but the error messages are the same. > > Anyways, thanks for your reply. It looks to me that something went wrong with compilation. Roderic does DX development on an AMD64 machine without problems. Are you sure that Wine is compiled for 32 Bit? Perhaps some problem with the 32 bit libraries?

March 8, 2006

Re: Can't run DirectX games on x86_64 biarch Linux

by Stefan Dösinger

Hi, > anno 1503 never ever worked for me (there where some discussion about > apps like this that follow a pattern with ddraw and threads, that wine > might be able to handle (ever)). Anno 1503 is not multi threaded, I had the demo running, but it was VERY slow. But there might be other glx context bugs

March 8, 2006

Re: Can't run DirectX games on x86_64 biarch Linux

by Christian Schneider

Am Dienstag, den 07.03.2006, 16:39 -0700 schrieb Jesse Allen: > On 3/7/06, Christian Schneider <mail(a)chrschn.de> wrote: > > Hi all. > > > > About half a year ago I replaced my old desktop by an AMD64 box and my > > previous x86 Linux from Scratch (LFS) installation by a x86_64 multilib > > LFS. And since then I'm not able to run any DirectX title anymore that > > used to work before. > > > > > Try disabling the sound in winecfg. I tried, but it didn't help. I've also tried different audio outputs (ALSA and OSS), but the error messages are the same. Anyways, thanks for your reply. Cheers, Christian Schneider

March 8, 2006

Re: Can't run DirectX games on x86_64 biarch Linux

by Christoph Frick

On Wed, Mar 08, 2006 at 12:09:28AM +0100, Christian Schneider wrote: > As you can see, the most common errors are err:seh:setup_exception and > err:ntdll:RtlpWaitForCriticalSection. I've also done some more tests > with other games like Revolt, Anno 1503, Half-Life 2, and the errors > all look alike. anno 1503 never ever worked for me (there where some discussion about apps like this that follow a pattern with ddraw and threads, that wine might be able to handle (ever)). -- cu

March 8, 2006

Re: GDI32: [4/5] freetype.c add more font selecting&linking mechanism support.

by Byeong-Sik Jeon

Hi. I found another registry key in my korean MS Windows XP. ----------------------------------------------------- [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FontAssoc] [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FontAssoc \Associated Charset] "ANSI(00)"="YES" "OEM(FF)"="YES" "SYMBOL(02)"="NO" [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FontAssoc \Associated DefaultFonts] "AssocSystemFont"="gulim.ttc" "FontPackage"="GulimChe" "FontPackageDontCare"="굴림" "FontPackageRoman"="바탕" "FontPackageSwiss"="굴림" "FontPackageModern"="바탕" "FontPackageScript"="바탕" "FontPackageDecorative"="굴림" --------------------------------------------------------------- I think that create_child_font_list(), WineEngCreateFontInstance() have to this key. and then I can remove "defSystem" in all my patch(4/5 and 5/5). I working. but, create_child_font_list(), WineEngCreateFontInstance() will not create directly this key. I want your advice. Thanks. 2006-03-08 (수), 01:41 +0900, Byeong-Sik Jeon 쓰시길: > 2006-03-07 (화), 14:34 +0000, Huw D M Davies 쓰시길: > > On Tue, Mar 07, 2006 at 09:29:14PM +0900, Byeong-Sik Jeon wrote: > > > ChangeLog: > > > Improved create_child_font_list(), get_nearest_charset(), more using > > > font-linking mechanism. > > > > > > If lfCharSet == DEFAULT_CHARSET, then ALL font(LOGFONT) can see current > > > locale letter, (have to exist least one font corresponding current > > > locale ). > > > > > > > - If lfCharSet == DEFAULT_CHARSET then use the current locale codepage. > > > > and If selected font is not support current ansi codepage, then it fixup > > > > the problem in "create_child_font_list()" function. > > > > > > > > > > > I'm slightly confused about what you're trying to do here. Could you > > try to explain it again please? > > > Sorry, my poor english... > > assume "Arial.ttf" is exist in the system. > ------------------------------------------ > string = "Hello. 안녕하세요. 安寕"; /* include non-western character */ > > logfont.lfCharSet = DEFAULT_CHARSET; > logfont.lfFaceName = "Arial"; > hfont = CreateFontIndirect(&logfont); > SelectObject(hdc, hfont); > > TextOut(hdc, 10, 10, string, strlen(string)); > -------------------------------------------- > at this case, now Wine print out broken shape, because glyph missing on > Arial.ttf. > > font-linking mechanism help this situation. but need to > ------------------------------- > [HKLM\\...\SystemLink] > "Arial"="......" > -------------------------------- > New get_nearest_charset(), create_child_font_list() solve this situation > without any additional config file change. > > > > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/gdi/fontex… > ---------------------------------- > Windows NT/2000/XP: DEFAULT_CHARSET is set to a value based on the > current system locale. For example, when the system locale is English > (United States), it is set as ANSI_CHARSET. > ---------------------------------- > Korean locale => HANGEUL_CHARSET, > Japanese locale => SHIFTJIS_CHARSET. > .... > but, Arial.ttf is missing these charset, therefore incorrect operation > in the get_nearest_charset(). > > Sorry again. Please see the code.... > > > > Moving this TRACE is clearly not correct. > Yes. I mistake...

March 8, 2006

Re: WINED3D: Implement GetCreationParameters

by Vitaliy Margolen

Tuesday, March 7, 2006, 3:22:28 PM, Peter Beutner wrote: > H. Verbeet schrieb: >> On 07/03/06, Ivan Gyurdiev <ivg2(a)cornell.edu> wrote: >>> This doesn't really make sense to me - the point of unspecified behavior >>> if a parameter is NULL would be to speed up the function under contract >>> with the caller. If you're already doing the check, why not handle it in >>> some way other than crashing? >> Because we *want* to crash and get a nice backtrace. > hm maybe I'm missing something but afaik you will get a backtrace right back into the > application code, which will help you exactly nothing (unless you have the source > code of the game and the binary doesn't have its debugging information stripped > which is very likely not the case). > So you have to figure out where you might have returned something wrong by looking at > the traces from _before_ GetCreationParameters. > The backtrace itself won't give you _any_ clues. > Unless some app relies on this crashing behaviour(which I doubt), I don't think wine > should implement bugs just because MS does it. > Seems a bit obscure strategy to me to crash in case of an error instead of proper > error checking/reporting. If anything Wine does crash in much more cases then native. Look at all the ntdll functions. Native never crash there (because all those are direct kernel calls). Wine on the other hand will crash whenever you have a bad pointer dereference. So I don't see any reasons why we should check for NULL pointer here. It will still crash if pointer is bogus, but not NULL. Also having a crash in a debug trace helps to find the place where did it crash. If Wine just returns from this function, you never know where it will cause the real problem. Vitaliy.

March 8, 2006