Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
Programming IT Technology

Compiling Under Wine 341

Posted by michael from the compiling-while-intoxicated dept.
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."
This discussion has been archived. No new comments can be posted.

Compiling Under Wine More

Compiling Under Wine

Comments Filter:

  • Awesome (Score:3, Insightful)

    by Anonymous Coward on Sunday February 23, 2003 @09:39PM (#5367983)
    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 (Score:3, Informative)

      by EvilSporkMan ( 648878 )
      Well, it won't be WINE, since WINE Is Not an Emulator, as we all know. =P

    • Re:Awesome (Score:5, Interesting)

      by SCHecklerX ( 229973 ) <greg@gksnetworks.com> on Sunday February 23, 2003 @09:58PM (#5368091) Homepage
      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.

      • Re:Awesome (Score:5, Insightful)

        by harlows_monkeys ( 106428 ) on Sunday February 23, 2003 @10:18PM (#5368169) Homepage
        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 (Score:5, Interesting)

          by Losat ( 643653 ) on Sunday February 23, 2003 @10:55PM (#5368298)
          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:Awesome (Score:2, Informative)

            by Anonymous Coward
            Speaking from experience, there was a definite Kiss-The-Ring culture surrounding OS/2.

            Back then, most IBM stuff could not be purchased retail and had to be procured through the sales channel (who was only interested in you if you were buying mainframes). Meanwhile, Microsoft was spamming CDs like crazy, figuring they would get paid eventually.

        • Re:Awesome (Score:2, Interesting)

          by vistas ( 214241 )
          Back in '84, I was the first person at the University of Georgia to get a Mac (I was one of the two campus-wide "microcomputer resources" at the time). For the two weeks that I had it (before a big-wig commandeered it) I BEGGED Apple for a development kit, compiler or *anything*.

          "3000 smackers please" was the only comment I got out of Cuppertino.

          So I kept playing on the PC with my $49 copy of Turbo Pascal, and my ~$200 copy of Lattice C. When MS dropped their Windows SDK from $900 to $300 in '88, I bit and basically never looked back.

      • Re:Awesome (Score:3, Interesting)

        by Qzukk ( 229616 )
        Oddly enough, BSD still lives despite the Linux binary compatibility.

      • Re:Awesome (Score:5, Insightful)

        by rseuhs ( 322520 ) on Monday February 24, 2003 @03:11AM (#5369059)
        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?".

    • Even if it will kill the need for native apps (read games).

      This is not insightful, that's nonsense.

      Currently, there is no real need for native Linux games, simply because there are not many Linux gamers.

      Wine is the ONLY realistic way to attract gamers (and create - not kill - the need for native apps).

  • ads (Score:3, Funny)

    by ldspartan ( 14035 ) on Sunday February 23, 2003 @09:40PM (#5367986) Homepage
    I find it entertaining that when I went to read the comments, I got to see an article for Visual Studio .NET :).

    --
    lds
    • and by "article" I mean "advertisement"...

      way to go, brain.
    • I don't see me - just set ads.doubleclick.net to 127.0.0.1 in your hosts file. Granted thats not the only host you have to add, but there are regularly maintained lists out there of good people to block :).

      • Or if your using Gecko (Score:4, Informative)

        by bogie ( 31020 ) on Sunday February 23, 2003 @11:32PM (#5368413) Journal
        usercontent.css

        *[src*='ads.'],
        *[src*='/ad/'] ,
        *[src*='/ads/'],
        *[src*='/Ads/'],
        *[src*='dou bleclick'],
        *[src*='us.a1.yimg.com'],
        *[src*='ad vertis'],
        img[src^='http://images.slashdot.org/ba nner/'] {
        display: none !important;
        }

        You can add whatever else you want there as well. Things like

        /* this hides the usual 468x60 Flash banner ads */
        embed[type="application/x-shockwave-flash"][wi dth="468"][height="60"] {
        display: none !important;
        visibility: hidden !important;
        }
        /* this hides the not so usual but very annoying 728x90 Flash banner ads */
        embed[type="application/x-shockwave-flash"][wi dth="728"][height="90"] {
        display: none !important;
        visibility: hidden !important;
        }

  • It is not recommended (Score:5, Funny)

    by YellowSnow ( 569705 ) on Sunday February 23, 2003 @09:40PM (#5367992)
    that you compile under the influence of any type of alcahol
  • does microsoft compile windows under wine?
    • Begging the question does not mean what you think it means.

      It means :

      "to assume something that hasn't been proven as a basis of one's argument,"

      "Wine is not good because it is open source", or "Microsoft's compilers are bad because it is closed source", are examples of Begging the question.

      • Re:which begs the question (Score:5, Informative)

        by fredrik70 ( 161208 ) on Sunday February 23, 2003 @10:11PM (#5368138) Homepage
        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)
      • "Begging the question does not mean what you think it means."

        Actually I think you are wrong. I do not for one second doubt that your interpretation was the original meaning, but when almost everyone uses it to mean what the original poster did, then "begging the question" has taken a new meaning. It really DOES mean what the original poster used it to mean.

        Besides, this new meaning is much more obvious than the old one.
        • but when almost everyone uses it to mean what the original poster did, then "begging the question" has taken a new meaning

          Except that we're thankfully not at that stage yet - this usage is common amongst North Americans (as are errors such as using "loose" when they mean "lose"), but is not widespread elsewhere.

  • Big deal! (Score:2, Funny)

    by Anonymous Coward
    Let me tell you something, I've compiled not only under wine, but on vodka, whiskey, shit even ACID. And when I was on acid, my monitor tried to eat me...

  • compiling? (Score:5, Insightful)

    by Anonymous Coward on Sunday February 23, 2003 @09:44PM (#5368015)

    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.

    • Actually (Score:3, Insightful)

      by Sycraft-fu ( 314770 )
      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.
  • GNU/Build GNU/natively GNU/on GNU/a GNU/computer GNU/using GNU/a MS-Windows/compiler GNU/without GNU/a MS-Windows/computer!
    • I know my cat likes to sleep on my keyboard. I'm just trying to figure out how she managed to post to Slashdot.

      And better than some of mine too.

      Funny thing is that I don't recall giving her a user account, so she's either stolen my password or rooted my box. And she looks so innocent sleeping over the sofa.

      Guess my momma was right when she warned me felines were devious little fuzzballs.

      (No, she's not named after the Friends character. She's named after Phoebe Snow. No, not the singer, the "train babe." Sheesh.)

      KFG

  • Compiling under wine eh? (Score:3, Funny)

    by trotski ( 592530 ) on Sunday February 23, 2003 @09:48PM (#5368034)
    Last time I tryed to compile something under the influence of (way too much) wine, I ended up on the floor infront of my computer. All I remember was waking up to a formatted hard drive; compiling under the influence of wine sucks!
  • wine compiling cygwin compiling wine compiling cygwin compiling....

  • WRONG! (Score:5, Insightful)

    by www.sorehands.com ( 142825 ) on Sunday February 23, 2003 @09:49PM (#5368049) Homepage
    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.

    • Re:WRONG! (Score:5, Informative)

      by spinkham ( 56603 ) on Sunday February 23, 2003 @10:50PM (#5368270)
      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.

    • Re:WRONG! (Score:5, Funny)

      by Jah-Wren Ryel ( 80510 ) on Sunday February 23, 2003 @11:05PM (#5368329)
      Duh! If it compiles it must be fine! What kind of newbie developer are you?

    • Re:WRONG! (Score:3, Informative)

      by bluGill ( 862 )

      It does not require a slow machine to find performance bottlenecks, it requires a fast machine! Anyone who wants to improve the preformance of code needs a profiler to find those places, but profilers slow down your code themselves, so you need a faster machine to get the same speed. In theory you can find the slow spots on a slow machine, but you are wasting a lot of time, a fast machine can find the slow areas in the code faster.

      That isn't to say you never run on a slow machine, but if you determin it isn't fast enough on a slow machine you need the fast machine to find those slow areas.

      If you try to improve performance without a profiler you waste your time optimising parts of code that are plenty fast, while often ignoring the part of code that is the problem.

      One man I know optimised every line in his program that was too slow, and got a 1% speed improvement. After that he used a profiler and discovered his program was spending 60% of its time doing arctangents, which is done in the library and was optimised by smarter people than him. Excpet they assumed you would build a bridge with their function so they used newton's mythod to get about 15 decimal places of accuracy. His program didn't need that much acuracy, in fact the first thing it did after getting the arctangent was chop off everything after the decimal place. By implimenting his own arctanget he was about to get his program to spend 2% of the time doing arctangent, and the program ran twice as fast. However without a profiler he could never have discovered the problem.

  • Visual C++ under WINE (Score:5, Interesting)

    by kruetz ( 642175 ) on Sunday February 23, 2003 @09:52PM (#5368061) Journal

    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.

    • Well I downloaded the latest GVIM for windows this evening and finally installed the ole for visual studio. Not exactly VC++ under linux, but a little vi in the VC sure is sweet! I might even actually play with it now.

  • Windows Compliant / Posix Compliant Drivers (Score:3, Interesting)

    by PetoskeyGuy ( 648788 ) on Sunday February 23, 2003 @10:01PM (#5368098)

    I'm a programmer for a Supplier of Software to the US Government and we are actively looking to port our products to Linux do to the strong interest from our clients. Specific Offices decide what products they want to implement and how to do it. We are investigating Emulating Windows as an one solution.

    I look forward to the days when any program that is Windows Compliant runs on any platform that supports the Windows API.

    That being said, the real problem I have is DRIVERS for my hardware working under Linux. If someone could emulate Windows enough to use standard Windows Drivers, there would be no more reason to use Windows at all. I truly commend those braves souls and companies who write drivers for Linux.

    Now if there was a Proxy that accepted Microsoft SQL requests and sent them to a PostgreSQL backend transparently we would be free of the beast and save the Tax Payers lots of money paying my paycheck, plus blow our competiters out of the water. :o)

    • Hey, you know, if there is anybody who could pull off this Hardware Abstraction Emulation stuff, it'd be those sharp critters over at Connectix.....what's that, they were acquired by Microsoft?. Never mind.
    • Novell had something similar to this (SQL proxy) a few years back called SQL Integrator - however, it looks like it has faded into oblivion due to poor sales. An open-source GNU solution would be pretty nifty. It would have to handle different feature sets & emulate certain commands... perhaps something with plugins to add support for different database types. (Novell does something similar with DirXML - a product that syncs different directory services databases with plugins that support each type of directory, such as ADS, NDS, LDAP, PeopleSoft, etc.)
    • Doesn't Postgres have an ODBC driver? Any reason why you aren't using it?

  • GNU! (Score:3, Funny)

    by Dunkalis ( 566394 ) <crichards@gmx.COWnet minus herbivore> on Sunday February 23, 2003 @10:02PM (#5368104)
    Wow! So RMS wants us to simply call it GNU now? Dropping the Linux part altogether? Sorta hypocritical to me ;).

    Or do you run Hurd? Which is technically the GNU OS.

    The above is meant to be funny.
    • For all we know, he is running a BSD kernel with GNU system software. The point is, it doesn't much matter what kernel he is using. We can't even tell. So why write it down?
    • Wow! So RMS wants us to simply call it GNU now? Dropping the Linux part altogether? Sorta hypocritical to me ;).

      Or do you run Hurd? Which is technically the GNU OS.

      He does mention Linux -- Mandrake specifically. But I agree, calling it GNU is a bit confusing (he also calls XFree86 "X-Windows", and refers to Unix-style text files as being in "GNU format").

      As others have mentioned, running the command-line compiler isn't all that much of a feat. I was a bit disappointed that he "hand edited" all the #include directives to correct the case -- something that could be done with a Perl in-place edit...
  • ...a no nasty headaches from the sulfides.

    Try Maryland Wines [marylandwine.com], esp Bordy
    and Beer [pubcrawler.com], esp Oliver Ale !

  • GNU computer? (Score:3, Funny)

    by arvindn ( 542080 ) on Sunday February 23, 2003 @10:03PM (#5368107) Homepage Journal
    Does this guy really use the HURD, or is it just that he's an RMS mega-fan?

  • CVS (Score:5, Interesting)

    by YoJ ( 20860 ) on Sunday February 23, 2003 @10:04PM (#5368113) Journal
    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:CVS (Score:2, Interesting)

      by Anonymous Coward
      Yea, that was my thought. I never copy any source files between any computers, just 'cvs up'. From his article, it sounds like he doesn't use any source control, so my guess he's never worked on a project with other people or shipped any heavily used software. Both require the ability to co-ordinate source code changes and manage releases from a baseline...not to mention a single place to do backups.

      I've been coding Java for a while now, but back in my C/C++ days, I only used the M$ command line tools. They integrate pretty well with a unix-style command line build system. The reverse isn't true.
    • That can cause problems: you'd often want to know that a change compiles+runs on both platforms before checking it into CVS.

      Using CVS as the main communication link between the two platforms means that linux developers can easily break the microsoft build, or vice versa.

  • I use Wine to compile but not for porting (Score:4, Insightful)

    by Captain Rotundo ( 165816 ) on Sunday February 23, 2003 @10:07PM (#5368127) Homepage
    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).

  • 1.0 ? (Score:5, Interesting)

    by IanBevan ( 213109 ) on Sunday February 23, 2003 @10:16PM (#5368162) Homepage

    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:1.0 ? (Score:5, Informative)

      by Papineau ( 527159 ) on Sunday February 23, 2003 @11:19PM (#5368370) Homepage

      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 [www.dssd.ca] 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.

    • Re:1.0 ? (Score:3, Informative)

      by IamTheRealMike ( 537420 )
      I'm curious, what exactly will the "milestone" of version 1.0 of Wine actually mean ?

      It's mostly purely technical targets, for instance the wineserver protocol will be frozen, which means that (I think) you can build WineLib apps and upgrade Wine and they won't break. There are a few other targets, mostly esotoric.

      Wine 0.9 is far more interesting, and will hopefully come out in the last part of 2003. It's focussed on being easy to use and setup.

      A lot of problems people have with Wine are usually related to it being badly setup. Partly that's our fault, Wine isn't especially easy to setup right, and because it releases every month, distro packages are often out of date (and now redhat doesn't even ship it anymore). After being increasingly frustrated with Wine, I tried CrossOver (a slightly hacked up version of wine designed to be easy to use), and it worked so well I was blown away. Installing IE6 in Wine is a distinctly wierd experience :)

      Anyway, I've been using WineHQ wine for quite some time now, but hopefully along with proper setups (DON'T use your pre-existing windows installation etc) Wine will get a much better reputation.

  • This is non-news. (Score:5, Insightful)

    by Doomrat ( 615771 ) on Sunday February 23, 2003 @10:17PM (#5368167) Homepage
    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...

  • Cygwin still doesn't work (Score:5, Interesting)

    by njchick ( 611256 ) on Sunday February 23, 2003 @10:25PM (#5368195) Journal
    Up-to-date Cygwin still doesn't work with the current Wine. Even the simplest utilities like ls.exe crash immediately. Yet the Microsoft's compiler works.

    Another interesting observation - putty doesn't work (the preferences are not displayed), but Internet Explorer works.

    I would except it to be easier to make Wine support applications that have the source available, but the experiment shows that the closed source software works better under Wine. Apparently, there is much more interest in running commercial software, yet it's surprizing to see free software so badly supported.

    • Re:Cygwin still doesn't work (Score:5, Informative)

      by Papineau ( 527159 ) on Sunday February 23, 2003 @11:00PM (#5368310) Homepage

      The putty problem you describe is actually a regression (was working, a patch broke it lately, the problem is known, but I don't know when it'll be fixed). BTW, putty can now be compiled out-of-the-box with Winelib, resulting in a native Unix application.

      The reason IE, Office and MS's compiler are more tested is that there's no 100% equivalent in OSS, so people have an interest in making them work under Wine. Putty is a ssh/telnet application, of which several others exist for Unix. Cygwin doesn't really serve a good purpose running under Wine, because it's main goal is to help in the porting of Unix apps to Windows, except that it really is a good test for Wine internals (headers, threads, files, pipes, etc.).

      That being said, don't forget that OSS (or source available) programs for Windows still use the Win32 API, which is an enormous beast, and for which some parts are not documented anymore (even if still in use). And there lies the bulk of the current incompatibilities with Windows software, not in the source code of a particular program. The other part is mapping Win32 APIs/concepts to the equivalent Unix lib or concept.

    • Does that mean that once they get Cygwin working I can finally:

      run Native WinXP (with remote desktop) ->
      VMWare (Linux) ->
      Wine ->
      Cygwin (with xserver) ->
      VMWare (WinXP) ->
      remote desktop back to the beginning

      All on the same computer?

      Oh Boy! It's what I've always wanted! Thanks, dad!
    • Why would the Wine developers be wasting time emulating open source software when...well...it's open source? That stuff can just be ported directly if it hasn't already. No need to waste cycles on a few layers of extra code that way.

      Then again, putting emulators inside each other is a good way to see if they really really work. Kind of like running text back and forth through babelfish...

  • An unbiased assesment (Score:5, Funny)

    by geeber ( 520231 ) on Sunday February 23, 2003 @10:27PM (#5368199)
    "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!"

    He thinks it's interesting. Imagine that - he wrote the damn article. Of COURSE he thinks it interesting.
  • Next you will have some moron compiling under vmware or bochs or plex86. If you don't care about the abstraction or the 60% degradation in performance, and the fact that you have to rewrite all your make files to use vc++ nmake, this is for you. Its a convoluted mess IMHO. Using cross gcc for win32 on linux is a much cleaner way of doing this.

  • GNU/WINE?!?! (Score:3, Insightful)

    by Arandir ( 19206 ) on Sunday February 23, 2003 @11:51PM (#5368470) Homepage Journal
    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!"

  • I do this with a DSP compiler (Score:3, Interesting)

    by statusbar ( 314703 ) <jeffk@statusbar.com> on Sunday February 23, 2003 @11:56PM (#5368493) Homepage Journal
    The Texas Instruments Code Composer Studio for the TMS 6701 DSP is only available for windows. For this project everything else is compiled for Linux-386 as well as embedded Linux-PPC.

    Running the command line tools under wine works fine, and now I am able to have one intel linux box compile all the DSP and PPC firmware as well as the Linux GUI code in a cron job from the daily cvs snapshots.

    Doing this has made things SO much nicer. I would prefer if TI had a linux version of their DSP compiler, and will continue to pester them for one, but in the meantime WINE saves the day and allows me to NOT run windows for weeks on end!

    My Win2000 anti-uptime is around 3 weeks now. I am weaning myself off windows!

    Running command line tools like compilers is one of the EASIEST things for WINE to do - All they have to do is read and write files and allocate memory.

    Biggest hassle for me: having to make special sed scripts to deal with mixed case file names in the auto-generated makefile dependency list that are incorrect since the compiler assumes case insensitive filesystems.

    --jeff++

  • weird... (Score:5, Funny)

    by dolson ( 634094 ) on Monday February 24, 2003 @12:06AM (#5368534) Homepage Journal
    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.

  • heh... wine... (Score:3, Funny)

    by doooras ( 543177 ) on Monday February 24, 2003 @01:23AM (#5368811)
    i prefer to compile under rum

    *hic*

Slashdot Top Deals

"A great many people think they are thinking when they are merely rearranging their prejudices." -- William James

Close