Making Windows Run Linux Applications

The Windows desktop application world and the Linux desktop application world don't collide all that often. For instance, you hardly hear, "Hey! I got this killer Linux desktop application. Too bad you can't run it in Windowshar har!" Arguably, it's because Microsoft's desktop percentage is something like 97 percent to Linux's 3 percent (from data found at Linuxplanet www.linuxplanet.com/linuxplanet/ reports /5381/1/ ).

That doesn't mean you won't need to run Linux applications on Windows occasionally; it's just that the need doesn't often arise. However, it's likely you'll find yourself needing to more and more.

In this section, we'll describe several ways that Windows users can leverage existing Linux applications.

OpenCD 2

Linux power-users have quasi-standardized a collection of tried and true applications to get their jobs done. These applications have a good reputation for working as advertised, are relatively bug free, and are 100 percent cost-free. So far, the deal is pretty sweet! However, until recently it was difficult for Windows users to access that same battery of software.

There's a very interesting project called the OpenCD project (at www.theopencd.org/ ). Here's the idea: round up the best-of-breed Open Source software and make it run natively in Windows. Yes, they're ready-to-run Windows applications, already in heavy use in the Linux world, and they're 100 percent cost-free.

The added bonus is that if you run the same application on your Linux desktop, you'll have nearly zero interoperability concerns. The applications on the OpenCD that run in Windows will, of course, output exactly the same data files that would be readable by their Linux counterparts.

OpenCD 2 contains a bunch of very useful software. We'll be exploring one of the applications it contains, OpenOffice, later in the chapter. You'll also find GIMP (a hugely popular graphics editor) and Audacity (a hugely popular audio editor), among others. To see a list of all the applications OpenCD 2 contains, just go to the website, and click "The Programs" in the menu on the left.

Unix Tools within Windows

Even Windows users like the power tools that are inherent to the Linux operating system. The Linux command-line tools simply cannot be beat. To that end, there are two sets of tools you might want to check out to help you add a little Linux flair to your daily Windows life: SFU 3.5 and Cygwin.

SFU 3.5 Tools and Shells

Microsoft's Services For Unix (SFU) includes a suite of command-line tools, ported to Windows. You already loaded SFU 3.5 on your windc1.ad.corp.com , the Windows domain controller, but you can also load SFU 3.5 on your Windows XP machine. If you followed along in Chapter 4, you did that to get an NFS client on our Windows XP machine. When you did this, you also loaded the SFU 3.5 command-line tools, including some Unix-style shells and a Perl interpreter.

All about the X Window System

Before loading SFU 3.5 on additional machines just for the tools, be sure to read the next section on Cygwin, an open source collection of free tools that also has a lot to offer , including an "X server" program.

But what is an X server? Well, the X Window System (often referred to simply as "X") provides graphics capabilities to Linux and Unix applications. Without it, you're stuck in Plain Text Land.

For historical reasons, X is very much a client/server system. The system displaying the user interface runs a piece of software called an X server , which responds to X protocol requests from the actual applications, which are known as X clients . An X application program can be run on one system and the user interface can be displayed on a completely separate system. Of course, they can also run on the same system.

The client/server terminology is used because GUI applications connect to the X server and make requests to display things and receive user input; this is certainly a client/server model, but it does lead to confusion because people aren't used to running things called "servers" on client workstations. The following graphic is helpful to understanding this.

These days, the application and the user interface are nearly always on the same workstation. When they aren't, it's not uncommon to use a lightweight solution like VNC (Virtual Network Computing, discussed in Chapter 8) to achieve remote display, instead of the older X protocol. However, the terminology and the underlying architecture are still with us.

Because SFU 3.5 doesn't include an X server program, it means that Unix applications that feature a GUI can't be immediately ported to Windows using SFU without a separate X server program. A free version is available from Startnet:

www.starnet.com/xwin32LX/get_xwin32LX.htm

Hummingbird's eXceed product also does the job:

www.hummingbird.com/products/nc/exceed/

It is even possible to use the X server that comes with Cygwin, an alternative to SFU that we'll discuss later, to provide a display for Unix GUI applications running on SFU. At that point, however,you may as well just run your Unix application on Cygwin instead of SFU and be done with it.

