Compiling Under Wine

now3djp writes "Interesting article over on CodingStyle that demonstrates how I successfully eliminated wasted time maintaining an MS-Windows computer when I could build natively from my GNU computer! /. has followed other cross compilers in the past. This article is different because I used MS's own compiler! This allowed me to get on with real games porting; with only a proportional increase in compile time. Wine has really come a long way in supporting simple apps, let us hope it reaches a 1.0 soon."

Comments

Visual C++ under WINE

[kruetz]

Wine has really come a long way to facilitate running major applications such as Visual C++. Features that "just work" often do not get mentioned because there is nothing to say. Wine has many excellent features like this. However, I have expressed the problems with Wine currently and I expect that in a potential follow up article many of these will be resolved. Wine has been in development for over a decade now. As it is finally nearing a 1.0 release, I see how much better it was than the 1.0 release of MS Windows.

Using Visual C++ on GNU/Wine gives me all the benefits of being able to develop a 100% compatible MS-Windows version of the game, while saving me the time of maintaining another Win2k machine version of the source and moving to that machine to compile. It has been a great time saver for me and I strongly expect this information will be very useful to myself and others in the future.

Okay, so you can use Visual C++ compiler under WINE. Is that terribly surprising when WINE can run MS-Office for the most part? The compiler takes the source files and libraries and produces an executable or library. I don't know for sure, but I wouldn't think that too much of this would involve heavy usage of the Win32API, much less the lesser-used and less-tested-under-WINE parts. For the most part, the compiler would be doing tokenising, parsing, translation and optimisation, which would in all likelihood use no external libraries or anything.

I don't mean to rubbish this article, I'm just saying that I don't see it as being terribly surprising. On the other hand, I think this is a great use of WINE and is definitely more innovative that anythin I would use WINE for. And as he says in the article, there was a lot of fiddling around with command line arguments and environment variables. But if you're compiling from the command-line under Windows, it's just as bad (no, really).

A much greater "victory" for WINE would be to have the whole VisualStudio ensemble running. But I'm not sure if this is feasible, especially in the short-term. By "victory" I don't mean something along the lines of "Linux now allows you to run a quality IDE", because KDevelop and Eclipse are great IDEs. Instead, VisualStudio and Office are probably the most complicated pieces of software written by MS (excluding Windows itself) and for WINE to be able to run them both as if they were running under Windows would be truly a fantastic achievement.

CVS

[YoJ]

The author describes the problem he originally solves as being the pain of moving code between Linux and Windows, losing attributes, case problems, etc. The approach I take is to keep all code in CVS on my file server. I do compiling and editing on my personal computer; both Linux and Windows can handle CVS. This way you have to reboot into Windows for the Windows compile, but never have to worry about copying files or case changes.

Re:Awesome

[Losat]

I think you are refering to IBM's Developer Connection, which was a bit like MSDN. This was fee-based but may have been free if you met certain criteria. It seems like they also had a developer partner program, though I can't remember for sure.
However, there were certainly compilers and development kits just anyone could buy and use (no application to fill out, just buy the box).
Exmamples: IBM's own excellent C-Set/2 (C/C++ compiler) (later Visual Age C++); Watcom's excellent C/C++ compiler; Borland's C++ for OS/2; Two (yes two!) distributions of gcc (gcc2 and emx). There were also two "Turboish" Pascal compilers and three "Visual" Rexx packages (somewhat Visual Basic like but using the Rexx language).
Still, I do agree that IBM could have been more friendly to developers, and IBM certainly did enough things wrong with the marketing.