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

Awesome

[Anonymous Coward]

I can't wait til we have a fully functioning windows emulator. Even if it will kill the need for native apps (read games).

Re:Awesome

[harlows_monkeys]

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?"

I don't believe that this is actually true. Win95 had excellent Win3.x compatibility, but developers nevertheless rushed to develop Win95 software. Why would Win3.x compatibility in OS/2 cause developers to forego native development, but not have the same effect on Win95?

I believe that what really killed OS/2 was IBM's attitude toward developers. Microsoft made it trivial to get started in Win95 development. Hell, you could go into Egghead and buy an MSDN subscription and all the tools you needed.

Compare to OS/2, where you had to apply to IBM for permission to develop, and buy an expensive development kit (at least, to officially develop).

I believe it was Jerry Pournelle who wrote of his experiences at a trade show, where he went to the MS booth, and asked what he had to do to develop for the upcoming Win95, and they handed him, on the spot, a development kit. At the IBM booth, he asked what he had to do to develop for OS/2 (a system that was already for sale, unlike Win95, which was still in beta). Did they hand him a development kit? Nope. They handed an application. If they decided he was worthy, he'd be allowed to buy a development kit.

I think that is the reason OS/2 development never took off.

Note! I'm not saying for-pay developer programs necessarily kill a platform. Apple used to have a for-pay program, but it was a joy, because of the astounding support. You sent any question off to DTS, and they would quickly have a good engineer, with full access to the source and the developers, answer it. I was having trouble with interrupt handling in a device driver, and they send me the detailed comments from the ROM source code for the interrupt handler, which explained exactly what was going on.

With Apple DTS, the feeling I had as a developer was that I was dealing with my peers at Apple, who wanted to cooperate with me to make something great. With IBM, I always felt like an insignificant pawn in whatever they were doing.

Re:Awesome

[AvitarX]

Ummm, it has.

Linux has far surpassed where OS/2 was, and is growing in use. Linux's total openness is a part of it's success (another part being it's freeness).

Linux has a large share of web servers. A large share of new super computer instellations. A large share new renderfarm instellations. A large share of scientific workstation instalations. A growing share in educational desktop installations. And a growing share in governmental type settings.

Linux is seriously taking off in a big way. It is HUGE and has far surpassed OS/2.

Re:Awesome

[rseuhs]

It's excellent handling of Windoze apps is part of what killed OS/2.

Nonsense, OS/2 was killed because PC-makers didn't want to use an OS from a competitor.

"Why port it when it can run the windoze version?"

Great, so you would rather have them ask "Why port it at all when 100% of our customers use Windows?"

Not exactly the same, but it would be much better to have native apps,

Sure, but we have to get a significant amount of users first, then can we expect native apps.

Wine helps building that userbase.

Instead of developers asking "Why port it when it can run the windoze version?" we have to have users asking "Why use Windows when Linux can run Windows and Linux apps?".

Re:Awesome

[afidel]

Wrong. An API is by definition a fixed implementation that does not change at a later time.

Try to tell that to the folks in Redmond. MS has done a great diservice to the idea of object re-use, they often fail to follow one of the most basic ideas of OO, that is you can extend but never change an interface. Almost every single service pack changes the interfaces to dozens and dozens of parts of the windows api. This is why we have "dll hell". If MS followed basic principals it wouldn't be a problem because rather than reworking the interface they would simply add new additions to the interface and depricate the old ones (leaving the origional interface and associated code so that programs would still get the behaviour they expect).

compiling?

[Anonymous Coward]

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.

WRONG!

[www.sorehands.com]

It may eliminate the need for a reasonably fast machine to develop on, but you always need a target machine for testing! But, the test machine should be slow so that one can find performance bottlenecks and see the program operate under non-optimal conditions.

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.

I use Wine to compile but not for porting

[Captain Rotundo]

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).

This is non-news.

[Doomrat]

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...