Ira Krakow (ikrakow_1999@yahoo.com) wrote:
At Wineconf, I had a number of conversations about Winelib's role in converting Windows apps. The consensus seems to be that the most efficient conversion path is for much of the Windows app to stay in Visual C++ (or whatever) and that only the modules that specifically require native Linux calls should be recompiled, via MinGW/Dev-C++ on the Windows side, and Winemaker on the Linux side, into Winelib objects.
For example, if the application requires PAM authentication, or a Linux-based help system, these modules would be separated out and encapsulated as Winelib objects. I was thinking of using PAM authentication as a good example, since it works for any authentication scheme that the application requires.
There are two other reasons to use winelib:
1) if your code uses SEH (structured exception handling), you have a problem. This technique is patented by Borland, see http://www.google.com/search?q=patent+5628016 or maybe by Sun, see http://www.google.com/search?q=patent+6247169 so the official gnu gcc can't support it. You can apply an unoffical patch (see http://reactos.csh-consult.dk/index.php?page=gccseh, or you may be able to use winelib plus some clever macros (see http://www.winehq.org/hypermail/wine-devel/2005/05/0186.html)
2) if you want to reach non-x86 platforms (e.g. MacOSX/PPC, Solaris/Sparc) winelib is the only way to go until projects like Darwine integrate a CPU emulator.
- Dan