SFU may meet your needs if your primary concern is command-line Unix compatibility, but it is not the most complete collection of free Unix tools available for Windows.

SFU 3.5 Commands for Windows

SFU has a variety of popular Linux commands. Here's a quick table:

Function	DOS/Windows Command	Unix/Linux Command
Take a directory listing	dir	ls
Copy files	copy	cp
Display a file	type	cat
Delete a directory	rmdir	rmdir, or rm -r
Set attributes	attrib	chmod
Change ownership	subinacl as extra-download	chown
Unpack a TAR file	None	tar
Print domain name	None	pdomain
Display processes	None	ps -al
Search for text	find	grep
Search for files by name, date, etc.	dir /b /s	find

The University of Minnesota Supercomputing Institute offers an excellent table of Unix and Windows command-line equivalents, as well as GUI ways to do the same tasks . You can find the table at www.msi.umn.edu/llsda/ntunix.html .

SFU 3.5's Shells for Windows

SFU also ships with two popular Unix-style shells that run under Windows. Specifically , the ksh (Korn shell) and csh (C shell). The idea is that if you already have Linux or Unix shell scripts that are working properly, you can just copy them over, and they'll work, assuming that all of the Unix utilities they rely on are included in SFU, of course.

If you have some experience with Unix shell scripts, you may question whether scripts written for the standard Unix sh shell, on which the POSIX standard for shell behavior is based, will really run on ksh . The answer is yes. Like the Bash shell more commonly found on Linux systems, ksh includes all of the features of sh and aims to be highly backward compatible.

To experiment with ksh , select Start All Programs Windows Services for Unix Korn Shell.

A command shell window will open, and the Unix-style $ prompt will appear.

Once inside, you'll have a wide range of Unix command-line programs to play with. For instance, you can run sh shell scripts and Perl scripts just as you would in Linux, often without any modification. However, if your script doesn't run perfectly , Microsoft does have some recommendations for porting sh shell scripts at www.microsoft.com/technet/interopmigration/unix/sfu/pshscrpt.mspx .

Note

Alternatively, you can use the csh shell, also accessed from the "Windows Services for Unix" submenu of the Start menu. We don't recommend csh for beginners because it is not an implementation of the POSIX shell standard, but csh it is useful for old-school Unix users who already have csh commands memorized "in their fingertips."

What if you want Linux compatibility for more than just scripts? What if you want to port full-scale applications? SFU can also be used for this purpose.

Interop Toolworks

InteropSystems offers a collection of additional open source software packages ready to use with SFU. The package is commercial, currently offered for $40. You could in principle compile these yourself with the compiler tools provided with SFU, but sometimes it makes sense to pay for convenience.

It should be noted, though, that many of these utilities and most of the other software in the Interop Toolworks toolkit come in the Cygwin suite described in the next section.

You can locate the Interop Toolworks toolkit at www.interopsystems.com/InteropToolworks.htm .

Cygwin Linux-Compatible Environment

A complete set of ported Linux tools is available from Cygwin, a subsidiary of Red Hat. (For the record, most people pronounce Cygwin "sig-win.")

The Cygwin project describes itself as "a Linux-like environment for Windows." Indeed, installing Cygwin is rather like installing a Linux distributionbut a little different. There are no hard drives to partition of course, but a similar GUI is used to pick and choose packages from various categories, as shown in Figure 7.1.

Figure 7.1: Selecting packages to install with the Cygwin setup program

The Cygwin installer makes it easy to download packages over the Internet. A full installation of Cygwin includes the gcc compiler, which you'll find essential if you decide to try recompiling Linux applications for the Cygwin environment from the source code.

Cygwin relies on the Bash shell. The Bash shell is no more or less "standard" than the ksh shell in SFU, but Bash on Cygwin does have exactly the same keyboard shortcuts and other user- friendly touches that Linux Bash users expect to find.

Cygwin includes the X Window System, which lies beneath the GUI of most user-friendly Linux applications. Even better, Cygwin also includes the GNOME environment on which the Fedora desktop we've used in this book is based. In general, Cygwin is the most Linux-like environment you can have on Windows without actually running Linux.

