gerard patel g.patel at
Fri Aug 31 14:51:16 CDT 2001

On Fri, 31 Aug 2001 16:26:47 +0200, giorgian <giorgian at>

>ok, let see it from a different point of view:
>the application works under windows, crashes under wine, whatever it 
>stores or not.
>so, the problem cannot be the application itself, the problem is that 
>wine doesn't behave as windows (USER32.DLL) does.

Well, yes.

>how can we find out whether:
>- GetWindowLong doesn't return the right value, or

Very unlikely, else almost no complex application
would work correctly (Set/GetWindowLong are used

>- someone else corrupts that data, writing some garbage on it?

Because of some Wine problem, the app does not
go through a code branch where this data is 
initialized. Or - much more unlikely - the data
is initialized but Wine goes through a code branch
where this data is reset.

The problem is to find where and why.
This kind of bug can be very difficult to fix.

If you need absolutely this app, I see the
following ideas :

- understand completely what the app is
doing from the existing trace.

- go back to a very old version of Wine where
'native' user32.dll from Win9x could be loaded and
trace under it - *if* it works, you could see where 
is the call to SetWindowLong for the appropriate
- trace the called Apis under Windows - IIRC 
some tool was said to exist on wine-devel.

With options 2 & 3 you compare the correct flow
execution with the flawed one of Wine - then when
you have found the point where Wine forks, you
have to understand why.


More information about the wine-users mailing list