Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
×
Wine Software Linux Business

No WINE Before Its Time 192

Joe Barr writes "Stephen Feller has a story about WINE on NewsForge this morning ahead of next week's expected Beta release. The WINE project is 12 years old, so it's just about time." From the article: "'Wine has historically had a very frustrating history because it has been alpha software,' White said. 'This is really hard work. We're replicating the work of a billion-dollar company. The reason we're saying it's alpha is because we believe we still have fundamental changes to make on the way the internals work.' Noting that it has not always been easy to install software with Wine's alpha releases over the last decade, White said that once you got something working it has never meant it would continue to do so, or do so properly. There may have been display glitches or things not functioning properly, if a program even worked with Wine at all." OSTG is the parent company of both Slashdot and NewsForge.
This discussion has been archived. No new comments can be posted.

No WINE Before Its Time

Comments Filter:
  • More info.. (Score:5, Informative)

    by jkind ( 922585 ) on Saturday October 22, 2005 @12:54PM (#13853113) Homepage
    LWN.NET has a good rundown of new features, including Direct X 9 support and a new RichEdit control :)
    http://lwn.net/Articles/154451/ [lwn.net]
  • by xactuary ( 746078 ) on Saturday October 22, 2005 @12:58PM (#13853135)
    The post reminded me of an old wine quote which I've used quite often... Just take a sip and say, "A naive domestic with little breeding, but I'm amused by its presumption."

    Cheers.

    • Heh, actually a caption to a 1940s James Thurber drawing. A host offers a glass to a guest: "It's a naive domestic Burgundy without any breeding, but I think you'll be amused by its presumption."

      I don't seem to be able to find a scan of the actual cartoon online anywhere, oh well.

  • Yes but.. (Score:4, Funny)

    by Anonymous Coward on Saturday October 22, 2005 @12:58PM (#13853137)
    Does it run linux?
  • VisualStudio Plugin (Score:5, Interesting)

    by Anonymous Coward on Saturday October 22, 2005 @01:01PM (#13853150)
    I think it would be incredible to have a VisualStudio plugin that would allow developers to target the Wine API and at least indicate if a particular API will not be supported under it. That way it makes the API less of a moving target in that it establishes WINE as the authoritative API for development of Windows applications that will work across platforms. Once people recognize that Windows is not the way forward they will appreciate having their options open.
  • by fm6 ( 162816 ) on Saturday October 22, 2005 @01:02PM (#13853153) Homepage Journal
    The reason we're saying it's alpha is because we believe we still have fundamental changes to make on the way the internals work.
    Microsoft seems to have the same problem.
  • vista (Score:5, Interesting)

    by CDPatten ( 907182 ) on Saturday October 22, 2005 @01:05PM (#13853173) Homepage
    How will Vista affect this beta release?
  • Wine for OSX (Score:5, Interesting)

    by Dr. Spork ( 142693 ) on Saturday October 22, 2005 @01:12PM (#13853199)
    You know, starting about next year, WINE will suddenly find a new big customer base, provided they can abstract the design enough to run on OSX-x86. I'm not sure how much work that would take but it certainly seems worth doing. I imagine that the people on OSX with an urge to run Windows apps will outnumber users of Linux with the same urge. Hell, if I were Codeweavers, I'd be working really hard on CrossoverOSX. There might even be good money in it!
    • Re:Wine for OSX (Score:3, Interesting)

      by FidelCatsro ( 861135 )
      I expect a large influx of funding from Apple(perhaps already has occurred and they wanted it kept quiet) , Darwine has been underway for a while already http://darwine.opendarwin.org/ [opendarwin.org] so they already have begun to tie it to the kernel .
      • Re:Wine for OSX (Score:5, Insightful)

        by fm6 ( 162816 ) on Saturday October 22, 2005 @01:47PM (#13853344) Homepage Journal
        No matter how quiet they did it, it would get back to Microsoft — and the repercussions would be extreme. The Mac still relies heavily on Microsoft's goodwill.

        The idea of running Wine on Intel Macs probably occurred to every WINE enthusiast roughly 300 milliseconds after Apple announced they were abandoning POWER. No doubt many people are working on it, including Codweavers. But forget about financial support from Apple.

        • Darwine is a project on the OpenDarwin site ,OpenDarwin was started by Apple and ISC to develop the kernel .
          to quote

          Many OpenDarwin members are either Apple employees or committers to Apple's CVS repository, who have an active interest in merging technologies from OpenDarwin.org into Darwin and Mac OS X releases..

          Pure speculation of course
          Some apple employs in their spare time working on the Darwine project , getting extra bonuses at Christmas and long holidays .

    • Codeweavers already announced that they were working on that codebase.

      I can't find the announcement, but have a line from the last WINE CVS drop changelog:

      * Some fixes for MacOS/x86.
    • by timeOday ( 582209 ) on Saturday October 22, 2005 @01:58PM (#13853394)
      I'm not sure it's such a good fit:

      Mac: It Just Works.

      Wine: Whoah, something almost worked!

      • Re:Wine for OSX (Score:3, Informative)

        by ultranova ( 717540 )

        Wine: Whoah, something almost worked!

        Wine used to work somewhat, back when all configuration was done with a config file, because then you could just copy-paste it from the Net. However, then some nincompoop decided to remove support for the text config in favor of graphical configuratio tool, which not only makes it harder to config things (since you can't just copy-paste config file from Net anymore), but apparently doesn't properly save little details like "is this drive the CD-ROM or hard drive", ev

        • Re:Wine for OSX (Score:2, Interesting)

          by esarjeant ( 100503 )
          Agreed -- while the Wine project is a valiant attempt to simulate the Windows API calls, it simply doesn't provide the transparent support necessary to enable all of your Windows apps. While it comes very close, and there are at least a few cases where you will be pleasantly surprised, you will be much happier discovering the open source alternatives for your favorite Windows app.

          The only place where this falls apart is when you want to play a game on your PC. The fact is, developers support the Windows pla
        • Do yourself a favor and stay away from Wine - as it is, it's just a waste of good diskspace.

          While I agree that Wine is sometimes barely useful, the people from CodeWeavers [codeweavers.com] make a really useful release every now and then. It's really stable, if you use the supported applications (check their website, mainly MS Office). The download version is $40.

          No hidden agenda, just a satisfied customer.

      • by Burz ( 138833 )
        Wow, It Nearly Executed!
    • Re:Wine for OSX (Score:4, Informative)

      by pwagland ( 472537 ) on Saturday October 22, 2005 @02:07PM (#13853429) Journal
      Hell, if I were Codeweavers, I'd be working really hard on CrossoverOSX. There might even be good money in it!
      http://www.codeweavers.com/about/general/press/?id =20050622 [codeweavers.com]

      It would appear that you are not alone...

      • I never claimed that the idea was original or non-obvious, though I didn't expect something to have already been announced. Thanks for the link.

    • I imagine that the people on OSX with an urge to run Windows apps will outnumber users of Linux with the same urge. Hell, if I were Codeweavers, I'd be working really hard on CrossoverOSX. There might even be good money in it!


      IIRC I heard that they were on the wine list.
  • Obsolete model? (Score:5, Interesting)

    by Slashdiddly ( 917720 ) on Saturday October 22, 2005 @01:13PM (#13853202)
    Could it be that the hardware improvements made over the last 12 years may have made library-level emulation unnecessary? Device-level (eg, vmware) and architecture-level (eg, virtual pc) are both simpler and more robust.
    • Could it be that the hardware improvements made over the last 12 years may have made library-level emulation unnecessary? Device-level (eg, vmware) and architecture-level (eg, virtual pc) are both simpler and more robust.

      Sure you can run Windows on a virtual machine, but you need a legal copy of Windows first. WINE allows you to run Windows applications without having to pay Microsoft any $$$.

      Also applications running in a VM are captive within the VM's window. I like the ability to move/resize/manage
    • Re:Obsolete model? (Score:2, Informative)

      by CaraCalla ( 219718 )
      You certainly have a point there.

      But:

      • Try running a graphic intensive application (eg. a game) inside VMWare.
      • More generally, there will always be applications which require the latest and fastest hardware. In that case you do care about emulation overhead.
      • You still need a Microsoft License.
      • While in VMWare's case integration between native and emulated apps is pretty good (filesystem, clipboard), its not even close to being on par with Crossover Office and wine.
      • Wine is not an emulator :-)

      --
      sig:

    • Could it be that the hardware improvements made over the last 12 years may have made library-level emulation unnecessary? Device-level (eg, vmware) and architecture-level (eg, virtual pc) are both simpler and more robust.

      Of course Wine is obsolete. It was designed over 10 years ago and obviously technology has improved since then. Who cares that they've made incremental improvements.

      Oh wait. That's the argument for getting rid of Hubble. Never mind.

  • by shumacher ( 199043 ) on Saturday October 22, 2005 @01:13PM (#13853206)
    In the hardware-side x86 world, at least for the last fifteen years or so, you could buy a complete system, and no single company could be guaranteed a cut. AMD might get money, Intel might get money, but nobody had it locked down. Over time, the x86 has become something of a standard hardware platform. With WINE, I'd love to see a Windows Standard Base created. A single software environment that would be very commonplace, widely supported, shipped on almost all hardware, but not tied to a single company. In a sense, push Microsoft in software where IBM went with hardware. Eventually, you'll see vendors start creating secure versions, embedded versions, silly hacks to the PSP, and the money could go anywhere. Microsoft's Windows division could use some more direct competition.

    Wouldn't that be great, or am I wrong?
    • problem is that its like trying to base a open document format on something that have its basis in the ms office files.

      yes it can be done, but you still have one company that controls the basis. therefor there is no need for embrace, just extend, and watch all the rest chase their tails...
      • That's the thing. IBM tried to force the market to Microchannel, and instead of the x86 world following, IBM found themselves on a incompatible, and largely unsupported fork. Microsoft could find themselves in the same boat if they try steering Windows just to break the base.
  • by AHumbleOpinion ( 546848 ) on Saturday October 22, 2005 @01:21PM (#13853235) Homepage
    This is really hard work. We're replicating the work of a billion-dollar company.

    Yes and no. It is a little simpler than this quote suggests. Wine does not need to implement every API that Microsoft produces. It needs to implement every API that desired Windows applications use. In some ways it is a quality of service problem, the marginal cost between supporting 90% of apps and 100% of apps may be too expensive. Maybe 80% to 90% is too expensive. I don't pretend to know what the optimal percentage is but it is surely not 100% or even mid to high 90%s.

    In any case this is a monumental task and the Wine developers deserve an awful lot of credit and thanks.
    • Wine does not need to implement every API that Microsoft produces. It needs to implement every API that desired Windows applications use.

      Except users come in all flavors, and the list of desired apps is probably as long as the API list. And sometimes building the system is just as much work as building the API, if you want to do the "desired" parts of the API the rest just naturally fits in. In the end, they're still trying to recreate most of what Microsoft has made.
    • by IamTheRealMike ( 537420 ) on Saturday October 22, 2005 @02:29PM (#13853524)
      It's not quite that simple I'm afraid.

      Take the recent DCOM work we did. This is what I'm going to talk about because it's what I know - myself (CW) and Rob Shearman (CW), along with some help from Marcus Meissner (Novell) and Huw Davies (CW) reimplemented large parts of DCOM mostly for one application. The work took many months - starting from a pre-existing codebase written by Marcus years earlier, we were "finished" ~135 patches later.

      What was that one application which was so important?

      InstallShield.

      Now perhaps you see the problem - sure, not every API is used by every app. But there are hundreds of thousands of APIs, many extremely complex, and many millions of applications. All it takes is ONE popular application to use a single API that was not yet reimplemented and you have months of work ahead of you.

      This is especially true of something like DCOM where the supporting infrastructure for 4 or 5 functions can run to 10,000+ lines of code.

      • by AHumbleOpinion ( 546848 ) on Saturday October 22, 2005 @06:47PM (#13854591) Homepage
        Please don't misunderstand. I am not suggesting that targetting a subset of MS APIs is fast or easy. I've been down that road in a product far more limitted in scope than Wine, it was painful for us too. I just wanted to clarify that a successful project does not need to be a perfect, or even near perfect, Windows clone (API perspective). I suspected that some readers would focus on the entirety of MS APIs and I wanted them to reconsider doing so.

        Your point is well taken but it really seems to address how to pick which APIs go into that xx% that gives you optimal coverage. Optimal coverage is also not something that is fixed. Naturally as new or updated apps come out there will be more work (and pain) for the Wine developers. I guess another way to describe the point that I was trying to get at is that there is a lag between Microsoft introducing APIs and applications beginning to use those APIs, and that it would seem the latter is more important than the former. Adopting a new API can be tricky for a developer because that API may not be supported on older versions of Windows. I'm guessing here but I would expect apps with broader appeal, and more importance to the average Wine user, would be more resistant to requiring newer APIs with little backwards compatibility. I would expect that apps that immediately jump on new APIs and ignore backwards compatibility would tend to be more specialized and more niche oriented and less likely to be needed by Wine users. Again, just guessing.

        Maybe this leads us to a way to estimate what xx is. Take the top 10 most commonly used apps, what APIs are used? Now the top 50, then top 250. Plot the % of API coverage required, maybe we'll have a useful curve.
    • It needs to implement every API that desired Windows applications use. In some ways it is a quality of service problem, the marginal cost between supporting 90% of apps and 100% of apps may be too expensive. Maybe 80% to 90% is too expensive. I don't pretend to know what the optimal percentage is but it is surely not 100% or even mid to high 90%s.

      I disagree. There are lots of people who need Windows for some purpose, but in order to accomplish that purpose, they need more than one app.

      For instance

      • So, just to take some numbers at random, let's assume I need 10 apps to work in order not to need to have a Windows machine. And let's assume that 90% of apps work under WINE. What are the odds that all 10 apps that I need are going to be available? Well, it's (90%)^10, which is about 35%.

        I disagree with your analysis. Your first flaw is that you ignore the requirements of your formula. The 90% of all apps working under Wine are not chosen at random, they do not have equal "weight", they are chosen by p
  • Good clone (Score:5, Funny)

    by Baramin ( 847271 ) on Saturday October 22, 2005 @01:38PM (#13853308) Homepage Journal
    White said that once you got something working it has never meant it would continue to do so, or do so properly. There may have been display glitches or things not functioning properly, if a program even worked with Wine at all.


    That's what I get from WinXP on a regular basis, so I guess I could stand using Wine.
  • ABRs of OSS (Score:5, Interesting)

    by Doc Ruby ( 173196 ) on Saturday October 22, 2005 @01:39PM (#13853310) Homepage Journal
    "Alpha" is not a subjective measure of the quality or maturity of code. Alpha means the code has never been modified by feedback from testers who are not part of the development team. "Beta" means code that has been or is being modified after receiving beta test results from people without the expectations, therefore the blind spots and other biases, of the developers themselves. Alpha tests are important, but beta tests are much more important to determine whether the code will be acceptable by its users, especially when those users aren't the developers. The "release" test is a more subjective delineation, especially since Netscape got everyone to accept that we'd use "beta" software the same way we'd use a general release.

    So WINE might have good reasons (eg. moving Microsoft target) for remaining relatively "immature", incomplete, or buggy. But once they revised it on feedback from people outside the WINE development team, it is beta, regardless of what they call it.

    This is not a semantic argument. It's a very important point about how development/testing patterns affect code quality. Incorporating the "social" aspects of development, and their constructive/destructive effects on projects, makes development more productive. This is especially true of OSS, as projects often lack the discipline that comes with keeping the code hidden from "outsiders". Without the proprietary discipline, the alpha/beta/release discipline lets OSS projects have more flexibility, and therefore more productivity when used right. Without even the alpha/beta/release discipline, OSS projects need another to produce quality, or fail to do so.
    • Re:ABRs of OSS (Score:2, Informative)

      by AlbertEin ( 924430 )

      From http://en.wikipedia.org/wiki/Development_stage [wikipedia.org]

      Alpha: The alpha version of a product still awaits full debugging or full implementation of all its functionality, but satisfies a majority of the requirements. It often lacks features promised in the final release, but demonstrates the feasibility and basic structure of the software

      Beta: A beta version or beta release usually represents the first feature complete version of a computer program or other product, likely to be unstable but useful for

    • Netscape got everyone to accept that we'd use "beta" software the same way we'd use a general release.
      I thought that was Google?
  • Or do others feel that multibillion dollar companies get away with selling alpha software? As far as I can remember, most companies put out alpha and beta software to let users test it in production environments. I could name a few here, but we have all probably dealt with this issue.

    One thing that is nice to see, the group developing Wine have no illusions, and freely admit that you might have problems using the software. Despite that, I know many people who use Wine so they don't need MS operating systems
    • "Or do others feel that multibillion dollar companies get away with selling alpha software? As far as I can remember, most companies put out alpha and beta software to let users test it in production environments. I could name a few here, but we have all probably dealt with this issue."

      One word: marketing. That's how you get away with selling alpha software. You market an alpha-qaulity product to look like something that works as good as it should, and if your marketing campaign successfully ropes in eno

    • Just imagine, and Digital kept pushing their Alpha CPUs on everyone. The didn't even make it to Beta, and it's no wonder that HP scrapped thier remains.

      Or, you could perhaps look at the software to see if it meets your needs, and not get so excited about the release name / revision. Considering that there are not a lot of ways to make Windows executables run on Linux, even a pre-that-thing-before-alpha sounds better than nothing at all.

      And no, virtual machines running windows isn't the same thing as runni
  • by Baldrson ( 78598 ) * on Saturday October 22, 2005 @01:59PM (#13853404) Homepage Journal
    The FTC should have been requiring M$ to publish its API from the first day IBM shipped MSDOS with the 4.77MHz 8088 PC.

    It should require M$ to publish all of its APIs now and verify that all M$ applications are written to those published APIs. Moreover, it should require that all communications between the application development portion of M$ and the operating system portion of M$ are public domain.

    • Err... is there some sort of analogy for opening the specs of a complex and mostly-monopolized system so that competition is possible? I mean, if I were an 80 year old judge and the most complex technology I understood was the telephone, how would you sell me on this idea?
      • Easy. The telephone system in the US went through exactly this process. It was once a monopoly. The phone company even owned the phone lines within your house and the telephones: you just rented them. You had to get your equipment from them and have them do all the service. Of course, this meant no competition and it suppressed innovation since depending on the case it was difficult or impossible to add third-party equipment to the system. Now, in contrast, there is competition and you can hook anything u

        • Even better analogy (Score:3, Interesting)

          by Lifewish ( 724999 )
          With the advent of local loop unbundling, it's possible to have another phone company hook your handset up to the rest of the country, by allowing them to implement the backend half of that specification. The result is ultra-fast dark fibre MANs in places like France, Italy and Japan (iirc anyway). By comparison, bandwidth rates in most of the US stalled years ago - the only counterexample is New York, and that was only an attempt to wipe out the cablecos.

          (I worked for a business analysis company special
        • sounds sort of like apple.

  • ReactOS and WINE (Score:5, Interesting)

    by Anonymous Coward on Saturday October 22, 2005 @02:12PM (#13853454)
    In case anyone doesn't know. The ReactOS project [reactos.com] works closely with WINE. They are implementing the API from WINE on a replica of the Windows 2000 kernel.

    This means that both Windows drivers and applications will work natively without any changes. They seem to have come on leaps and bounds in the past year with many applications working straight away (OpenOffice, Abiword, mIRC, Unreal Tournament, InfranView, PuTTY as some). Once they start implementing some of the security features then there will be another viable alternative.

    In the future I can imagine ReactOS coming on a CD with OpenOffice, Apache etc, much like Linux distributions do, which creates an easy migration path:

    Windows + Apps -> Windows + OSS Apps -> ReactOS + OSS Apps then then off to a Linux or *BSD varient if you want.
    • Re:ReactOS and WINE (Score:4, Informative)

      by TwoTailedFox ( 894904 ) <TwoTailedFox@Gmail.com> on Saturday October 22, 2005 @02:16PM (#13853480) Journal
      Replica? Almost. ReactOS is designed to be compatible, first-off, with Windows NT 4.0.

      Networking is the next big leap for the 0.3.0 ReactOS Release. Some parts work quite well already.
  • Wine? (Score:3, Funny)

    by Geoffreyerffoeg ( 729040 ) on Saturday October 22, 2005 @02:35PM (#13853549)
    The WINE project is 12 years old, so it's just about time.

    In other words...it aged for 12 years?
    • Actually, this is an important observation. It tells us that WINE is a red wine. Nobody would age a white wine for that long.

      • Totally off-topic, but I have been to Slovenia last year, and the proud employee of a wine cellar ("We even export to France!") showed me their long-term white wine cellar; some of the bottles there were 50 years old.

        He told me the old whites were very pleasing to the taste buds, and in the dictatorial 'communist/socialist' age many a bottle has been poured down the throats of party officials.

  • Somebody should port WINE to Windows, so then you wouldn't need Linux to run Windows applications.

    <EmilyLitella>Oh, never mind.</EmilyLitella>

    -Don

  • It looks like the next version of Windows will be coming out pretty soon then. :)
  • >>[...]once you got something working it has never meant it would continue to do so, or do so properly. There may have been display glitches or things not functioning properly[...]

    Are they talking about Wine here or Windows?
  • The reason we're saying it's alpha is because we believe we still have fundamental changes to make on the way the internals work.'

    By that definition, I'd ask if MS-Windows has ever been out of an Alpha development state.

"...a most excellent barbarian ... Genghis Kahn!" -- _Bill And Ted's Excellent Adventure_

Working...