> Patrik Stridvall <psÉleissner.se> writes:
>
> > Perhaps, even though I very much doubt that, you have a very
> > clever solution for the problem. In that case I am _very_ intrested.
> > Care to elaborate?
>
> Check how we do it for the 16-bit case. This is exactly the same
> thing. Both 16->32 and 32->16 calls go through a thunking layer, and
> the standard Wine code is simply calling functions pointers,
> completely unaware that a transition to 16-bit code may take place.
Yes, that will (and does for Win16) work fine for _direct_ calls.
But they are not the real problem.
The real problem is the indirect calls.
Like the Enum* function. Let take EnumWindows as example:
BOOL EnumWindows(WNDENUMPROC lpEnumFunc, LPARAM lParam);
If I call it from an internal (non-x86 or cdecl) function
lpEnumFunction will get a pointer to a (non-x86 or cdecl) function.
If I call it from an external (x86 or stdcall) function I will
lpEnumFunction will get a pointer to a (x86 or stdcall) function.
Notice the assymmetry. But let not get too theoretical.
Let look how Win16 thunking handles this instead.
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.
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.
Thus each indirect call is handled explictly by Win16 thunking
and this will be the case for my problem too AFAICS.
In short, your claim that, I qoute, "there is no need to change a
single line of the standard Wine code for this" does not have
AFAICS any support neither in theory nor in practice.
So I still wonder what super solution you have for the problem
and why it wasn't used to implement Win16 thunking.
