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.

Re:Awesome

[SCHecklerX]

Be careful what you wish for. It's excellent handling of Windoze apps is part of what killed OS/2. Developers: "Why port it when it can run the windoze version?"

Not exactly the same, but it would be much better to have native apps, as opposed to having to emulate/VM that other OS.

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.

1.0 ?

[IanBevan]

I'm curious, what exactly will the "milestone" of version 1.0 of Wine actually mean ? I would doubt that it'll ever be 100% compatible with Windows 98/XP. So what feature list is the development team trying to complete before calling it 1.0 ?

I think that pretty much any other product would have been deemed a failure if it had endured a 10 year development life and not reached version 1.0. Unless of course we're talking about Duke Nukem Forever...

My experience of Wine is common to most people's I think; it looks like a great idea, but as soon as you try to run any non-trivial program, it simply locks up/doesn't work. I've looked at their website and looked at all the "passed" indicators on their test cases. That doesn't help me run my apps much though... do they need more test cases ? Are they simply too abstract ??

Just my $0.02 worth

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.

Re:Bullshit

[bm_luethke]

Not neccessarily the most fair test. First the test were ran on an athlon system. Intel compilers optimized mostly based on the Intel architecture.

For example, we ran several benchmarks at work on three computers with gcc 3.1 and the intel compilers. Basically gcc and intel were fairly equal on the pIII xeons (intel had the edge). Gcc was somewhat faster on the athlon 700, and the intel compilers blew gcc away on our p4 2.4 ghz.

So what conclusions can you make? neither intel or gcc are better than the other. As we expected it depends on several factors - one of the main is hardware (wow, who woulda thunk hardware affects optimization :) ). In fact on the P4's with multi-threaded floating point operations we saw well over 300%, none of the tests were worse than 100% faster. On the athlon Gcc was slightly better except in one case were it was signifigantly faster. Eventually we found that gcc 2.x or 3.x does not have good p4 optimization yet (we asked on the devel lists trying to get better numbers as we didn't want to pay for the intel compilers). Of course this was about 6-10 months ago so they could have gotten optimizations in by now.

If I had to choose one or the other as "generally producing faster code" I would ask "what hardware are we talking about". And that GREATLY influences the answer.

Re:wow

[crath]

Now this is impressive. Things like this are what WINE should be all about. Amazing.

I disagree, it's depressing not impressive:

• The author first asserts that the process of moving files between the systems causes the upper/lower caseness of the filenames to be munged; however, the text later talks about how his personal preference for file casenames is all lower and so he changes them. There is nothing in his "transfer between Linux & Windows" scenario that causes the case names to be wrong. The real issue is simply that his personal preference for filenames differs from that of the original author of the source code.
• The author displays no knowledge of the network mounting of filesystems using SAMBA (CIFS) or NFS. This would have been a far better method and while it too would have slowed down compiles on the machine mounting the filesystem he states that he is not unhappy with such a slowdown.
• Why isn't the source code checked into a configuration management tool, like CVS? What the article should have been describing was the process he followed checking the application into CVS, making his personal preference changes, checking in those updates, and then checking it back out onto both platforms and performing the compiles there---with no compile slowdowns.
• As others have already noted elsewhere, he will still have to test on the target platform. Those who argue that VMWare is as good as a native boot-up for testing are simply displaying their ignorance and inexperience: display and network problems are often induced by a change in hardware platform, and VMWare is a distinct hardware platform from a testing perspective. While testing on VMWare is useful, it is not sufficient: a Windows application should be tested on several different hardware platforms as part of its formal QA.

In summary, while the article probably accurately describes the author's actions, there is nothing in his account that others should be emulating. More experienced developers should be consulted in the search for best practices.

I write this as someone who has done software development for almost 20 years; more than 20 if you count my high school years as a computer hobbiest.