(This page uses style sheets.)
Wine stands for “Wine Is Not an Emulator”, and full details can be found at http://www.winehq.com/.
The development of Wine started around 1993 by Bob Amstadt who was running GNU/Linux and Windows on the same machine. GNU/Linux software had reached the point where it was capable of meeting most of his needs, but he had some games programs he was very fond of which were only available on Windows.
Fed up of re-booting just to run games he started work on a means of intercepting the system calls the games used and mapping them to the GNU/Linux X environment. Others heard of the work and chipped in to help, until Wine was capable of running the games they wanted to play.
Around 1995 people tried to run other programs, including Quicken and the Office suite, and these applications then became the main area of interest. A separate group split off, continuing the support of the complex graphical techniques used in games but which are in general not used in office style applications. The project now took on a more formalised approach, with a team of core developers and a project leader. Since 2000, the project has been put on an even more systematic footing, with a project leader and support team based in the USA, two small development teams in Canada, and developers in most European countries. Major vendors are also contributing, for instance IBM.
Techniques were created to identify the operating system calls that the programs made. In most cases the development of a small amount of code would enable a given application to run. It was found that programs often make preparations to call a particular interface but then do not actually make the call. Code was therefore written to allow the programs to continue making these preparatory calls without getting immediate errors, as well as code to support actual calls.
The first commercial use of Wine was by Corel, who had done a lot of work in supporting Wine and used it to produce a GNU/Linux native version of Wordperfect 8. Other companies have since used Wine to produce a GNU/Linux version of their products with the minimum of effort and change, one of the latest being Xilinx who produce specialist electronics CAD packages. The Ximian Mono project is likely to use Wine to allow .NET applications written for Windows to work without being rewritten. See http://appde.winehq.com/ for details on the level of support for a range of applications.
Recently a team of experienced Windows application developers has started to produce a suite of test programs to systematically check the 12,000+ system calls currently in the Windows library set.
Currently Wine comprises around 750,000 lines of “C” code implementing around 90% of the calls in popular Windows specifications such as ECMA-234 and Open32. Calls that are not publicly documented are more difficult to implement, but progress is being made.
Some companies working on Wine develop code for particular functions which initially is proprietary. They do this to fund themselves and their work on the mainstream project. They move their code into the mainstream when they have a suitable alternative source of revenue. Support for OLE and ActiveX falls into this category.
Wine intercepts all Windows and DOS system calls together with BIOS interrupts and tries to map them into the GNU/Linux X environment. Native processor instructions are executed as they would have been in the the Windows environment, and therefore Wine is not a full emulator.
Wine is not tied to the Intel x86 architecture – for instance, a version for the DEC/Compaq Alpha exists, but serious demand and usage only exists on x86. It does not enable x86 Windows programs to be run on another architecture such as the PowerPC or SPARC, although Wine will compile and run on both.
Not every interface in the Windows environment can be mapped onto an interface in the GNU/Linux and X environment. Some Windows interfaces simply do not have an equivalent. This means that in some instances a significant amount of code has to be written to support the mapping. For instance, there are problems with the more complex cursors used by some Windows programs. The X Window System cannot cope with more than 2 colours in a cursor, which means that Wine has to make assumptions about what colours to use, occasionally with unusable results.
Wine is actually two products, Wine itself, which allows pre-compiled Windows programs to run, and Winelib, which may be used to compile a Windows program to produce a native GNU/Linux program (this is what Corel used to produce the GNU/Linux version of Wordperfect).
Winelib could be used to run programs on hardware other than x86 if the source code is available, although other architectures specific problems may still exist (for instance endian issues).
Support is available for Windows 3.x/95/98/ME/NT programs (although Windows NT support is less complete). Many programs intended for Windows 2000 will run, unless they use specialised new interfaces introduced with Windows 2000. Little work has yet been put into supporting specific Windows XP programs, but there are very few of them yet.
Wine supports most of the Windows publicly documented interfaces, however, support is not always as complete as one would like. See http://www.winehq.com/?page=status for details on the current state of support in Wine.
Programs that run in isolation or only use external communications interfaces will normally run. Each program should be individually checked because the precise interfaces and parameters used could interact to cause problems.
Some people have reported running compilers and development environments with some success.
Some specific areas are not complete, for example Dynamic Data Exchange (DDE). However many programs make DDE calls without actually using them, and hence will work quite happily. OpenGL and other specialist high-speed graphics areas also have issues. Implementation of Access Control Lists (as in Windows NT) exists in part, but has not yet been integrated with ACLs in the underlying O/S.
VxD device driver technology, introduced with Windows 98, is a difficult area. This needs access to the hardware and kernel internals in a manner that any serious multi-user system could not allow. There are techniques available to produce equivalents but they involve a lot of work and are not guaranteed to work. In some cases the vendor can be persuaded to produce a native GNU/Linux version that uses normal GNU/Linux interfaces. As this architecture is being dropped by Microsoft (Windows NT type architectures will not allow such access) this will slowly cease to be a problem.
Some Windows programs try to manipulate devices directly (especially serial ports). This is not allowed in GNU/Linux, or any other Unix variant. This normally only applies to communications packages such as Procomm, and programs derived from DOS products where such things had to be done.
Rendering of some graphic images is not yet satisfactory, especially TrueType font handling. However this is being actively pursued.
The other difficult area is software developed by Microsoft themselves. This is because these products tend to use undocumented interfaces. While it is possible to discover what is happening, developers have to be careful since the laws on reverse engineering are very strict in some countries. The USA, for example, forbids reverse engineering for any purpose, and most other western countries allow it only for the establishment of compatibility. Thus, work in this area will always be rather slow.
Running application installers, in particular, has been problematic, but recent work has resolved most of the difficulties, and work is continuing. Some of the difficulties are caused by package developers not using recommended techniques. Access to the registry is one example of this. Wine holds its registry in a different format to Windows, to make recovery easier. As long as the documented interfaces are used to access the registry this does not matter, but developers sometimes, at risk of corrupting a real Windows registry, access the registry directly, with the result that the program cannot be made to work under Wine.
Wine is sometimes criticised for poor performance, but this is often due to extensive debugging code. It is possible to compile Wine without this, but this should be done with care as it means that problems cannot be diagnosed without further recompilation.
As mentioned earlier, extended versions of Wine are available as commercial products to support development of the mainstream of Wine. Two companies doing this are Transgaming and CodeWeavers. Transgaming mainly work on improving graphics and sound interfaces and their product is aimed at the games market. CodeWeavers are working on mainstream office applications and have a product, CrossOver Office, which, for instance, supports Office and Lotus Notes.
Visual Basic 3 has been reported to run under Wine, but no details are available.
Visual Basic 6 currently will not install. Work is under way to tackle this, but it is too early to tell whether they will be completely successful or not.
No other versions are known to have been tried.
This is a list of general guidelines to manage the process of migrating applications to GNU/Linux under Wine:
Check the licence conditions. Some companies have issued licences that forbid running their application except on the target operating system. For instance, Oracle used to do this and Microsoft are starting to do it for components that can be freely downloaded; the situation is fluid. Remove any program with such conditions from the test list and make a separate list of them.
Obtain copies of all applications that are to be migrated (this may well be all). Site licences may not allow copies for testing purposes.
Set up a test machine with the latest snapshot of Wine.
Test each and every program on the test list. Note all problems encountered, also note if they are in the install, initialisation or running phases. Also assess if they actually affect what users need to do by testing with a representative selection of end users. Poor performance should also be noted. Warning messages will be output indicating where system calls are not yet implemented or are incompletely implemented.
For each program in the problems list, first check if there is already a GNU/Linux implementation. If so, there should be no problems, but test as far as possible. If there is no existing GNU/Linux implementation it will be necessary to contact the vendor and suggest creating one by the use of Winelib. Again, DLLs may be missing. Each vendor will have to be dealt with separately.
Where vendors refuse to cooperate then alternative applications will have to be found, or the project abandoned.
Once a list of the extra DLLs and library calls required is available it will be possible to get a price for the implementation.
Each program will need retesting with new snapshots of Wine/Winelib until the problems all vanish. Patches sometimes cause problems with programs that were previously running correctly, and this needs to be tested.
Wine is normally compiled with debugging tracing, and this hits performance badly, especially in screen interactions. Any programs that run correctly but have performance problems should be re-run against a copy of Wine compiled without the debug tracing. If performance is still unsatisfactory then development work will be required.