Slashdot Mirror
No WINE Before Its Time
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.
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.
How will Vista affect this beta release?
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!
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.
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?
The core API is definately C, but most of the ancillary libraries are C++. Pretty much anything COM based is C++ (DirectX, OLE, GDI+, etc...).
Not that I agree with the original poster, you can certainly emulate C++ in C.
If you need web hosting, you could do worse than here
"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.
--
make install -not war
In case anyone doesn't know. The ReactOS project 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.
Video Production Support
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 specialising in telecoms over the summer vacation. This is one of the few things I can remember after 4 weeks of maths.)
For the love of God, please learn to spell "ridiculous"!!!
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.