Last updates:
Mon Apr 29 09:38:02 2002
Fri Nov 12 15:35:12 2004
Thu Aug 31 07:25:36 2006
Sat Sep 9 15:22:14 2006
Fri Oct 6 15:48:00 2006
Thu Mar 23 14:15:17 2017
[The companion document, GNU and UNIX utilities on the Microsoft Windows (3.x, 95, 98, and NT) platforms, may also be of interest.]
Well-behaved Microsoft Windows applications should communicate with the operating system only though documented standard Windows API functions stored separately in dynamic load libraries (DLLs), completely avoiding probes into low-level hardware features and device drivers. For such applications, it should then be possible to provide replacement libraries that remap the calls to equivalent functionality in some other platforms.
This approach has been tried for several years, with commercial products like Insignia Solutions' SoftPC, and Sun's SunPC (which can run either on an Intel x86 board installed in a Sun workstation, or on SPARC hardware with software emulation of Intel x86). Unfortunately, a great many Windows programs have been found to deviate from the Windows API, or to use undocumented API functions. This practice has been so widespread that several books have been written about it:
The use of undocumented API functions in Microsoft's own products has been a major component of the long-running U.S. antitrust suit against Microsoft.
Most desktop publishing software is not particularly CPU intensive, and most of the CPU usage is inside the windowing libraries. This means that emulation of the Intel x86 instruction set on another architecture, with the library layer replaced by native code, can still provide reasonable performance. SoftPC, and Sun's no-longer-supported WABI (Windows Application Binary Interface), both take this approach.
Citrix Metaframe provides library replacements that run on the Windows platform, but instead of displaying a window locally, send screen updates to clients on other systems (Windows, MacOS, and UNIX, plus Java clients on any platform), effectively providing the remote windowing capability that the X Window System has given UNIX and (Open)VMS users since 1984.
Microsoft itself has licensed the Citrix work, and offers a product called Windows Terminal Services. This approach lets organizations provide powerful central servers running Windows, with inexpensive (and lower-performance) thin clients on user desktops.
The commercial Win4Lin product provides a library layer that allows running any of several versions of Microsoft Windows on GNU/Linux systems on IA-32, EM64T, or AMD64 hardware. The company has a home page here.
For several years, there has been an effort in the GNU/Linux community to provide a freely available implementation of a Windows library layer that runs on Intel IA-32 (x86) and EM64T, and AMD64, hardware on multiple operating systems (FreeBSD, GNU/Linux, Mac OS X (on Intel), Solaris, and possibly others): WINE (Wine Is Not a (CPU) Emulator) . A companion commercial effort is working to speed WINE development and provide (paid-for) support: CodeWeavers Wine . Because Wine provides only the library layer, it requires a CPU architecture on which Microsoft Windows can run. Thus, it does not run on RISC architectures (Alpha, MIPS, PA-RISC, PowerPC, and SPARC), or on Intel IA-64. To run it on those systems, you need a virtual-machine layer to emulate a CPU architecture: see the virtual machines page, and the Wine FAQ for details and Web links.
There is also a project to implement a complete open-source operating that is compatible with Microsoft Windows XP: ReactOS . It can be run on bare hardware, or in a virtual machine running on top of another operating system.
The commercial Wind/U system provides a Windows library layer on selected Unix platforms.