If you need to run MS Windows applications under Linux and haven’t been satisfied with the current solutions, here’s the road less traveled…
There are three methods of obtaining use of Microsoft (MS) Windows applications under Linux. They are:
Wine, available from ftp://tsx-11.mit.edu:/pub/linux/ALPHA/Wine/development/DOSEMU, available from ftp://tsx-11.mit.edu:/pub/linux/ALPHA/dosemu/DESQview/X (DV/X), available from QuarterDeck software
Wine is rather well-known, as is the excellent DOSEMU. While researching these methods, however, I discovered that there exists a wide misunderstanding of their current capabilities and status among Usenet readers. I certainly support the efforts of the Wine and DOSEMU crews to bring MS Windows applications to Linux, but the impression that either is “ready for prime time” only impedes their efforts. Annoyed users complain that the products are, as their developers themselves point out, very incomplete.
For instance, the file dosemu-0.60.2/dos/README.Windows contains this warning under the heading Windows 3.1 Protected Mode: WARNING!!! WARNING!!! WARNING!!! WARNING!!! WARNING!!! Danger Will Robinson!!! This is not yet fully supported and there are many known bugs! Large programs will almost certainly NOT WORK!!! BE PREPARED FOR SYSTEM CRASHES IF YOU TRY THIS!!!
The document goes on to list some of the problems; in short, it’s not yet ready for serious use, such as most work environments. Take a moment to read that README completely before experimenting. I found it to be accurate.
Wine has a similar status: the release notes proclaim that Wine is currently for developers only, and you should not yet expect your applications to work. Thus, a Linux user is left with two choices: reboot the system with DOS or use the slower DV/X. Linux users isolated from a network tend to think that rebooting with DOS is Okay, but those needing network services or the power of Linux on a regular basis should consider using DV/X.
DV/X is probably unknown to most LJ readers, and the thrust of this article is to introduce you to it. The three possibilities above are listed in order of speed—Wine will certainly be the fastest when it’ss finished. They are listed in reverse order of “success”—DV/X is capable of running nearly every large MS Windows application now. Because I am willing to pay a speed penalty in exchange for access to other Linux services while running MS Word or MS Excel, I have been happily utilizing DV/X for months. I look forward to the day that Wine (or DOSEMU) allows me to run MS Word without the speed penalty.
DV/X is QuarterDeck’s solution to bringing DOS to network computing (see ftp.qdeck.com:/pub or www.qdeck.com). QuarterDecki’s DOS software line includes the well-known QEMM memory manager and DESQview, the best DOS multi-tasker. DESQview was expanded into a network program several years ago as DESQview/X. This software product brought Unix programs to DOS via an X Window interface and provided DOS programs to networked Unix hosts with X. One of the most interesting features of DV/X is its ability to provide MS Windows applications to networked X boxes. The software had some delays coming to market, probably due to the difficulty of creating a program to translate MS Windows and X. It is now available as version 2.0 and is much improved.
To run MS Windows applications such as Word 6.0, Excel 5.0, and PowerPoint with DV/X, you need a dedicated DOS computer in addition to your Linux box. I used an old system, a 386DX with 12 Megabytes of RAM, at home and a spare 486DX2 machine at work. A network connection is necessary; I had pairs of SMC Ultra and 3COM 3C503 Ethernet cards. The DOS system doesn’t need a fast or powerful video card, as the X display on the Linux box will be where you control MS Windows. The DOS box needs at least 8 MB of RAM, since DV/X can easily use up 5 MB and MS Windows needs several more. QuarterDeck supplies networking software with DV/X as part of its base cost, but it’ss not TCP/IP-based. A Novell TCP/IP stack is available for an extra fee and has been offered several times at no cost as a purchase inducement.
Get your Linux system up with networking active (see the NET-2 HOWTO document). Install DV/X on the DOS box after installing the TCP/IP stack (you will need an ODI driver on the DOS side for a TCP/IP stack). Just follow the prompts (and DV/X manuals) and adjust per your network. On an isolated network, you may wish to allow access without passwords for easier use. Once Linux has networking running and DV/X is installed, run some ping checks to be sure that communications are working correctly. I get 1 to 2 millisecond ping times on either a dedicated two computer network or a crowded 10-BaseT hub. Try some large FTP transfers to accurately test the network; isolated networks should run hundreds of kilobytes per second when properly configured.
Once you think your “network computer” is ready, launch DV/X on the DOS box and bring up an Xterm on the Linux side. You will need a username besides root on the Linux side in order to simplify logins. Any username can have root’s “power” by setting the UID and GID to 0—something that might be convenient for overriding protections during file transfers. Obviously, don’t consider doing this if your network is connected in any way to the outside world. Also, if you do this, you are discarding all the file system and memory protections that protect you from damage caused by program bugs, viruses (none are documented to exist under Linux), and simple mistakes.
In the Linux Xterm, type:
$ xhost +dosboxname $ rsh dosboxname fileman
where dosboxname is the alias for the IP address for the DV/X DOS computer (you will need to have it in /etc/hosts on the Linux computer). After a few moments, you should get a new X-Window with the very useful DV/X File Manager. It’s similar to the old Norton Commander, an interface whose look and feel has been duplicated countless times. With the DV/X File Manager, you can log into networked hosts, initiate multiple file transfers, or perform routine disk housekeeping tasks. If the File Manager doesn’t work, take a look at whatever messages were displayed and check manuals, Usenet, friends, support lines, and maybe even the author…
Log into the Linux computer from the File Manager (under the Navigate radio button) as a user other than root. Work through the file system until you get to one of the directories in the font path for the X server (I used /usr/X386/lib/X11/fonts/misc). Note that File Manager doesn’t show symbolic links, so you need the actual pathname. On the DV/X side, maneuver to the BDF subdirectory under the DVX directory. Copy all the font files over to the Linux side (unless you never want to run DOS remotely) with a binary transfer. Check that the file sizes come out identical on both sides of the File Manager dialog box. Once that’s complete, you need to run mkfontdir in the Linux font directory you chose and restart the X server.
Now you can run remote DOS with:
$ rsh dosboxname dos
You might need to set up the xhost access list again. Without the transferred fonts, a remote DOS process might crash your X server. Now that you have these preliminary steps accomplished, you know that your “network computer” is working. Time for MS Windows. DV/X has a lot of interesting features, such as the Remote Program Launcher; spend some time exploring them.
Initially, you should start with MS Windows configured to use just a simple VGA Display driver. Getting MS Windows running if you have difficulties is a problem exclusively for their product support personnel. Naturally, if MS Windows doesn’t run on the DOS computer, it won’t work under DV/X. After getting the networked MS Windows running, you can get screen sizes of 1024×768 if your X display has room. Since DV/X is converting the video commands, you don’t need the actual video card drivers. Instead, you use the Windows “Super VGA 1024×768 256 colors Large Fonts” driver. Read the DV/X documentation on setting up WinX for best results. To run MS Windows under Linux X, you can type the following in an xterm:
$ rsh dosboxname winx
In a few moments, you should be able to launch applications other than Solitaire from MS Windows. You can even start another MS Windows process (if you have sufficient memory) that is completely independent of the first (be careful). You’re limited to Standard mode, but so far I haven’t come across an application I need that truly requires Enhanced mode. One of the first things you’ll need to do is change the MS Windows color scheme with the Control Panel Color tool (In the “Main” window). Otherwise, you may have invisible fonts! I suggest starting with the “Arizona” color scheme instead of the default.
TANSTAAFL: There Ain’t No Such Thing As A Free Lunch. As mentioned above, there is a speed penalty for using DV/X to get MS Windows applications under Linux. It’s a direct result of the network connection between the involved computers (that’s likely to be the slowest part of the pipeline). However, for many uses, that speed penalty may be negligible. Ten Mbit/s Ethernet is not very fast when compared to ISA bus speeds: ISA is 5 times faster than the original Ethernet. There are one hundred Mbit Ethernet cards appearing, for a cost about 2 times the 10 Mbit cards. One hundred Mbit cards should give DV/X MS Windows performance equivalent to an ISA video card, which is quite acceptable to many users. This is the most serious drawback, but it needs to be balanced against the alternatives—in short, your mileage may vary.
As I mentioned, the speed difference may be negligible—you may not even notice it. I still can’t type at even one-thousandth Ethernet speed. I find the major use of DV/X MS Windows to be typing large amounts of text without text layout or formatting concerns. The other major use is for tasks of under 30 minutes; in both cases, the speed penalty is not apparent or traded off against the time to change operating systems. The remaining gotchas are somewhat minor.
The DOS ODI driver may have some problems. I notice that the 16-bit Ultra cards don’t outperform the 8-bit 3C503 cards. I believe the Ultra ODI driver might be the cause. The network stack you use on the DOS computer can also make a difference—I’ve seen the best results from the Novell TCP stack. It’s RTFM time here.
You may see some color changes. I use fvwm as an X Window manager, and sometimes the MS Window picks up the colors of the fvwm pager when switching between pages. Usually the next dialog box clears the colors up. There may also be some rearranging of your X workplace in order to fit MS Windows in at higher resolutions. The Alt-F4 keystroke will no longer close the MS Windows application. Instead, under the standard fvwm setup, it will iconify the window. Double-clicking the corner of the menu bar still works nicely to terminate applications. The usual problems between DOS filename limitations and Unix file names exist during file transfer.
I use DV/X regularly after months of experimenting—in fact, I booted DOS last month and realized it had been 6 weeks since I had last ran DOS. DV/X is as stable as MS Windows (actually, a little better, since DESQview isolates tasks in a fashion similar to Linux). There are some silver linings in the slow speed cloud. DV/X File Manager is a very useful tool; we have an Apollo workstation that exercises it frequently. DV/X can provide remote printing services, making the Linux end a snap to configure. Oh, and yes, I used my network to assist in preparing this article. See Figure 1.
I’ve set up two networks with DV/X and Linux; most of it runs “right out of the box”. I’ve been using Linux at work for 10 months now and have only rarely been forced back into DOS. In fact, Linux applications have provided better answers to tasks than the less stable DOS equivalents on several occasions. Source code availability and group programming naturally lead to superior programs!