On 13 Apr 2003, Alexandre Julliard wrote:
It will be fairly complex, and will probably add a lot of different constraints, I'm not sure it would really be an improvement over winebuild. If you want a really transparent solution then it should most likely be done directly at the linker/ld.so level.
Yes, it sounds about right. Of course, the ultimate goal would be to be able to use Wine by doing -lwine. Now, an intermediate step toward this goal would be to allow the program to remain a Unix app (rather than a Winelib app), and require a more complex linking process. Which is fairly close to what winebuild is doing currently.
But we are not there. The idea with this additional step would be to factor all this ugliness into one spot (that is, linking), so we can drop it altogether when the required support appears in the linker.
Thinking more about it, the current winebuild setup is very close to this. So what's bothering me? I guess asking people to transform their apps to a Winelib app if they want to use Winelib.
For CUI apps, there is no difference between the current winebuild process, and what I'm proposing (a Unix app with a non-standard link). I think (please correct me if I'm wrong).
However, for GUI apps, people need to provide the WinMain entry point instead of main. Maybe we can export some sort of init function, so that they can keep their main(), and simply call a wine_init(). Doing so, we maintain the appearance of a Unix app. Of course, the limitation would be that no Wine-related funtionality can be called before the wine_init() call. So no more static C++ initializers, etc. Would this be doable?