You can install Cygwin by following the current instructions on the Cygwin home page, at www.cygwin.com/ .

Cygwin's Shells for Windows

Cygwin uses the Bash shell by default, which is normally the default choice on Linux. Cygwin also offers many additional shells, including tcsh , a more user-friendly version of csh . You might understandably raise an eyebrow at the idea of a "user-friendly" Unix shell. tcsh and Bash are considered more friendly because they support the use of arrow keys to recall recently used commands, command completion with the Tab key, and similar features missing from the csh and sh legacy shells with which they are backward compatible.

Once you have installed Cygwin, you can launch a Bash shell by selecting Start All Programs Cygwin Cygwin Bash Shell. The Unix-style $ prompt will appear.

As in the SFU ksh shell, you can run existing Unix shell scripts and Perl scripts very well in the Cygwin environment. In addition, because the package includes an X Window System server and support for GNOME applications, it's simpler to port Linux applications that feature a graphical user interface.

Porting Applications with Cygwin

What if you want Linux compatibility for more than just scripts? What if you want to port fullscale applications? Cygwin can also be used for this purpose. Intriguingly, with Cygwin, it is possible to mix Windows code and Linux code in the same program.

Wholesale Linux (and PC) Emulation on Windows

If you can't find the Linux application you want to run for Windows, why not simply make Windows run Linux? That's the approach several pieces of software take.

The first category will pretend to create an entire working PC inside your PC. Yes, you heard that right. The idea is that if you can emulate an entire PC inside your own PC, you can run any operating system you wantsay, Fedora Core 3and simply install the applications you want inside this virtual machine!

To that end, I (Jeremy) have written several articles on PC virtualization technology that we encourage to check out:

" A Virtual Machine Primer " This article describes what PC virtualization is all about and how it got started:
- http://mcpmag.com/features/article.asp?editorialsid=429
" A Virtual Shootout " This article describes specifics about the two leading products in this space: Virtual PC and VMware. We'll make some additional notes about each in the next two section.
- http://mcpmag.com/features/article.asp?EditorialsID=428

By reading these articles before continuing, you'll get a handle on terminology and why you'd care to possibly take this approach.

Microsoft's Virtual PC and Virtual Server

Virtual PC and VirtualServer are two products from Microsoft. For what they do, they're very reasonably priced.

On Virtual PC, Microsoft doesn't specifically support Linux inside the virtual machines. We've done it, though. It works , it's just not supported. In other words, Microsoft only wants you to run Windows within Windows. That doesn't really help you here. Therefore, we cannot in good conscience recommend Virtual PC for running Linux virtual machines (guests) within your real Windows machine (the host).

Note that Microsoft also produces Virtual Server, which is the bigger, badder server version of the tool and is similar to Virtual PC. The good news is that certain Linux distributions are supported within Virtual Server (once Virtual Server's SP1 is applied). However, for the casual user running Windows XP on their desktop, Virtual Server running Linux isn't the answer, as it only runs under Windows 2003 and won't run under Windows XP. However, in a test lab environment where you have access to Virtual Server, it would make a fine choice for testing Linux while running Windows.

You can download a 45-day trial version of Virtual PC at www.microsoft.com/windows/virtualpc/default.mspx .

You can download a 180-day trial version of Virtual Server at www.microsoft.com/windowsserversystem/virtualserver/evaluation/trial/default.mspx . Be sure to load Virtual Server's SP1 if it's not specifically included in the download.

VMware

VMware Workstation 5 is VMware's latest PC virtualization product. It has full support for running Linux within Windows. VMware also has executables that run on Linux! (So we'll mention VMware again in a little while when we talk about how to get Windows applications to run under Linux.) You can see a screenshot of VMware in Figure 7.2. Here we're running Windows XP as our "real" operating system (again, called the "host") and Fedora Core 3 as a virtual machine (sometimes called the "guest").

Figure 7.2: VMware Workstation for Windows running Fedora as a guest

One of the most important aspects of using VMware effectively and efficiently is that after the virtual machine is installed, you must load the VMware tools inside the virtual machine. These tools are not strictly required, but they provide increased speed, stability, time synchronization with the host computer, and (with Windows) the ability to drag-and-drop files from the host's desktop to a guest's desktop.

