GetWindowLongA

[Andreas Mohr Usenet 08/01]

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