> By "standard Wine code" I mean the normal Win32 code, like what you
> find in the dlls/ dir (or in Winelib apps).
Yes, that I my defintion too.
> You may of course need to
> change build.c to generate export tables differently, or other similar
> low-level stuff;
Yes, there will be some modifiction to tools/build.c and
a file relay32/thunk32.c similar to if1632/thunk.c.
> but I had the feeling you were suggesting more
> extensive modifications.
I think that can be avoided, but I am not 100% sure yet.
> > There is no particular problem making a working solution.
> > What I am interested in is avoid wasting a lot of time implementing
> > a patch that are later rejected because it isn't good enough.
>
> Then you should definitely explain what you intend to do. And if your
> solution requires doing for Win32 the same kind of mess we have to do
> for Win16, I can tell you already I won't like it...
Providing it is possible to fix the trival Enum* kind of thunking
in the .spec files, which I think it is, the primary impact will
be that THUNK32_{Alloc,Free} will added at the places in the
code where functions pointers are used in non-trivial.
As for in how many places function pointers are used in non-trival ways
that remains to be investigated. WNDPROC, HOOKPROC, TIMERPROC, ABORTPROC
and KEYB_EVENT_PROC are the are the only ones I have found currently
supported in Win16. There might be more in Win32 though, but I haven't
found any yet. There will be a few lines new code for each place.
In short, AFAICS the source code impact will be very small.
With GNU C on x86 the size and performace impact can be made
zero by trivial defines.
I might be wrong but since it works for Win16 I see no reason
why it will not work for Win32, there we have much fewer problem
no segmented pointer, same datastructures, same alignment on data
structures, no integer truncation/sign extention problems to name
a few.
