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
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
I totally disagree. It is like saying Lets not port. And keep paying the Microsoft tax. Which keeps Microsoft big and Linux small forever. And is only good for PC. What about IBM machines, PDA(s), Suns, Macs... An x86 only Linux is not Principal-Linux.
The path is: - Move to a different compiler on windows. Alternatives: comu-c - (2 WML (Weeks for 1 million Lines) ) C++ builder Borland. - (Lots of COM ATL and MFC see MinGW. Lots of Win32API STL and C++ - 4 WML ) gcc (MinGW) - (Very very soon - 6 WML ) Intel c++ - ( Don't know )
- Than Winelib on Linux. If you are using Technologies unavailable in Wine/Linux, (for example speech to text). Implement it and send patches to wine. - Maintain the projects on all platforms (Including windows) with the same compiler and Makefiles. - Slowly step-by-step Port MFC code to wxWidgets, STL to STLPort, ATL to Atilla, msvcrt to glibc ,Win32 to POSIX. And use POSIX portability tools on Windows. - Stop the MS tax, grow up, get Independent.
You see Wine is like High-school where you get to Revolt against your parents. And it is like collage Where you get a real education. Than you have a real Job and you get to Fly rockets to the moon. But your parents can't come.
Free Life Boaz
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.
Thanks. Ira
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
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.
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+
-
Boaz Harrosh -
Eric Pouech -
Ira Krakow -
Michael Stefaniuc -
Shachar Shemesh -
Troy Rollo