Winelib's role in converting Windows applications
wine-devel at shemesh.biz
Sat May 7 01:16:29 CDT 2005
Ira Krakow wrote:
>As many of you know, Brian and I are writing a book on
>Wine and Winelib for Prentice Hall. Brian's doing the
>Wine part; I'm doing the Winelib part.
>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
>This is the approach I plan to take. I welcome all
What I found, when I suggested to clients to work this way, was that the
debugging tools were wholly and utterly inadequate. With all due respect
(and I have TONS of respect) to winedbg, it's not up to the standards of
working with ddd or the Visual Studio integrated debugger.
Maybe running the remote Visual Studio debugger will work. I know it
worked for me on some occasions. I also know that when I tried to run it
in the most crucial of cases, it crashed the parent Visual Studio (i.e.
- the part that ran on Windows). As such, there are occasions where
compiling natively is, more or less, the only choice.
Lingnu Open Source Consulting ltd.
Have you backed up today's work? http://www.lingnu.com/backup.html
More information about the wine-devel