Ira Krakow ([EMAIL PROTECTED]) 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
