Weekly Edition
Return to the Development page
| |||||||||||||
Wine to Reach A Major Milestone
In just a few weeks, Wine
will be reaching a major milestone: a beta release.
Until now, Wine has been one of the largest projects under
development that has never seen a beta. Wine's codebase is
approaching 1.5 million lines, contributed by nearly 700 individuals
over the past 11 years. Two successful commercial products are based
on the code, and it is used in a production environment by several large
corporations. While Wine often catches flack within the open-source
community for bringing Windows compatibility to Linux, there are two
facts that are undeniable:
Wine's acronym paradoxically comes from both the phrases WINdows Emulator and Wine Is Not an Emulator. Don't worry, Wine's developers really don't care (much) which you prefer since it fits both descriptions to some degree. At its core, Wine is an implementation of the Win32 API designed to run on top of Unix-like operating systems. KDE, of course, relies on Qt and GNOME on GTK, and in this regard Wine simply implements yet another API. The difference is, Win32 was designed by Microsoft and happens to be one of the most widely used APIs in existence. The Wine beta release will come at an interesting time. Microsoft is not planning on releasing any major new API components until Windows Vista ships. Even then, it will be a while until any major applications require the new API. As a result, Wine has a few years to stabilize the existing APIs. Besides implementing the Win32 API, Wine contains several unique features for running Windows programs on Linux. On Linux, the ELF binary format describes executables and libraries. Microsoft uses a different format, PE (Portable Executable), for the same purpose. The PE format is more complex and allows multiple resources to be embedded in one file. Wine implements a special loader to open PE files. Windows also contains primitives, such as threading, that are much different than on Linux. Wine's wineserver is used to synchronize between threads and processes using custom IPC code. It performs many of the low-level functions done by the kernel on Windows. If that isn't exciting enough for you, Wine also comes with winemine, a minesweeper game. Wine's architecture has stabilized quite a bit over the past few years. Items tackled just this summer include:
A lot of things are in the process of being cleaned up for the beta release. Wine's application database, which lists compatible applications, has seen a complete overhaul over the past year. Some new capabilities have been added in the past few weeks. Work is underway to rewrite major portions of the Wine User Guide to bring it up to date. Finally, wine's Bugzilla bug database has been pruned of items that have been fixed. So let's be realistic, how well does it work? Thanks to recent work done by CodeWeavers, most Windows programs now install. For a long time, just getting a program to install was a huge hurdle, things have really improved in that area. Many small to medium-sized programs run just fine, though you may notice little discrepancies. Larger programs, such as Photoshop, Word, Excel, or Quicken can be coaxed into running, but they have traditionally suffered from regressions in Wine. As a work-around, CodeWeavers' CrossOver Office is able to run those programs, so the technology is definitely capable. Games usually don't run out of the box because of copy protection schemes that aren't compatible with Wine. The focus of the beta release is to provide a starting point for stabilizing Wine. Tons of bugs need to be fixed and entire APIs remain to be finished off. The beta release won't be a magic bullet that suddenly makes Wine perfect, but all of the tools and interfaces will be in place. It will also be feature complete from a packaging standpoint, and distributions are encouraged to begin testing integration. For anyone interested in development, there's still a lot of work to be done and plenty of ways to get involved. Stay tuned to WineHQ for announcements. (Log in to post comments)
Curious about coverage Posted Oct 6, 2005 5:27 UTC (Thu) by felixfix (subscriber, #242) [Link] Not being a Windows programmer or even user, I am curious how well Wine works from a Microsoft internals programmers perspective. I have heard that the Microsoft API is quite, err, flexible, in changing from time to time, that it is harder to maintain compatibility between Windows releases than among the various different flavors of UNIX. Perhaps some Microsoft developers have taken looks at offbeat corner cases and either snickered or applauded. Would anyone in the know care to comment?
Curious about coverage Posted Oct 6, 2005 19:34 UTC (Thu) by sbergman27 (guest, #10767) [Link] This is not what I hear from the Wine developers. The Wine developers have said that although it is sometimes reported that the win32 API being a moving target makes it hard for Wine, that's not really true. Applications developers still want their stuff to run on, say, Windows 98. Undocumented, poorly documented, and buggy API calls seem to be a bigger problem. Wine has to reproduce even the API bugs faithfully.
Wine's main problem, last I looked, was its incompleteness. Many API functios being simply stubs which do nothing but print "FIXME".
To be honest, when I encounter a situation in which I am forced into the position of trying to run a app for a client under Wine, I don't go into it with much hope.
On the other hand, I have seen wine do some amazing things. Back in 1999 or so, I got the original "Unreal" running under Wine. It took a solid weekend of work, but when I was finished it worked absolutely perfectly, with 3DFX Voodoo Glide accelleration at 800x600, perfectly synchronized sound, and perfect stability. I played the whole game through twice without a single crash. I even compared my frame rates with someone with similar hardware and won.
The problem is, you can then turn around and run something really simple and it will crash even before the main window comes up.
I must say I have never seen a project that progressed with such agonizing slowness as the Wine project. Not a criticism of its developers. They've simply taken on a *big* job.
Curious about coverage Posted Oct 6, 2005 19:48 UTC (Thu) by felixfix (subscriber, #242) [Link] I am more curious about coverage in general than how far it lags behind the moving target. I am especially curious about Microsoft internals developers who have looked at its coverage of corner cases out of curiousity. I know if I were in Redmond working on the OS, or working on an app which I knew had special code in the OS, I would be quite curious about how well WINE handled it, how much of the secret internal goofiness was reverse engineered.
Wine to Reach A Major Milestone Posted Oct 8, 2005 1:03 UTC (Sat) by giraffedata (subscriber, #1954) [Link] This milestone is apparently just a statement from developers that they will start trying harder than before to stabilize the release. It's obvious that Wine has been in beta test, and full production, for years.Incidentally, since people sometimes misunderstand the terms, here is what alpha and beta test mean: Alpha test is the test done by developers by simulating work loads. Its only purpose is to find bugs; not to get any work done. If the program is an editor, alpha testers would pretend to edit files and try various sequences of commands, but they will just throw the file away when the test is done. In the commercial world, you have to pay people to do alpha test The quality of alpha test is limited by testers' imagination. Beta test is a test done in real production. A real user performs a real job using the code under test. In the editor case, the beta tester would use the code to prepare an actual web page or update a real config file. But half the purpose of the work is still to find bugs. The beta tester knows the code hasn't been fully tested yet, therefore has bugs, so is careful about how much he depends on it. In the commercial world, you can often get beta testing for free (perhaps more precisely -- you can get beta testing for nothing more than a chance to get early access to the code). Full production is like beta test except that there is no objective, or expectation, to find bugs. In small open source projects, there is no meaningful difference between a beta test and production.
|
|||||||||||||