> Patrik Stridvall <psÉleissner.se> writes:
>
> > We don't need to go that far to encounter problem.
> > Just change the #define __stdcall to the empty define
> > and we will get plenty of problems that also will
> > exist with the emulator.
>
> It is absolutely not clear that they are the same problems, or that
> they need the same solution.
>
> If you want to support compilers without stdcall, fine go ahead, but
> you better find a way to do it with only minimal impact on the code,
> because it is a very low priority feature.
>
> If you want to support an x86 emulator, fine, you are allowed to do
> more extensive changes because it is a feature more people want. If it
> then turns out your emulator support can also be used to fix the
> stdcall issue, great. But trying to use the emulator as an excuse to
> push the stdcall changes is not going to work.
Ah, OK. Now I understand, you don't they are the same problem?
Perhaps I have missed something, but AFAICS it is obvious
that they are the same problem.
The trick is to allocate/deallocte the thunks are the right time,
so when thunk is called insteed of whatever can't be called directly
be it x86 code on non-x86 or be it a stdcall function when it
expects a cdecl function.
Once you get to the thunk, it doesn't matter if you rearange
the arguments for a stdcall or if you call the emulator
or if you do a IA-64 to/from IA-32 on Itanium or whatever
you wish to do. Once you get the thunking layer in place
it can be adapted to the current situation. Of course
there are some implementation detail, like on Itanium
and possibly also with the emulator you will need a thunk pair
because of the asymmetric intercalling but that is just
implementation details that doesn't effect the interface
of the thunking layer.
As it stand: I think that the problems are obviously the
same you think that it is absolutely not clear that they
are the same. So therefore I am _very_ interested in hearing
_your_ arguments and _your_ opinion on my arguments.