Loading the VMware tools when your guest machine is Windows is a no-brainer and works perfectly every time. However, in our example here, our guest is a Fedora Core 3. While Red Hat products are fully supported with VMware, Fedora Core 3 is only quasisupported.

Because of this, the prescribed instructions to load the VMware tools don't quite work perfectly with Fedora Core 3 machines as guests. However, we have found that with Fedora Core 3 only one small additional step is required to make things work properly. Other distributions may require more elaborate workarounds; see the sidebar "Installing Other Linux Distributions On VMware" for more information.

When Fedora Core 3 is a VMware guest, you'll encounter the following issues:

Installing Fedora Core 3 from downloaded CD-ROM ISO images is a bit of a pain. There is a lot of switching between the various ISOs during installation time. You'll solve this by downloading a DVD-ROM image of Fedora instead. This works just as well in VMware's virtual CD-ROM drive, and only one ISO file is needed during installation.
When creating a guest machine, VMware doesn't have a category to specifically create a "Fedora Core 3" guest in the same way it has options for other specific operating systems, Selecting Red Hat Linux works fine, as long as we address the other issues on this list.
As mentioned, installing the VMware tools is the most important thing we can do to maintain a fast and stable Fedora Core 3 guest. The VMware tools aren't specifically compatible with Fedora Core 3. That is, the tools don't come with a precompiled kernel module for the Linux kernel version included with Fedora Core 3. Fortunately, the VMware tools installer is smart enough to compile a new module to work with our kernel. But this option is only available if we specifically install the "Development Tools" (under the "Development" heading) when we install Fedora. These include the necessary "C" language compiler and other software needed to compile a kernel module.
There are several issues to overcome when trying to run VMware tools using versions older than VMware Workstation 5. If you want to get the tools running in, say, VMware GSX 3.2 or Workstation 4.5, definitely visit our web site at www.winlinanswers.com

VMware has instructions on how to load the tools on web site at http://tinyurl.com/9d47r for both VMware 5.0 and other version of VMware (like GSX 3.2 and VMware Workstation 4.5). These instructions are general guidelines for various Linux distributions. However, here is what we did to get Fedora Core 3 to run as a guest operating system. Here, we'll present instructions for 5.0 (see our web page at www.winlinanswers.com for tips on how to get VMware Workstation 4.5 and GSX 3.2 to run a Fedora guest):

Download a DVD-ROM installation image of Fedora Core 3 from http://fedora.redhat.com/ .
Create a new VMware virtual machine. Specify Red Hat Linux as the guest operating system.
Install Fedora Core 3 from the DVD image. When selecting packages, make sure you include the "Development Tools" (under the "Development" heading during installation). You do not have to include the X11 development packages.
When you have completed the installation process, log in as root.
Inside the VMware application, pull down the "VM" menu and choose "Install VMware Tools." This puts a fake CD-ROM in the drive of the Fedora Core 3 guest.
At a command prompt, type ls /media/ cdrom to see a list of files on the VMware tools CD. Note the name of the RPM package. In our version, the file name is VMwareTools-5.0.0-13125.i386.rpm . Note, if you see a lot of gobbeldy-gook when you take an listing of CD-ROM, we've found a reboot (and a re-log on) helps kick it in the pants.
At a command prompt type rpm -i /media/cdrom/{name_of_rpm_package_you_got_ in_the_last_step}.rpm
Once the previous command finishes, start the VMware installation script:
```
  vmware-config-tools.pl  
```
The installation script will ask a variety of questions. You may accept the default for each of these by pressing Enter, and we recommend that you do so. However, toward the end of the script, you're asked which screen resolution suits you. Choose whichever you want, say, 800x600 or 1024x768.

The VMware tools are now installed, but you have two more steps. You need to run it the first time, then also tell the tools to run every time you graphically boot.

To run it the first time, open a command-prompt and type vmware-toolbox . When you do, you'll be able to check out the various VMware options. The most meaningful being on the first page to allow for time synchronization with the host. Note that the mouse is now allowed to freely move between the Fedora Core 3 guest and the host machine. Click Close to close the vmware-toolbox .

