Slashdot Mirror
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."
I can't wait til we have a fully functioning windows emulator. Even if it will kill the need for native apps (read games).
It's not so interesting to me that he managed to compile using VC++ under WINE. VC++ doesn't call any of the APIs you code, it just puts machine code into the file saying you can call them if you want. It's all well and good to have VC++ compile DX9_CreateSurface() (or whatever) into a bunch of PUSHs, POPs and a JMP instruction, but that doesn't help if WINE can't actually call that function when you're testing. It makes more sense to me to use Bochs or VMWare to test your application if you're developing on multiple platforms. Anything less would be short-changing your Windows clients.
If the people are forced to test applications on slow machines, we may not have word processors that need 40MB of ram and a 933MHZ pentium III to run.
Fight Spammers!
I use Microchip's pic assemler through wine, for a small piece of code I maintain that runs on a PIC that wasn't supported by any GNU/Linux assembler when I started. I also maintain a legacy version of a very specific proprietary MSDOS (actually we run DRDOS) program that was written with Borland C, hopefully I will be replacing the last running bit of that with a DJGPP compiled version soon, which of course can be cross compiled on GNU/Linux without the need for Wine and bcw.
I know what your thinking, but when a piece of software has worked flawlessly (well almost!) for 15 or so years, and is 'mission critical' it is very hard to drop a platform and move on. I am hoping to try out a move to Linux some day in the near future so that I can take advantage of new features and things that just arent available for DOS. But unless I can convince everyone else of the benefits I may be supporting dos for quite some time (I am the only software person at this company).
Visual C++ doesn't do anything weird regarding Windows API. The IDE is a normal affair, and the compiler could be run without a user interface. It's really not testing Wine to it's limitations and the irony of situation is barely worth commenting on. This is non-news, the only thing this article achieves is to make Slashdot look like the anti-MS geeks with limited social awareness. Some things just aren't worth giggling at.
I don't even need to look at the poster to know that this is the work of micheal...
What the fsck is "GNU/WINE"! Aaargh! It's one thing to give RMS some credit, but this reeks of puerile toadying in an effort to look sophisticated in front of other juvenile sycophants.
Repeat after me, "WINE is not a GNU project!"
A Government Is a Body of People, Usually Notably Ungoverned
Don't like their STL? Use STLPort! Bonus points if you can compile it under Windows using their incredibly sucky installation instructions, which sorta ... stop in the middle of the process.
Karma: Could be worse (could be raining)
I think if you are serious about cross platform development, you need to have a native install of all the platforms you intent to port to. Either multi-boot or seperate boxes. Why? Well amy emulator, WINE espically but even VMWare, has certian quirks and differences that native hardware does not. You need to test it as it will be run to be sure. Also, if you are using any advanced 3d function, the emulators are going to fall flat on their faces.
If I were really serious about a commercial cross platform release, say Windows and Linux I think I would want a ton of testing. I'd probably want at least 3 different systems, all tht had a copy of Windows 98, ME, 2k, and XP plus at least 3 big Linux distros. While in theory something complied for any hardware under any verison of Windows should work on any other, it's just not the case. Same for Linux. You want to test for the little "gotchas" if you want to make sure you have a really stable software.
The safest bet is to not have your job depend on tweaking the last little bit of performance out of a customer's machine when you have only a vague idea of which platform they might be running on. Either improve your algorithms in the whole, or hide the slow performing code in a place where the user won't notice. (if possible)
That said, another option is to isolate the performance-critical sections into chunks of code which get optimized separately and then have cpu-detection code choose the appropriate chunk at runtime. The debian atlas packages do something like this, though (AFAIR) they use hand-optimized assembly instead of just using compiler flags and/or different compilers. (and yes, you can have both the sse- and 3dnow-optimized packages installed on the same machine, and the code will load the appropriate shared library at runtime)
Then, instead of standardizing on a compiler, you'll need to standardize on a build system that will let you compile the code as you need it compiled.
The author first asserts that the process of moving files between the systems causes the upper/lower caseness of the filenames to be munged
This is the case, I've run into this problem myself many times and it has little to do with how the files are saved and much to do with how fs-drivers are implemented and configured. Compare to how you often end up with read-only files if you copy them from a CD in Linux. Sure you can change some settings, but then often get other side-effects in other situations (goes for both). I believe he is the original author of his project.
The author displays no knowledge of the network mounting of filesystems using SAMBA (CIFS) or NFS.
The fact that he is dual-booting strongly suggests that he (like most of us) only has one development machine, not a complete network of machines. Don't get ignorant just because you are better equipped.
Why isn't the source code checked into a configuration management tool, like CVS?
Once again, he only has one workstation, thus is CVS out of the question since it needs to be hosted under one of the OSes and he can only run one at once. Besides, CVS is in most cases just unnecessary and complicates and slows stuff down if you are the single developer. You can make backups through normal file copying.
As others have already noted elsewhere, he will still have to test on the target platform.
Which I'm sure he does now and then too (by dual booting). However, if you just need to do some minor change in platform independent code it's really a bliss to not need to dual-boot.
Besides, your criticism of using VMWare for testing is quite irrelevant. It's true you need to test on multiple environments to know that it works on them all, but as you said, VMWare with Windows X *IS* one of these environments. If he's dual booting he only has access to one environment anyway, using VMWare as well will add one or more extra testing environments.
I would have LOVED to have a similar setup as his when I was developing BladeEnc. Like him I only had one development machine (couldn't afford more) and constantly needed to dual-boot in order to recompile and package a new version. The platform dependent parts of BladeEnc were very limited and untouched for 95% of the development, thus this setup + testing under wine (for possible quality degradation due to compiler excentricities) would have been more than enough during most of my days. Only performance tweaking would have to be done in windows environment.
With your 20+ years as software developer you obviously have found your way of working in your projects and with your budget. Don't knock others creative solutions for solving their problems with their resources in a totally different situation.