Compiling Under Wine

It is not recommended by YellowSnow · 2003-02-23 14:40 · Score: 5, Funny

that you compile under the influence of any type of alcahol

Re:It is not recommended by eclectro · 2003-02-23 14:51 · Score: 5, Funny

that you compile under the influence of any type of alcahol

but it's ok to post on slashdot???

--
Take the cheese to sickbay, the doctor should see it as soon as possible - B'Elanna Torres, "Learning Curve"
Re:It is not recommended by Pseudonym · 2003-02-23 15:44 · Score: 4, Funny

Don't drink and derive?

--
sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});

compiling? by Anonymous Coward · 2003-02-23 14:44 · Score: 5, Insightful

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! by www.sorehands.com · 2003-02-23 14:49 · Score: 4, Insightful

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.

--
Fight Spammers!

Re:WRONG! by spinkham · 2003-02-23 15:50 · Score: 4, Informative

He was testing on a seperate machine, just wanted to avoid the hassle of transfering all the sources every time he wanted to compile.
Quote from article:

The transfer of source to an MS-Windows machine and the correction of filenames and text format issues have been avoided. Therefore, I can build the game from one machine, then I only have to copy the final chaos.exe to my MS-Windows machine to test.

--
Blessed are the pessimists, for they have made backups.
Re:WRONG! by Jah-Wren+Ryel · 2003-02-23 16:05 · Score: 4, Funny

Duh! If it compiles it must be fine! What kind of newbie developer are you?

--
When information is power, privacy is freedom.

Visual C++ under WINE by kruetz · 2003-02-23 14:52 · Score: 5, Interesting

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.

--

This sig intentionally left bla... dammit!
Who's got the whiteout?

Re:Awesome by SCHecklerX · 2003-02-23 14:58 · Score: 4, Interesting

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 by YoJ · 2003-02-23 15:04 · Score: 5, Interesting

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.

I use Wine to compile but not for porting by Captain+Rotundo · 2003-02-23 15:07 · Score: 4, Insightful

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

Re:which begs the question by fredrik70 · 2003-02-23 15:11 · Score: 5, Informative

VC++ isn't a bad compiler at all, really. They got a quite shitty implementation of the STL lib though(might have changed now - I use VC++ 6). Also isn't properly following the C++ ANSI standard. for example the scope whenyou declare vars in for loops is broken. MS is aware but they can't really fix it easily now, since *lots* of old MFC code would break if they fix it. Yuo can set a flag though to enforce ANSI but it not on by default. Compiler makes quite good code though. If you want a more 'proper' closed source compiler go for Borland's - the command line version is even free on their website! (after a rather hefty registration proc though)

--
if (!signature) { throw std::runtime_error("No sig!"); }

1.0 ? by IanBevan · 2003-02-23 15:16 · Score: 4, Interesting

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

--
Never, ever lose a file again. Ever.

Re:1.0 ? by Papineau · 2003-02-23 16:19 · Score: 4, Informative

Before 1.0, let it reach 0.9 (0.8 was released circa 1994 or 1995). You can check the unofficial Wine 0.9 TODO for a list of features needed for the 0.9 milestone.

About the long development life... don't forget it started with Windows 3.1 as it's first target. Then, Win95, Win NT 4.0, Win98, WinME, Win 2K, Win XP came out. We're talking 2 different architectures (for some kind of operations at least), and some new features to implement at each version.

Also, the list of authors currently lists 557 different people (contributions vary from a one-liner to a complete architecture overhaul). The number of currently active developpers is of course way smaller, more along the lines of 30-50. Of those, the vast majority do it in their spare time. So a long development period is not an indication of a failure, since if it was nobody would work on it anymore.

The test cases (called conformance tests) try to verify that what Wine implements reacts the same way in Windows. Depending on the purpose of a test, it can be trivial or not, implemented in Wine or not yet. A whole lot of dlls don't have any test written for them yet, so yes, we need more test cases.

This is non-news. by Doomrat · 2003-02-23 15:17 · Score: 4, Insightful

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

Re:Awesome by harlows_monkeys · 2003-02-23 15:18 · Score: 5, Insightful

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 by Losat · 2003-02-23 15:55 · Score: 5, Interesting

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.

--
I'm not a lawyer, but I play one on Slashdot.

Even a man who's pure of heart by YellowSnow · 2003-02-23 16:10 · Score: 5, Funny

and uses the preview right
can turn to a troll
when the typos roll
and the bottle is empty and light

weird... by dolson · 2003-02-23 17:06 · Score: 5, Funny

You don't need Wine if you know what you're doing...

dana@digory:battlepong$ make
g++ `sdl-config --cflags` -c sound.cpp
g++ `sdl-config --cflags` -c collide.cpp
g++ `sdl-config --cflags` -c ball.cpp
g++ `sdl-config --cflags` -c game.cpp
g++ `sdl-config --cflags` -c menu.cpp
g++ `sdl-config --cflags` -c player.cpp
g++ `sdl-config --cflags` -c randgen.cpp
g++ `sdl-config --cflags` -c init.cpp
g++ `sdl-config --cflags` -c main.cpp
g++ `sdl-config --cflags` sound.o collide.o ball.o game.o menu.o player.o randgen.o init.o main.o -o bpong -lm `sdl-config --libs` -lSDL_image -lSDL_ttf -lSDL_mixer
dana@digory:battlepong$ file bpong
bpong: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.0, dynamically linked (uses shared libs), not stripped
dana@digory:battlepong$ make clean
rm -rf *.o bpong
dana@digory:battlepong$ sh cross-make.sh
g++ `sdl-config --cflags` -c sound.cpp
g++ `sdl-config --cflags` -c collide.cpp
g++ `sdl-config --cflags` -c ball.cpp
g++ `sdl-config --cflags` -c game.cpp
g++ `sdl-config --cflags` -c menu.cpp
g++ `sdl-config --cflags` -c player.cpp
g++ `sdl-config --cflags` -c randgen.cpp
g++ `sdl-config --cflags` -c init.cpp
g++ `sdl-config --cflags` -c main.cpp
g++ `sdl-config --cflags` sound.o collide.o ball.o game.o menu.o player.o randgen.o init.o main.o -o bpong -lm `sdl-config --libs` -lSDL_image -lSDL_ttf -lSDL_mixer
dana@digory:battlepong$ file bpong
bpong: MS Windows PE Intel 80386 GUI executable not relocatable

It's MAGIC.

Re:So you're saying my vi clone. . . by bofkentucky · 2003-02-23 17:23 · Score: 4, Funny

what is your project's name...emacs *ducks for asbestos-lined safe room*

--
09f911029d74e35bd84156c5635688c0

Re:Bullshit by bm_luethke · 2003-02-23 17:30 · Score: 4, Interesting

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.

--
------- Sorry about the spelling, I suffer from two problems. Dyslexia makes it difficult to spell well, lazy makes it

Re:Awesome by AvitarX · 2003-02-23 17:36 · Score: 4, Insightful

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.

--
Wow, sent an e-mail as suggested when clicking on "use classic" banner, and got a fast response that addressed my msg

Re:Awesome by rseuhs · 2003-02-23 20:11 · Score: 4, Insightful

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:wow by crath · 2003-02-24 00:58 · Score: 4, Interesting

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.

24 of 322 comments (clear)