Ira Krakow wrote:
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.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
requires.
This is the approach I plan to take. I welcome all
feedback.
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.
Shachar
-- Shachar Shemesh Lingnu Open Source Consulting ltd. Have you backed up today's work? http://www.lingnu.com/backup.html