Now, we need to make the vmware-tools (a service) run at every startup we make graphically. To do this we can use the system-config-services command. Once running select Action Add Service. Simply type in vmware-tools (not vmware-toolbox) and click OK. You've now added the vmware-tools to automatically be run in the background every time the machine boots graphically.

We have found that failing to install the VMware tools makes both the guest operating system and the host operating system much slower and makes the guest less stable, so we strongly recommend installing them as specified above.

Once the tools are installed, reboot your Fedora Core 3 machine and ensure the tools are working. You'll know they're working if you can freely move the mouse in and out of the virtual machine.

Bochs

There's a free alternative to commercial virtualization software. There are several projects, in fact, but only one can run Windows XP or Windows 2003 at present. That solution is called Bochs and can be found at http://bochs. sourceforge .net/ . You can see a Windows XP machine running Bochs in Figure 7.3.

Figure 7.3: Bochs is a virtual machine emulator that runs in Windows or Linux. Inside a Bochs guest, you can run Windows or Linux.

Installing Other Linux Distributions on VMware

There are other incompatibilities that can arise between the assumptions made by the VMware installation script and the reality of various Linux distributions. This is especially true with versions of VMware prior to 5. These incompatibilities generally have to do with the names and locations of files and applications. Specifically, in addition to the /dev/mouse problem, older VMware installers assume that Linux is using the X Window System software provided by the XFree86 organization. However, most distributions now install an alternative distribution of the X Window System from x.org. Unfortunately older versions of the VMware installer don't automatically catch this distinction and fail to configure the GUI correctly.

Fixes for these problems are available. The following discussion thread on the VMware website provides solutions:

www.vmware.com/community/thread.jspa?threadID=8923&messageID=99653

