Section 28.2. Emulation and Virtual Operating Systems
|
The next step up from using Windows files within Linux shells and applications is to make Linux act like Windows so it can run Windows applications . In this section we discuss the two most popular ways to do this: Wine (along with CrossOver Office) and VMware. 28.2.1. WineWine can get you out of a number of high-pressure situations, whether it's your friends bugging you to play the latest Half-Life 2 mod, or finding out after you converted your entire corporation to Linux that the CEO can't function without his favorite Access database. Wine is a free software project that lets you run your favorite Windows programs on Linux. It does this by implementing Microsoft's Win32 application programming interface (only on Intel x86 systems). The acronym Wine expands to "Wine Is Not an Emulator." Rather than emulating a Windows system, Wine translates between the Windows program and the underlying Linux system. You can think of Wine and its libraries as a piece of middleware that sits between your application and Linux (not unlike those other APIs we mentioned). However, no one will get angry if you call it an emulator because it sort of works like one. Wine's roots can be traced back to 1993 and the earliest days of Linux. A group of developers thought it might be interesting to get Windows programs to run on Linux. At the time, Microsoft used the Win16 API in Windows 3.1. A newer operating system, Windows NT, was under intense development and was intended to usher in a wide range of new technologies, including the Win32 API. The Wine developers underestimated the amount of work involved with getting Win16 applications to run, and the subsequent Win32 programs that arrived in the next few years added an entirely new complication. Over time it became clearer how to design the architecture to allow Windows programs to run on Linux. Much of the core design was completed by 2000, but the sheer expanse of the Win32 API meant that several more years would be required just to implement its functionality. The latest versions of Wine support advanced APIs such as DirectX, the Microsoft Installer, and COM. A running joke within the Wine community is that it's been six to twelve months from completion for over a decade. However, things have progressed rapidly in the past few years and it's likely that by the time you read this a stable version of Wine exists. Let's be realistic about what Wine can and can't do for you. A huge number of programs have been written for Windows over the years, and there's a sweet spot where programs tend to work well with Wine. Anything before Windows 95 tends to run into problems. There are a lot of reasons for this, but the main reason is that the Win16 and DOS parts of Wine don't get used much, so bugs remain. Similarly, the applications written for the latest and greatest version of Windows sometimes use features not yet implemented in Wine. Everything in between, which generally means applications written for Windows 98, 2000, and XP, has a decent shot at running. Common applications that people use Wine with include the following:
You may find some aspects of your application that won't work with Wine, in which case you'll need to evaluate whether they're necessary or whether perhaps a commercially supported version of Wine (described in a later section) can fix it. Purists may argue that Wine simply degrades Linux and free software. Practically speaking, however, it's undeniable that more software exists for Windows operating systems than for any other. It's also undeniable that a huge amount of Windows software has turned into abandonware over the years as companies have gone out of business. Wine can expand the library of software you have access to and help you solve integration problems. Wine developers would be the first to point out you should always try to use a native Linux solution. If you can't, then maybe Wine can help you. If you're a software developer, you may be interested in Winelib, which is the Wine version of the Win32 interfaces, exported for applications to link against. Thanks to Winelib, you can take the source code of a Windows program and recompile it on Linux with Wine. There are several advantages to this, such as being able to run a program on versions of Linux other than x86. Creating a Winelib app also means your program will have access to any native Linux library. For example, if you'd like to integrate an application with a native Linux sound system, you could rewrite parts of the application to work with ALSA. Winelib apps still require Wine to facilitate the management of system activities such as Windows threading. Winelib can be found at http://www.winehq.org/site/winelib. Wine can help you solve a wide range of integration problems, though some work may be required on your part to make it function smoothly. Don't give up on Wine if your favorite application doesn't start up the first time you try it. Study the resources we point you to here, to get a feel for what you may need to do. Spend some time with the configuration tools to alter the default settings. If that doesn't work, you may want to download the trial version of CrossOver Office to evaluate whether it will work for you. 28.2.1.1. Getting and installing WineLike most free software, the decision you'll need to make concerning Wine is whether to compile from source code or download a binary version. Both offer advantages, but you should weigh the decision carefully. It's recommended you download a binary version if you can. The source code does utilize standard build tools, so if you're comfortable doing a standard configure/make build, you may find it to be a reasonable option. Regardless of which option you choose, you'll want to make sure certain pieces of software have been loaded and configured on your system. Both the Wine source code and binary packages can be found on the WineHQ web site at http://www.winehq.org/download. For some distributions, such as Debian or Ubuntu, you can find additional information for installing packages. All of the individual package selections will redirect you to a download mirror. Wine development moves rapidly, and if your system came preinstalled with it, you should strongly consider upgrading to the latest version on WineHQ. The Wine project maintains binary packages for the most common Linux distributions, including Red Hat, Mandriva, Fedora, SUSE, Debian, and Slackware. Chances are you can find a package to work with your distribution. Each package has been built specifically for its associated Linux distribution and may even offer some integration you wouldn't ordinarily find from the source distribution. In addition, each binary package has been compiled to work specifically with the set of libraries that come with your distribution. If you're not sure you have all the software installed on your system to compile Wine, download the binary version. Use your Linux distribution's package tool, such as rpm or apt, to install Wine. If you choose to download Wine's source code, you'll need a standard build environment. Wine utilizes libraries that are standard on almost every Linux distribution, but you'll need to make sure you have the headers available for things such as X. Building consists of running just a few common commands from within the source code directory: $ ./configure $ make depend $ make Be sure to monitor the output from configure to make sure everything was found. To actually install the packages, you'll need root access. As root, run make install from within the source directory. The default installation directories are in /usr/local, such as /usr/local/bin and /usr/local/lib/wine. If you would like to access the latest development source code of Wine, you can download it from the CVS server. Wine's CVS tree remains relatively stable from day to day, and it's uncommon to run into a build problem. But, as with any software under development, you'll need to carefully evaluate whether it's worth being on the bleeding edge. To access the CVS server, you'll need to let CVS know where the repository is, log in, and then check out the actual source code: $ export CVSROOT=:pserver:cvs@cvs.winehq.org:/home/wine $ cvs login $ cvs -z 0 checkout wine For future updates, enter the newly created wine directory and simply run cvs update -PAd. 28.2.1.2. A simple example of using WineTo get started with an application that uses Wine, let's walk through running a simple example. Afterward, we can examine the settings that get automatically configured by Wine. The defaults are sufficient for running simple programs, but you'll want to tweak them later for many applications. To dive right in, run the Wine task manager application taskmgr . If your installation worked, you can enter: $ wine taskmgr Wine's task manager allows you to start, stop, and debug Wine processes. After running taskmgr, you'll notice that a couple of things have been automatically set up in your account. Wine stores its settings in a special directory named ~/.wine and in subdirectories below that. Within ~/.wine you'll find that a system registry has been created and stored within three files named system.reg, user.reg, and userdef.reg. In addition, two important directories have been created: dosdevices and drive_c. The former contains all of the mappings necessary to configure your virtual Windows drives. The latter contains an entire virtual Windows drive with all of the directories you'd expect to find on Windows, such as c:\windows and c:\Program Files. We discuss each of these in more detail as we go on.
28.2.1.3. Configuring WineWine configuration generally involves a couple of graphical tools, but you can also use a regular text editor if you prefer. At the core of Wine's configuration lies the Wine registry. Because Windows applications require a registry to store settings, Wine was forced to implement a completely compatible system. For many years Wine also maintained a separate configuration file (the venerable config file.) Having two different configuration mechanisms made no sense, so Wine abandoned its custom mechanism to move its settings directly into the registry. Now you can configure both applications and Wine with one set of tools. Wine comes with two different tools for configuration: winecfg and regedit. The first lets you easily control common settings. The second will let you control more obscure settings as well as the settings for your applications. Both tools access the registry files stored in ~/.wine. Unlike Windows, these registry files are stored in a plain-text format. You can always fire up your favorite text editor and change the keys manually. Run winecfg from the command line to start the program. The first thing you'll notice along the top are a series of tabs to configure applications, libraries, graphics, appearance, drives, and audio. The Applications, Libraries, and Graphics tabs are linked together to allow you to control settings for an individual program. For instance, on the Applications tab you'll notice you can change the Windows version that Wine reports to the program. The default attempts to emulate Windows 2000. You may find that a program responds differently if the Windows version is, say, Windows 98 versus Windows XP. If you happen to know the program explicitly requires Windows 2000, you can use the Add application button to locate your program's executable. Then you can change the Windows Version setting just for that program while leaving the Default Settings as they are. Likewise, all of the settings within the Libraries and Graphics tabs affect the application (or Default Settings) selected within the Applications tab. The Libraries tab allows you to change the behavior of individual libraries. Wine can optionally use native Windows libraries if you have them available. For instance, if you have a Windows partition on your computer, you can copy the DLLs from C:\WINDOWS\SYSTEM to the corresponding directory within your virtual Windows drive. To utilize one of those libraries, type the name of the library in the text box under "New override for library." For instance, if you copied FOO.DLL from Windows, enter foo in the text box and click on the Add button. By default, Wine tries to load the native Windows version followed by the built-in Wine version. You can change that load order to native only, built-in only, or either search combination using the Edit button. Using native Windows libraries can often work around deficiencies within Wine. But keep in mind that you can never replace the core Wine DLLs kernel32, ntdll, user32, or gdi32. Games are the most common reason for changing settings within the Graphics tab. You may find that changing the color depth will enable a game to run better. If you have the XRandR extension available within your X server (and most systems do these days), Wine will attempt to resize your screen if requested by an application. That behavior may not be desirable, though. Therefore, Wine can "Emulate a virtual desktop" of a size of your choosing. The virtual desktop will run an application within an enclosed X window. The Appearance tab does not affect the running of applications, but just allows you to customize Wine's look. It loads Windows XP themes based on .msstyles files. Windows programs are sandboxed within a contained filesystem environment. The settings within the Drives tab allow you to adjust how much of the underlying Linux filesystem can be seen by an application. This can prevent misbehaving Windows programs from affecting anything else on your system. Wine can modify only files that the Linux user running it can modify. By default, Wine sets up a special virtual Windows drive in ~/.wine/drive_c and installs Windows applications there. If you look at the drive mappings for your virtual C: drive, you'll see that they point to that location. If you would like to add another drive, click on the Add button and locate the Linux directory you'd like to access. For instance, if you have some removable media, you can add that mount point as a drive. The final tab that controls audio settings is pretty self-explanatory. If you use the Autodetect button, it attempts to automatically figure out which one of Wine's audio drivers should be used. You can also set this manually using the drop-down box. If you have difficulty getting sound output, be sure to check the mixer settings within your distribution to make sure the volume on your audio device is turned up. Problems with audio are handled in Chapter 9. In general, winecfg operates like Windows' control panels. It simply serves as a graphical interface to the underlying registry settings. And just as on Windows, you can configure these settings directly using the regedit tool. Just run regedit from the command line to open it. You'll find most of the settings we've discussed stored within the HKEY_CURRENT_USER\Software\Wine branch of the registry. For example, if you drill down through the hierachy using regedit, you'll see that the Windows version is stored directly in the key HKEY_CURRENT_USER\Software\Wine with a value of Version containing the data of the version, such as win98. regedit can also be useful for examining application settings. Usually these keys follow a naming convention like HKEY_LOCAL_MACHINE\Software\vendor\application. The only configuration settings not stored in the registry are drives and ports. The changes made using the Drives tab are stored directly in the filesystem using a series of symbolic links. If you look in the ~/.wine/dosdevices directory, you'll see that each link points to the location within the filesystem to be accessed by the virtual drive. The default configuration will look something like this: lrwxrwxrwx 1 wineuser wineuser 10 May 6 21:37 c: -> ../drive_c lrwxrwxrwx 1 wineuser wineuser 1 May 6 21:37 z: -> / Therefore, the virtual Windows drive c: points to ~/.wine/drive_c. The z: points to the root of your filesystem. Accessing ports is done in a similar manner, and you may find you need to add a symbolic link for com1 to something like /dev/ttyS0 in order to access the serial port. Of course, Wine will be able to access only the parts of your root filesystem that the user has access to. 28.2.1.4. Running WineTo actually run applications, just invoke wine. First, locate the actual file you need to run. Most likely this means locating an installation program first. Generally the name will be something like SETUP.EXE or INSTALL.EXE. To run it, enter: $ wine SETUP.EXE The installation program should then execute and copy all of the files the program requires into your virtual Windows drive. It will also make any necessary registry changes. On Windows, this may mean setting up some special RunOnce registry keys that get executed when Windows reboots. The RunOnce keys will execute just that one time, but they typically perform actions necessary to set up a program for use. To simulate a reboot and execute these keys, run the wineboot command. Running that command really can't hurt anything, so you should always plan on running it after installing a program. Once the program is installed, you need to locate the executable and run it. There's a chance Wine was able to modify your desktop's configuration and create an entry for this new program, so you may see an icon right on your desktop for the new program. You may also see menu entries in GNOME's Panel or KDE's Kicker toolbar. Wine will attempt to set up a special Wine menu containing all of the installed applications. If that doesn't work, or if you prefer to run your application from the command line, navigate into the directory where you installed the application. Typically this will be something like ~/.wine/drive_c/Program\ Files/application. Many Windows applications like to be executed from the working directory where the application is installed. From that directory simply enter: $ wine program.EXE At this point, you may find you need to tweak the configuration options using winecfg to adjust the Windows version or DLL overrides for the program. If you compiled Wine from source, you'll see FIXME messages printed out informing you of unimplemented Windows functions. Often the FIXME messages can lead you to the library experiencing the problem. Replacing that library with a native one may solve your problem. Installing third-party software may help as well. Internet Explorer and the libraries it comes with can often solve Internet-related issues.
If you have a text-based application, you can run that with Wine as well. You may want to change the graphics driver to be winetty.drv rather than winex11.drv so it can run without requiring X Windows. However, some text-based programs misbehave and attempt to use graphical features for backend processing, so you may not be able to run it without X Windows support. To execute a text-based program, run it with the wineconsole command: $ wineconsole program.EXE Other programs you can run through wine include Wine versions of Notepad, REGEDIT, and many other common programs provided by Windows. The Wine versions of these programs access Winelib, and all of the graphical elements you see on the screen have been drawn by Wine. 28.2.1.5. Further helpIf you run into problems, check out Wine's web site at http://www.winehq.org for more information. It has extensive user documentation. The FAQ might contain the answer to your question. If not, the Wine User Guide contains more in-depth coverage of the topics discussed here as well as other tips and tricks. Finally, several helpful documents have been put together to debunk popular myths, explain in more detail how Wine works, and highlight specific features. Wine also hosts several resources to help resolve problems. If you look in the Application Database, http://appdb.winehq.org, you may find that someone has already solved the same problem you're chasing. If you would like to report a bug, check out Wine's Bugzilla database at http://bugs.winehq.org. You may find the mailing lists hosted on WineHQ helpful to solve problems, as well. Lastly, a wiki has been set up to collect information from the community. If you would like to contribute, or you would like explore more documentation, you can find it at http://wiki.winehq.org. 28.2.1.6. CrossOver OfficeIf you're struggling with Wine, you may find that a commercial version works better. CodeWeavers' CrossOver Office, available from http://www.codeweavers.com, supports a small set of Windows applications. You can download a 30-day trial version for free to get a feel for whether it will work for you. CodeWeavers actively tests Windows programs with its product, and its supported applications work really well. The current list includes over 30 different popular applications, including Microsoft Word, Excel, PowerPoint, Visio, Access, Quicken, iTunes, FrameMaker, and Lotus Notes. You can also use CrossOver Office to run popular web browser plug-ins, such as QuickTime, Shockwave Director, and Windows Media Player, and have them interoperate with a native Mozilla web browser. CrossOver Office provides a stable and tested version of Wine you can rely on. CodeWeavers also provides consulting services to help you run Windows programs on Linux. If you're looking for a company to provide the warm, fuzzy feeling of commercially supported Wine, CodeWeavers fits the bill. CrossOver Office can be ordered and downloaded directly from CodeWeavers' web site. You have the option of downloading an RPM installer for Red Hat, SUSE, and other RPM-based distributions, a custom Debian installer, or a Loki-based installer. The Loki-based installer is the preferred method because it can be run entirely in user space. After downloading the Loki-based installer, be sure to set the execute bit (chmod +x) on the installer script. Then you just need to run the following script: $ ./install-crossover-standard-5.0.sh The script will first unpack CrossOver Office and walk you through the installation. At the end it gives you the option to install Windows software. This launches the cxoffice/bin/cxsetup configuration tool and gives you a list of supported software you can install. This wizard-like tool will walk you through the process of installing the software and perform any additional steps necessary, such as restarting Wine to simulate a Windows reboot. You can also choose to install unsupported software. CrossOver Office runs many other applications besides the officially supported ones, and you may find your favorite Windows application works better with CrossOver Office than regular old Wine. Regardless of whether you choose to install supported or unsupported software, you'll be prompted next for the location of the installation file. You can choose from either your vendor CD-ROM or a setup program on your hard drive. Some of the supported software will install automatically, but other software may require the installation program to run. When installation is complete, a simulated reboot of Wine is performed and menu entries are made for your desktop. Your desktop panelKDE's Kicker or GNOME's Panel--will contain a new entry called Windows Applications that leads to the programs installed by CrossOver Office. To configure CrossOver Office, navigate to the CrossOver menu in your desktop's panel and choose Configuration. You'll then be presented with the tab-based cxsetup dialog giving you options to Add/Remove programs or Manage Bottles. The first option allows you to manage applications, including the use of the Install button to launch the installation wizard described earlier. The second option, Manage Bottles, allows you to customize aspects of CrossOver Office. Bottles are self-contained directories for sets of installed applications, each holding a complete Wine configuration. After selecting a bottle from the list available, you click on the Configure button to edit things such as menus, set file associations, configure plug-ins, add fonts, open control panel apps, and change bottle settings. Each tab contains a Help button in case you get stuck. 28.2.2. VMware WorkstationVMware (now owned by EMC) distributes proprietary products that permit the running of virtual operating systems on servers and workstations.[*] The workstation product has achieved a certain popularity by aiding people who want to run different operating systems on their computer desktop; among other things, they can run licensed versions of many different Windows operating systems on Linux. VMware Workstation also sees much use in development and testing. Many claim that it accelerates application deployment.
28.2.2.1. So what does it actually do?VMware Workstation 5 allows multiple operating systems and applications to run at the same time on a single physical computer. If you have enough RAM, a decent hard drive, and a modern CPU, VMware performs well. Figure 28-1 provides a look at VMware Workstation running on Novell Linux Desktop 9 with Windows XP Home Edition installed. This should give you an idea of what you can expect to see if you use this product. Notice on the top of the toolbar that an icon lets you select a full-screen mode. This option makes the screen look just like the guest operating system is running natively. According to VMware, Workstation Version 5 runs on the following:
Figure 28-1. VMware Workstation 5 on Novell Linux Desktop 9 Users of Fedora Core 3, Gentoo, Red Hat, and Debian have reported that VMware 5 also runs on their systems without difficulty, although the company does not claim to support them. As shown in Figure 28-1, the author found VMware completely functional on NLD 9. Each guest operating system runs in an isolated virtualized machine. VMware maps a host's computer hardware resources to the virtual machine's resources, so each virtual machine has its own CPU, memory, disks, and I/O devices, so to speak. At least it looks that way to the guest operating system. The virtual machine appears to the guest operating systems as a standard x86 computer. Once VMware Workstation installs on its host, you can install and run unmodified versions of Windows, Linux, Novell NetWare, and Sun Solaris x86, as well as applications written for those platforms, on one machine. The promise of VMware is for users to derive the benefit of using multiple PCs without the expense, physical setup, and maintenance of various hardware platforms. VMware Workstation makes it easy for Linux users to run Windows applications. VMware Workstation as a product may turn out to have a limited lifetime. It could be seen as a way to allow Linux users to run their favorite Windows applications while they move toward replacing them with versions that run natively in GNOME, KDE, and other desktop environments. It's worth remembering that the workstation product is just one product among VMware's offerings, and that the future for VMware, the company, probably lies in the server area, where it has given Linux a leg up in the data center. Still, VMware has an important place in the history and evolution of Linux. Many people still love it and are glad it's around. Hopefully, the company will continue to innovate and make using Windows applications simpler for Linux users while it grows its server business. 28.2.2.2. Installing VMware Workstation 5We had some difficulty installing VMware on SUSE Professional 9.2, even though the company listed it as a supported platform. The installation seems simple. One downloads VMware as either a gunzipped tarball or as an RPM. Once the package installs, simply run vmware-config.pl. But SUSE 9.2 kept giving this error message: None of the pre-built vmmon modules for VMware Workstation is suitable for your running kernel. Do you want this program to try to build the vmmon module for your system (you need to have a C compiler installed on your system)? CC [M] /tmp/vmware-config1/vmmon-only/linux/driver.o /bin/sh: scripts/basic/fixdep: No such file or directory make[2]: *** [/tmp/vmware-config1/vmmon-only/linux/driver.o] Error 1 make[1]: *** [_module_/tmp/vmware-config1/vmmon-only] Error 2 make[1]: Leaving directory `/usr/src/linux-2.6.11.4-21.7' make: *** [vmmon.ko] Error 2 make: Leaving directory `/tmp/vmware-config1/vmmon-only' Unable to build the vmmon module. When we decided to switch and try Novell Linux Desktop, installing it without any updates, VMware installed as well. Afterward, we updated NDL 9 and tested VMware Workstation 5; it continued to work. We later discovered that SUSE's 9.x kernels have patches that do not come with a stock Linux kernel. Many packages relying on prebuilt modules fail. You can recompile the modules as a workaround. To recompile the modules, use: # cd /usr/src/linux # make cloneconfig # make prepare # vmware-config.pl vmware-config.pl will then find all the necessary files as if a fresh kernel had been compiled. You also may find some confusion on the VMware site regarding which Linux distributions can operate as "guest" systems and which operate as hosts. Think of this like inviting a guest to your home. You escort them into the living room, where you sit and talk. In VMware terms, when you install VMware, you create a living room for a guest operating system. In this case, you are running Linux as the host system and install Microsoft Windows as a guest. If you are interested in installing other Linux distributions as guests, make sure you check with the VMware web site for supported guests (as opposed to hosts). Officially supported guest operating systems include the following:
The virtual hardware of VMware 5 runs better than previous versions. With a single Pentium IV or an equivalent AMD processor and 512 MB of RAM, one should be able to run two virtual machines simultaneously. The previous versions would grind to a halt in such a scenario. 28.2.2.3. VMWare Workstation 5 featuresOnce you get used to the novelty of seeing another familiar operating system running on your Linux system, you can start to consider the advanced capabilities of VMWare Workstation 5 that turn it into an excellent platform for system testing and group development work. Operating system snapshots . Version 5 of VMware provides for multiple snapshots so that a user can preserve the state of a guest and revert to an older state after powering down and starting up again. You can configure a virtual machine to take a snapshot and preserve an audit trail. If you need to examine a virus, for example, you can take a snapshot before you introduce the malware. If the virus does damage, you can restore the virtual machine to the state preserved in that snapshot. The same capability can prove valuable when you're testing new code or a patch. Previous versions of VMware allowed for the taking of snapshots. However, each snapshot would overwrite the previous one. So, for testing purposes, Version 5 provides a significant upgrade. Virtual networks. Workstation teams allow users to set up a virtual network or lab on a host computer. You can power up multiple virtual machines, as mentioned earlier. You then can configure networking the way you would on any local area network, however, this network would run on a single computer. Users can work together in what VMware calls a LAN segment. They are invisible to the host computer's network, which creates a virtual safe house for development. Cloning. VMware Workstation 5 provides interesting deployment capabilities with what the company calls clones. In VMware workstation terms, two types of clones exist. One is called a full clone, which we might consider to be similar to a ghosted image used to provision another computer. The second type of clone is called a linked clone. It remains dependent on the original image. VMware's full clone functions as an independent copy of a virtual machine. Once a user makes the clone, it runs separate from the parent. It then can go off and become a unique instance that you can use to make changes or deploy for whatever purpose you see fit. VMware's linked clone shares virtual disks with the original or parent, conserving disk space. This permits multiple virtual machines to use the same software installation. Also, linked clones take less time to create than a full clone. Labs might want to create linked clones to provide identical environments to developers, quality assurance engineers, testers, or maintenance programmers. If you store a linked virtual machine on your local network, other users can make a linked clone quickly. A support team can reproduce a bug in a virtual machine, and an engineer quickly can make a linked clone of that virtual machine to work on the bug. The files on the parent of a linked clone continue to exist at the time one creates a snapshot, and continue to remain available to the linked clone. Changes to the parent don't affect the linked clone, and changes to the disk of the linked clone don't affect the parent. 28.2.3. Other Programs for Running MS-DOS and Windows Applications on LinuxA number of other attempts have been made by different groups of developers, both open source and commercial, to bring DOS and Windows programs to Linux. The simplest is Dosemu (http://www.dosemu.org), which emulates PC hardware well enough for MS-DOS (or compatible systems such as PC-DOS or DR-DOS) to run. It is still necessary to install DOS in the emulator, but since DOS is actually running inside the emulator, good application compatibility is assured. To a limited extent, it is even possible to run Windows 3.1. Another open source project is Bochs (http://bochs.sf.net), which emulates PC hardware well enough for it to run Windows and other operating systems. However, because every 386 instruction is emulated in software, performance is reduced to a small percentage of what it would be if the operating system were running directly on the same hardware. The plex86 project (http://savannah.nongnu.org/projects/plex86) takes yet another approach, and implements a virtualized environment in which Windows or other operating systems (and their applications) can run. Software running in the virtual machine runs at full speed, except for when it attempts to access the hardware. It is very much like Dosemu, except the implementation is much more robust, and not limited to running just DOS. At the time this book was written, all of the projects discussed so far in this section were fairly immature, and significantly limited. To put it bluntly, the sayings, "Your mileage may vary" and "You get what you pay for" go a long way here. You may have better luck with a commercial product, such as VMware (http://www.vmware.com) or Win4Lin (http://www.win4lin.com). Both of these work by implementing a virtual machine environment (in the same manner as plex86), so you will need to install a copy of Windows before you can run Windows applications. The good news is that with VMware, at least, the degree of compatibility is very high. VMware supports versions of DOS/Windows ranging from MS-DOS to .NET, including every version in between. You can even install some of the more popular Linux distributions, to run more than one copy of Linux on the same computer. To varying extents, other operating systems, including FreeBSD, NetWare, and Solaris, can also be run. Although there is some overhead involved, modern multi-gigahertz CPUs are able to yield acceptable performance levels for most common applications, such as office automation software. Win4Lin is a more recent release than VMware. At the time of this writing, it ran Windows and applications faster than VMware, but was able to support only Windows 95/98/ME, and not Windows NT/2000/XP. As with other projects described in this section, we suggest keeping up-to-date with the product's development, and check once in a while to see if it is mature enough to meet your needs.  |
