You cannot have a tool that is going to write the translation layer automatically. I guess it is simpler to write it by hand for the Unix APIs (maybe a couple thousands at most?), rather than for the Windows APIs >> 10 thousands, plus tons of messages, plus tons of callbacks, plus poor documentation, etc.
Well, who would need documentation as we HAVE the source of these APIs (ie the Wine source code itself). My conception of a tool would have been something like that : each time in the Wine code that a function is 'exportable' to the application itself (be it via DLL loading, GetProcAddress, COM, ...), its signature could be stored somewhere (as is already done for relay traces in the .spec files but much more precise). Then, a tool could then, for any two given architectures, generate translation thunks from one to the other (which would convert structures with the various alignements for each platform, ...). Of course, Varargs function would be hell to simulate (but well, same problem for glibc translation than for Wine).
The remaining problems would be callbacks. But for these too, as we have access to the code filling the data given to those, we could also do some special code handling the various translations.
So, all in all, I still do not see why it would be much more difficult for Wine rather than for any other library....
Lionel (playing devil's advocate)