Patrik Stridvall <[EMAIL PROTECTED]> writes:
> Notice that in the if1632/user.spec EnumWindows points
> to THUNK_EnumWindows16 defined in if1632/thunk.c.
> Also notice that THUNK_EnumWindows16 allocates a thunk
> and then calls the real EnumWindows16 function.
Exactly my point. When we have an x86 emulator a call to EnumWindows
from x86 code will jump to a THUNK_EnumWindowsx86 that will allocate a
thunk and call the real EnumWindows.
> But there is even more difficult cases. The data structure
> WNDCLASS contains a WNDPROC function pointer so there
> is quite a lot of code in windows/winproc.c to handle this.
WNDPROCs are different because you need to handle the 16/32
distinction in the message type, so you have to know what kind of
function you are calling.
> Thus each indirect call is handled explictly by Win16 thunking
> and this will be the case for my problem too AFAICS.
Of course the calls are handled explicitly, but in the Win16
layer. And the calls to/from the emulator will be handled in the
emulator layer.
> So I still wonder what super solution you have for the problem
> and why it wasn't used to implement Win16 thunking.
Maybe you should instead explain to us what _your_ solution is to fix
what you perceive as a problem?
--
Alexandre Julliard
[EMAIL PROTECTED]
