Patrik Stridvall <[EMAIL PROTECTED]> 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.
> You didn't comment if you think what I proposed will work
> or if it is an acceptable solution. Why don't we try
> to solve the problems that must be solved regardless
> instead of chasing after future problems that are either
> indepent or easily solved after the problem I am talking
> about have been solved.
I think we already have enough real problems to not go about inventing
new ones. The stdcall "problem" is trivially solved: use gcc on x86.
> So what do you think? Do you think my proposal(s) we work and
> which one do you prefer? As I said I can try and remake
> the Win16 thunking layer as a proof of concept.
Of course it can work; the question is whether you can do it in a way
that the cost isn't larger than the (very small IMO) benefit of being
able to use another compiler on x86.
--
Alexandre Julliard
[EMAIL PROTECTED]