(The URL is also shortened as http://tinyurl.com/4tpne .)

Of course, using VMware 5 is the easiest way to resolve these difficulties, and could be a free upgrade for you depending on your circumstances.

The most important limitation of Bochs, and one that should be mentioned right up front, is performance. Simplifying a bit, VMware and Virtual PC simulate the peripherals attached to the computer. And so does Bochs. But VMware and Virtual PC execute the actual guest operating system application code natively on the real processor with speed that approaches that of a real PC. Bochs doesn't. Bochs simulates the processor, one machine language instruction at a time, which is very, very slow. Orders of magnitude slower than a real PC. There is a project to bring VMwarelike native code execution to Bochs, but as of this writing the project has been stalled for quite some time for lack of funding. See www.plex86.org/ for the latest on this effort.

Also, compared with VMware or Virtual PC, Bochs is a lot clunkier. Specifically, the GUI for setting up a virtual machine is lacking. In fact, it's a simple command text box, although it does get the job done.

Another problematic limitation of Bochs: communicating between the host PC and the guest PC can be difficult. Although Bochs supports virtual networking similar to that of VMware, in practice it is quite difficult to configure. In VMware, it just works.

For light duty, Bochs may be useful, but for tasks that require a virtual machine with performance in the same ballpark with the real, host machine, Bochs is not a good choice. Unless you're running Windows XP on a non-Intel-compatible architecture that can't run VMware, which is a very rare scenario (and you would know if it applied to you), Bochs is probably not a practical choice.

coLinux

The guys over at www.colinux.org have an interesting approach. The idea is to port the Linux kernel so it just runs on Windows. The Linux kernel becomes an application within the Windows operating system. You can try this on your xppro1.ad.corp.com machine if you like.

There are five major steps to getting coLinux running on your Windows box:

Preloading a special network driver, Winpcap
Downloading and installing coLinux on Windows and downloading a coLinux guest image
Unpacking a coLinux guest image
Downloading a swap file
Configuring the .XML file which describes our intended setup

Finally, we'll be able to run coLinux.

Loading Winpcap

To try coLinux out, you first need to load Winpcap, a free packet capture library for Windows. coLinux uses it to trick out your Windows network card so the coLinux installation can see it. You can get it at http://winpcap.polito.it/ or http://winpcap.mirror.ethereal.com/ .

Do this before proceeding.

Downloading and Installing coLinux and Downloading a coLinux Guest Image

You'll be asked several questions during your installation. In our tests, at the "Selected components to install" screen, we chose to load everything.

Here's our advice: Do not accept the default suggestion of installing to c:\program files\coLinux during the installation. Instead, choose to install coLinux at c:\coLinux , and you'll be much happier . This is because the default configuration file assumes you will choose c:\coLinux . Additionally, since you'll have to fire it off (later) at the command line, you'll be happier doing so from within c:\colinux rather than c:\program files\coLinux . No one enjoys using the cd command to access long paths with spaces.

Next, during the installation, you're asked which distribution you want to run: Debian or Gentoo. Our familiar Fedora Core 3 isn't currently supported by coLinux. In our tests, we chose Debian.

The selected distribution is downloaded to your coLinux installation directory. However, it is compressed in the high-compression .bz2 format and you'll need to unpack it. Under Linux, you would just use the bunzip2 command, but because we're in Windows we'll use the WinRAR archiving utility to solve this particular chicken-and-egg problem.

Additionally, during the install, you'll be prompted to load a third-party, downloadable Windows network driver. This is required for coLinux networking support. WinRAR can be found at http://www.rarlab.com/ if you choose to use it for unpacking as we did.

Downloading a Swap File

The next step is to download a Linux swap file. The idea is that coLinux writes its temporary stuff to the swap file, and coLinux needs its own swap space, independent of the Windows swap file. Here, you can download a swap file representing how much swap space you want to allocate to coLinux. Download the swap files from http://gniarf.nerim.net/colinux/swap/ .

For now, put the .bz2 file in the same directory as the rest of your coLinux. In our testing, we chose the swap_128Mb.bz2 file.

Unpacking Your Distribution and Swap File for coLinux

The quickest way to unpack .bz2 files is by using WinRAR, available from www.rarlab.com/ .

Unpack the two .bz2 files you downloaded, one for the distribution and one for the swap file. This produces files by the same names, minus the .bz2 extension. You will end up with files named Debian-3.0r2.ext3-mit-backports.1gb and swap_128Mb . We unpacked these to directories with the same names as their corresponding files.

Configuring the .XML Settings File

In your coLinux directory, there's a file named default.colinux.xml . Windows Notepad can't edit this; you'll need to use Windows Wordpad. Inside, you'll see a bunch of configuration parameters. In order to make this work, we simply had to find some default text and replace it with our situation. Here's a quick list of what to find and what to replace it with if you have followed our instructions exactly for installing coLinux thus far.

Find the line that says:

 <block_device index="0" path="\DosDevices\c:\coLinux\root_fs" enabled="true" />

Append it so it points directly at your unpacked Debian file. Specifically, ours now says:

 <block_device index="0" path="\DosDevices\c:\coLinux\Debian-3.0r2.ext3- mit-backports.1gb\Debian-3.0r2.ext3-mit-backports.1gb" enabled="true" />

Find the line that says:

 <block_device index="1" path="\DosDevices\c:\coLinux\  swap_device  " enabled="true" />

Edit it so it points directly at your unpacked 128MB swap file. Specifically, ours now says:

 <block_device index="1" path="\DosDevices\c:\coLinux\swap_128Mb\  swap_   128Mb  " enabled="true" />

Find the line that says:

 <memory size="64" />

Change it so it says:

 <memory size="128" />

Running coLinux

To fire up coLinux, at a Windows command prompt, first change to the c:\coLinux directory. Then run the command colinux-daemon -c default.colinux.xml . coLinux will boot. At the end of the boot process, you should see the display shown in Figure 7.4.

Figure 7.4: The top window shows Debian Linux running under coLinux. The bottom window is the monitor, which shows any errors during startup or runtime.

You can log in as root with root as the password.

There's a lot to be said for coLinux. It's possible for coLinux to successfully run a full GUI environment, and it also supports virtual networking more smoothly than Bochs. In addition, initial support for accessing the host file system (accessing, for instance, the C:\ drive of the host machine) has been added. coLinux is very promising and well worth a try. It's not a complete solution for power administrators today, but it's certainly a decent up-and-coming solution. A pretty good community forum and more detailed installation instructions can be found at http://wiki.colinux.org .