[prev in list] [next in list] [prev in thread] [next in thread] 

List:       wine-devel
Subject:    RE: PageMaker and thunking
From:       Patrik Stridvall <ps () leissner ! se>
Date:       2000-08-28 11:59:43
[Download RAW message or body]

> I'm still trying to solve problems with PageMaker and thunking...

OK.
 
> Assuming, that problems arise with using 
> QT_Thunk/SMapLS_IP_EBP_8/SUnMapLS_IP_EBP_8
> functions (i.e. Win95 thunks), I guessed that -winver nt40 
> will solve at least some
> part of the problem

Reasonable guess IMHO.

> But PM always used Win95 thunks: with 
> nt40 or win95. Traces
> showed, that PM uses GetProcAddress to decide, which type of 
> thunking to use.
> After commenting mentioned above functions in kernel32.spec, 
> it confirmed my guess,
> and PM now opens and actually draws the whole page layout! 

Oh no, please spare me, that was the most ugly kludge I have
seen in a long time.

> Though some problems
> persist (with Syslevel locking in PlayMetaFile for instance), 
> but progress is here!

OK. But this is unrelated I guess?

> Now I'm in embarrassment: to really continue hacking 
> PageMaker, I need to choose
> some way: either try to solve problems with Win95-type 
> thunking (but nobody except
> Andreas Mohr actually tried to help me with absolutely 
> unknown for me subject), or

I read the message, but I didn't understand what the problem
was so I hoped somebody else would help you.

Now I think I understand though.

Hmm. Even if we take the strict view that applications not
working under Windows NT is not supported by Wine your
application doesn't fail that criteria so we should IMHO do
something to make it work.

> try to implement some sort of hack around GetProcAddress to 
> simulate presence and
> absence of the bunch of functions. The latter is very 
> obscured idea and I don't
> like it.

The idea in itself is not that obscure. However GetProcAddress
obvious can't contain specific hacks for specific modules.

What we should do IMHO is to extend the spec file format to
handle the case where API:s only exists on specific platforms.

The logic for supporting this could be done where
SNOOP_GetProcAddress is called. In fact the calling
inferface would be identical. Instead of returning a "thunk"
like SNOOP_GetProcAddress it will return either the function
itself or NULL if it doesn't exist on this OS version. Just
lookup in a table exactly like SNOOP_GetProcAddress
does.

Note that this solution doesn't support having different
ordinals for different OS versions but that is not nessary
for the problem above. I'm not sure that will ever be needed.

Instead of
@ stdall Foo(ptr long) Foo

We could have
@[win95,win98] stdcall Foo(ptr long) Foo
and
@[!win95,!nt351] stdcall Foo(ptr long) Foo

The first means that the function only exist on win95 and win98
and the second mean that it exist on all OS versions except
win95 and nt351.

The first case is for support legacy function that have been
discontinued. The second case is for supporting future
extentions without having to change the spec file for each
new OS version. OK that doesn't happend that often but
it is good to think ahead.

What do you think? Implementing this should not be very hard.

[prev in list] [next in list] [prev in thread] [next in thread]