Re: Winelib's role in converting Windows applications
Troy Rollo a écrit : On Sat, 7 May 2005 16:16, Shachar Shemesh 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. Many years ago I made GDB understand Borland's TDS debugging format. I now use a modified gdb+insight under Linux to debug Borland compiled executables under WINE, together with some scripts that allow me to debug Borland code and GCC code in the same session. I believe the old Microsoft VC++ debug format was trivially different to Borland's TDS, yes although I don't know about Microsoft's current debugging formats. it evolves a bit (changing some information size and layout in the files) but the core looks quite the same If winedbg already has symbol reading code perhaps that can be ported. likely yes (but in dbghelp, not in winedbg) A+ -- Eric Pouech
Re: Winelib's role in converting Windows applications
On Sat, 7 May 2005 16:16, Shachar Shemesh 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. Many years ago I made GDB understand Borland's TDS debugging format. I now use a modified gdb+insight under Linux to debug Borland compiled executables under WINE, together with some scripts that allow me to debug Borland code and GCC code in the same session. I believe the old Microsoft VC++ debug format was trivially different to Borland's TDS, although I don't know about Microsoft's current debugging formats. If winedbg already has symbol reading code perhaps that can be ported. I tried to get the Borland TDS stuff merged into the standard GDB code but there were components that needed to go into some of the libraries GDB depends on and the maintainers of those libraries were somewhat unresponsive to my submissions.
Re: Winelib's role in converting Windows applications
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 requires. This is the approach I plan to take. I welcome all feedback. 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. Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. Have you backed up today's work? http://www.lingnu.com/backup.html
Re: Winelib's role in converting Windows applications
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. This is true, the only good reason to still recompile everything as Winelib stuff is if you need to run your programs on an other CPU architecture like PPC or SPARC. But for that you need to have the whole source for your application because binary DLLs wont work. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 Sr. Network EngineerFax.: +49-711-96437-111 Red Hat GmbHEmail: [EMAIL PROTECTED] Hauptstaetterstr. 58http://www.redhat.de/ D-70178 Stuttgart
re: Winelib's role in converting Windows applications
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
Winelib's role in converting Windows applications
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. Thanks. Ira
Re: Winelib's role in converting Windows applications
Hi Ira, --- Ira Krakow [EMAIL PROTECTED] wrote: 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. Another good example is from the UI point of view where you don't want users to have to deal with drive letters in a Unix env. Using winelib it would be possible to directly call GTK/GDK or KDE and use browse dialogs. Of course some work seems to be going on to add support for this directly to shell32 so someone else might know suggest a better way. Thanks Steven __ Yahoo! Mail Mobile Take Yahoo! Mail with you! Check email on your mobile phone. http://mobile.yahoo.com/learn/mail
