Andreas Mohr Usenet 08/01
vooe7o001 at sneakemail.com
Fri Aug 31 17:32:40 CDT 2001
giorgian <giorgian at icube.it> wrote:
> Ove Kaaven wrote:
>>GetWindowLong with offsets >= 0 is application-managed storage. The
>>application stores whatever it likes there using SetWindowLong. If the app
>>didn't store anything there yet (or stored a null pointer there), you
>>should figure out why it didn't.
> 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.
> how can we find out whether:
> - GetWindowLong doesn't return the right value, or
Very unlikely, as others already pointed out.
> - someone else corrupts that data, writing some garbage on it?
Rather unlikely, too.
I think the same: code path doesn't get triggered.
Or some Wine function returned NULL which the app then dutifully put in that
app storage field ;)
You could run --debugmsg +loaddll and use a different mix of native/builtin
DLLs until it hopefully runs and you know which DLL has a problem.
Then compare the behaviour until you find the bug inside that DLL.
You could also buy an app called APIS32 (see internet).
This is less than $20 or so.
This app allows you to trace function calls on Windows.
With a bit of luck you'll be able to find out why it works on Windows
and doesn't on Wine.
Andreas Mohr, Renningen, Germany
In case you need to contact me after expiry of temporary email address:
my real address is (initial of first name).(last name)@mailto.de
More information about the wine-users