by Robert Pfister and Kamran Husain
IN THIS CHAPTER
DOSemu stands for DOS emulator. This is a bit of a misnomer, because DOSemu does
not actually emulate MS-DOS. Instead, it provides an environment in Linux under which
MS-DOS and MS-DOS applications can be run. DOSemu enables you to run MS-DOS sessions
The development of DOSemu is not yet complete. A small but growing number of MS-DOS applications will run under DOSemu. The most impressive application reported to run under DOSemu is the real mode of MS-Windows 3.0.
MS-DOS applications don't run as fast under DOSemu as they would under native MS-DOS, but most applications are fast enough. You have the added advantage of being able to run Linux and MS-DOS applications side by side.
The design of DOSemu will always cause some speed degradation, but the same design also provides the capability to virtualize a PC. The disk drives, serial ports, and memory configured under DOSemu do not need to match the hardware on your PC.
DOSemu is available on some CD-ROM distributions and on most major Linux BBSs and FTP sites, such as sunsite.unc.edu. The latest version available as of this writing was 0.53pl39 (pre-release 0.53, patch level 39). DOSemu is dependent on the version of the Linux kernel installed. Version 0.64 with vm86plus does not work with kernels before 2.0.0.
For the truly adventurous, the latest development version of DOSemu is available on the Internet via anonymous FTP at dspsun.eas.asu.edu:/pub/dosemu/. As with the development version of any software, it is not as thoroughly tested, and it might have some serious bugs. Stick to the released versions if at all possible. The latest released, stable version at the time of writing was dosemu0.64.1.tgz from tsx-11.mit.edu in the /pub/linux/ALPHA/dosemu/ subdirectory.
The DOSemu distribution needs to be installed in a directory under /usr/src. DOSemu does not build correctly if the distribution is installed elsewhere. A DOSemu distribution consists of a compressed tar file that is unpacked by a shell command such as this:
bash# tar -zxvf filename.tar.gz
DOSemu is undergoing constant revisions. Review the QuickStart and other README files before proceeding.
DOSemu is distributed as source code that needs to be compiled and linked before you use it. This is not a very complicated task because the process is automated. To build DOSemu, you need the following software installed:
To build DOSemu, log in as root, change directory (cd) to the directory created by unpacking the tar archive, and type the following commands:
bash# ./configure # or ./configure -emable-SMPmodules if running with emumodule bash# make bash# make install
The DOSemu distribution includes a reference manual written in TeX. If you have TeX installed and want to create a typeset version of the manual, use make everything rather than make most.
To properly compile DOSemu, you need to be logged in as root and have approximately 12MB of virtual memory free. Use the top command to check how much free memory is available. You can increase the free memory either by installing an additional swap file or by killing unnecessary processes. Fortunately, you need excess memory only to compile DOSemu.
The full build of DOSemu takes approximately five minutes on a 90MHz Pentium. When the build is complete, you are ready to configure and run DOSemu.
DOSemu can be configured to boot MS-DOS from a floppy or hard drive. As when configuring a real PC, you usually start by booting from a floppy and work up to booting from a hard drive.
The simplest and safest way to initially configure DOSemu is by using a boot floppy. Create a bootable DOS floppy from your favorite DOS distribution. DOSemu supports MS-DOS versions 3.3 through 6.22, as well as DR-DOS 6.0.
In addition to bootable DOS, the disk should have the following DOS files:
From the dosemu subdirectory, copy the following device drivers onto the floppy:
From the command subdirectory, copy the following file:
exitemu.com
Everything you need to configure DOSemu exists in the file /etc/dosemu.conf. A user-specific configuration file can be created in a user's home directory named ~/.dosrc. Both of these files have the same format. I will refer to these files interchangeably as dosemu.conf. A sample configuration file is in the etc/ subdirectory of the standard DOSemu distribution. Look for the file named dosemu.dist.
The example file is several hundred lines long. Most of this configuration file contains comments to help explain the configuration options. Anything to the right of a # character is a comment. A # in the first column means that the entire line is a comment. Sample configuration lines for nearly all supported hardware and software options are contained in this file. Most DOSemu configurations can be expressed in 25 to 30 lines.
Configuration parameters in /etc/dosemu.conf have two basic formats. A parameter that needs just one value has the form parameter value. A parameter that needs multiple values has the form parameter { value1 value2 ... }.
One way to configure DOSemu is to copy the example configuration file to /etc/dosemu.conf and then edit the parameters based on information in the comments. Another way is to create a simple dosemu.conf file and add to it as needed. A bare-bones file looks like this:
timint on
keyboard { layout us keybint on rawkeyboard on }
video { vga console }
cpu 80486
bootA
floppy { device /dev/fd0 threeinch }
Use a text editor to make the following customizations to dosemu.conf based on your actual hardware:
Make sure your drive A floppy is not mounted under Linux, and insert your boot floppy into drive A. Start DOSemu from a virtual console by typing DOS. Your version of DOS will boot from drive A, and you should be at the familiar A:> prompt. If you are using an empty MS-DOS disk, you will soon run out of things to do. To exit the DOSemu prompt, press Ctrl-Alt-Page Down, or use the exitemu.com command provided on your boot floppy.
Most Linux users have DOS partitions on a hard drive. Some might even have a separate hard drive dedicated to DOS. This section shows several ways to configure DOSemu to access these drives as native DOS disks. You can abandon your boot floppy and boot from a hard drive, even if you do not have an MS-DOS-formatted drive or partition anywhere. Accessing a Dedicated MS-DOS Disk or Partition The easiest way to access a hard drive is to configure the drive in your dosemu.conf file. The disk or partition in question must be formatted for MS-DOS and be a primary partition. Extended DOS partitions are not yet supported. Following is the format of the parameter entry to access a hard drive:
disk { type "device" readonly }
The type parameter can be partition or wholedisk, and the device is the Linux device being accessed. Typical names would be /dev/hda1 for a partition or /dev/sda for an entire disk. The readonly qualifier is optional, and as the name implies, it write-locks the disk or partition in question. If you boot Linux from a hard drive using LILO, do not access that drive using wholedisk. When DOSemu boots from that drive, it gives you a LILO prompt. Unfortunately, neither LILO nor Linux runs from within a DOSemu session.
Following are some examples of valid entries for disks:
disk { partition "/dev/sda4" } # mount 4th partition
disk { partition "/dev/hda1" readonly} # mount 1st IDE partition readonly
disk { wholedisk "/dev/sda" } # mount the whole 1st SCSI disk
How to Access any Linux Directory from DOSemu A much safer way to access a DOS directory is through the emufs.sys device driver. This driver enables you to access any Linux subdirectory as a logical device under DOS. In your config.sys of your boot device, simply add the lines
device = emufs.sys /c
where /c is the Linux directory you want to mount. The next available drive letter is used for this logical drive.
Any disk or device mounted in the Linux file system can be made available to DOSemu as a logical disk through the emufs driver. Disks and directories do not need to be DOS-formatted and can include CD-ROMs as well as NFS and IPX mounted disks. Files in these directories, however, must be in the MS-DOS 6.0 format to be visible under DOSemu.
With a logical device you can perform typical operations, such as read, write, and delete files, and run executables. Utilities such as drvspace, undelete, and defrag do not work on disks accessed through dosemufs.
DOSemu has an additional abstraction called a diskimage. A diskimage is a Linux file that appears to DOS as a logical device. Either a floppy or a hard disk is supported as a diskimage. A diskimage makes an ideal boot device because the size can be set just large enough to boot MS-DOS. Unlike drives accessed by dosemufs, drives configured by diskimages work with such utilities as undelete, scandisk, and defrag. Creating Floppy Image Files A floppy disk file is easy to create under Linux. The floppy image file does not need to do anything except exist initially. To create an initial floppy image file, use the touch command; for example,
touch filename
This new floppy will appear as an unformatted floppy when you boot DOSemu. Because the size of the floppy is configured in DOSemu, formatting the floppy will expand the image file to the expected size (1.44MB for a high-density 31/2-inch floppy). Accessing a Floppy Image Under DOSemu To use a floppy disk, you need to specify the floppy geometry for the benefit of DOS:
floppy { heads 2 sectors 18 tracks 80 threeinch file /usr/dos/hdimage }
This simulates a 1.44MB, 31/2-inch floppy. A diskimage floppy can be used in the same way as any floppy, except that it cannot be removed. Expect the diskimage floppy to operate significantly faster than a real floppy, with formatting taking only a few seconds.
Creating Hard Diskimage Files Under Linux Hard diskimage files are more confusing to configure than floppies. To initially create the hard disk file, use the command mkhdimage found in the periph directory of the DOSemu distribution. Instead of specifying the size of the image, you need to specify the number of heads, sectors, and cylinders of the disk to create. Following is an example mkhdimage command that creates a 10MB disk:
mkhdimage -h 8 -s 20 -c 128 > /usr/dos/hdimage
To compute the size of a disk based on disk geometry, multiply headsxsectorsxcylindersx512 (number of bytes per sector under MS-DOS). Because these parameters do not represent the real characteristics of a disk, the ratio of heads to sectors to cylinders does not matter to DOSemu. However, MS-DOS recognizes only the first 1,024 cylinders of a disk.
Because mkhdimage creates a file of only 128 bytes, no other check of available space for the configured amount takes place. Do not configure a diskimage drive larger than the available disk space. Accessing a Diskimage Under DOS To use a diskimage as a logical hard drive, use the disk parameter with a type of image rather than wholedisk or partition, as well as the name of the Linux file used:
disk { image "/usr/dos/hdimage" }
Like floppy diskimages, hard diskimages are not initially formatted. When a diskimage file is initialized, it is also unpartitioned. Use the MS-DOS fdisk utility to create a partition on the drive you configure. To avoid confusion and data loss, configure DOSemu with only one real floppy and only the new hard diskimage for a hard drive. Sometimes a new diskimage will appear to fdisk to have a partition created, but MS-DOS is unable to access the partition. The easy fix is to delete the existing partition and re-create it.
Hard diskimages are different from floppies in that disk space used under Linux is allocated on demand. A newly formatted diskimage of any size takes up enough disk space to store FAT information. The disk file grows as disk space is used under DOS. An interesting observation is that if a diskimage is drvspaced under MS-DOS, drvspace allocates the entire amount of space for its drive mapping.
Linux's virtual console can support more than just text-mode virtual consoles. Due to the direct-access nature of most DOS-based video, this is perhaps DOSemu's biggest weakness. Not all video boards work correctly with DOSemu, and even fewer work perfectly. The basic configuration for the video section with graphics looks like this:
video { type console graphics chipset chipset_type memsize kb vbios_seg address
vbios_size=hex }
If your video board is 100 percent VGA compatible, omitting everything past the keyword graphics might work.
The following chipset keywords are supported:
Video boards that do not have the BIOS configured at 0xC000 need the vbios_seg to be set to the actual address. When in doubt, you can determine the video BIOS starting address (vbios_seg) as well as the video BIOS size (vbios_size) by using the Microsoft Diagnostics (MSD) utility that comes with MS-DOS and MS-Windows.
The following line allows DOS access to known video ports directly and helps compatibility:
allowvideoaccess on
DOSemu does not need to run under just a Linux virtual console. DOSemu can run in an xterm, on a remote (network or dial-up) connection, or within its own X Window interface. Remote connections and xterms are configurable in exactly the same way as virtual consoles, except that no levels of graphics are possible. Remote sessions typically cannot generate a Ctrl-Alt-Page Down to end the session; using the exitemu.com is the quickest way to end a remote DOS session.
The X Window interface to DOSemu is called xdos. Xdos is a relatively recent development for DOSemu, and it has only a few additional advantages over running DOSemu in an xterm. Xdos has built-in mouse support so that a mouse supported under X Window also works within the xdos window. Graphics support does not yet exist for xdos, but it might eventually be possible--development work is underway. Figure 62.1 shows a sample xdos session running within X Window. Configuration parameters available for xdos are listed in Table 62.1.
Parameters specific to xdos take the following form:
X { param1 value1 param2 value2}
FIGURE 62.1. A sample xdos session running under X Window.
Table 62.1. Xdos-specific dosemu.conf parameters.
| Parameter | Sample | Meaning |
| title | "DOS box" | X Window-specific title. |
| display | "mybox:0" | X server to use if xdos is to be displayed on another X server. |
| font | "vga" | Monospaced font to be used. |
| icon_name | "xdos" | Icon name to use when DOSemu is iconized. |
| updatelines | 25 | Number of text lines in the display. |
| updatefreq | 8 | How often X updates the xdos screen. 20 is approximately once per second. |
| blinkrate | 8 | How often the cursor blinks. |
A starting point for configuring xdos is the following line:
X { title "DOS box" icon_name "xdos" updatelines 25 updatefreq 8}
The DOSemu keyboard can be configured to handle various keyboard layouts for international keyboards. If a given layout is available in the Linux kernel configuration, it is probably available to DOSemu. This is the default configuration for a keyboard:
keyboard { layout us keybint on rawkeyboard off }
The keybint option enables DOSemu to handle keyboard interrupts more accurately but is a bit unstable.
The normal keyboard handlers should suffice for simpler DOS tasks, but they don't handle more complicated keystrokes. Keyboard-intensive packages such as WordPerfect that make heavy use of Alt and Ctrl keys need to be represented better. The rawkeyboard option offers a nearly complete representation of the PC keyboard by bypassing all key translations. This is known as raw mode. To use raw mode, simply turn it on in the keyboard configuration. Raw mode is possible only when you are running DOSemu from a virtual console.
If you are running xdos, the keyboard mapping is controlled mainly by your ~/.Xmodmap file. Because the Backspace and Delete keys are typically reversed under X Window, the following Linux commands restore the expected keystrokes:
xmodmap -e "keycode 107 = 0xffff" xmodmap -e "keycode 22 = 0xff08"
Changing this mapping might cause the same problem with other X Window applications.
To configure serial ports, you simply need to make them known to DOSemu. The basic configuration looks like this:
serial { com1 device /dev/cua0 }
This example maps DOSemu's com1 to Linux's serial port 0 (which maps to COM1 under native DOS). You can specify additional parameters, such as the port address and IRQ. All the serial port parameters except the Linux port apply only to ports configured under DOSemu. DOSemu accesses the real serial ports as Linux devices that are configured by the kernel. The IRQ, COM port number, and port addresses are what you want DOSemu to simulate, and they do not need to match the actual hardware. The same IRQ restrictions between COM 1/3 and COM 2/4 still exist under DOSemu. If you cannot use two ports simultaneously under Linux, you cannot do so under DOSemu.
The following example configures the hardware com1 as com3 with a different IRQ and base address:
serial { com3 base 0x3e8 iq 5 device /dev/cua0 }
It is generally less confusing if you configure ports as they really exist.
Printers under DOSemu can print to a device or file, or you can let a Linux program such as lpr handle the output. Each printer statement in dosemu.conf is assigned an LPT device number in the order in which it occurs in the file. Multiple printers can be declared to DOSemu; however, MS-DOS has a set limit of three LPT devices.
To configure a printer to save to a file or device, simply specify the file keyword and the name of the file or device. A timeout value specifies how long DOSemu waits in seconds after the last character is received before flushing data and closing the file or device. Here are some example printer configurations using a file and device designation:
printer { file "/usr/tmp/dos-print-1" timeout 10 }
printer { file "/dev/lp1" timeout 10 }
To configure a printer to send data through an external program such as lpr, specify the command to use and any options to include on the print line. The option parameter must contain the string %s in the same place you would specify the filename if you were using this command under Linux (for example, lpr -p %s). An example of configuring the printer to print using lpr is as follows:
printer { command "lpr" options "-p %s" timeout 10 }
DOSemu implements printing as a two-step process:
When the timeout expires, DOSemu closes the temporary file and issues the specified command. The directory /usr/tmp needs to exist to save the temporary files, and it should have world access. Setting the sticky bit on this directory helps speed up printing. The sticky bit speeds up file access by maintaining the files in memory rather than only on disk.
You can get limited support for Netware access by using IPX from within DOSemu with the use of the pktdrv driver.
The pktdrv packet driver uses interrupt 0x62. Following is the general procedure for adding support:
Now recompile DOSemu. Then take the steps described in the v-net/dosnet.README file and rerun the emulator. There is also a file called Netware-HOWTO, by Lauri Tischler (ltischler@fipower.pp.fi), that is included with the DOSemu distribution. You can also get this document at the Web site http://sunsite.unc.edu/mdw/linux.html.
A large level of debugging information is available under DOSemu. This information is sent to stderr, but it can be sent to a file using redirection; for example,
dos 2> dbg.out
Or it can be sent through a DOS command-line option:
dos -p dbg.out
Approximately 20 different debug message types can be turned on. When you are configuring DOSemu, the most useful message type is the config parameter. This points out syntax problems in the configuration file. Turning on debug information is most helpful when DOSemu returns to the shell prompt without any error messages.
The following debug configuration example shows all the available debug parameters:
debug { config off disk off warning off hardware off
port off read off general off IPC off
video off write off xms off ems off
serial off keyb off dpmi off printer off
mouse off}
Several miscellaneous parameters can be adjusted for DOSemu. Table 62.2 shows the various parameters and their meanings.
Table 62.2. Other DOSemu configuration parameters.
| Parameter | Possible Values | Meaning |
| dosbanner | "on" or "off" | Turns on/off welcome banner when booting DOSemu. |
| mathco | "on" or "off" | Tells MS-DOS if a coprocessor is available. Because Linux already emulates a math coprocessor, set this parameter to "on". |
| dpmi | "on" or "off" | Turns on DPMI support. This is a bit unstable, so use with caution. |
| FastFloppy | Number | Turns on higher-speed floppy access. Use with caution. |
| speaker | "off", "native", | Turns on access to speaker by |
| "emulated" | direct access, emulated or by a speaker emulation mode. | |
| EmuSys | File extension | Uses an alternative config.sys file with this file extension. A good value might be "EMU". Alternative to |
| DOS 6 boot menus. | ||
| EmuBat | File extension | Uses an alternative autoexec.bat file with this file extension. Similar to EmuSYS. |
| cpu | 80286, 80386 | CPU type to emulate. Because you won't fool all programs, use what you really have. |
| ipxsupport | "on" or "off" | Allows IPX access through the Linux kernel. |
| xms | Size in kilobytes | Amount of XMS memory to make |
| or "off" | available. | |
| ems | Size in kilobytes | Amount of EMS memory to make |
| or "off" | available. | |
| Hogthreshold | Number | The higher the number, the longer DOS can "hog" the CPU waiting for a keystroke. An initial setting of 5000 is a good starting point. Set to 0 to turn off hog detection. |
| bootB | Specifies that DOS is to boot from the floppy configured as B. | |
| ports{ } | Allows DOSemu access to specific hardware ports. List the hex values of hardware ports desired. | |
| mouse | Type of mouse | Microsoft, Logitech, mmseries, |
| you have | Mouseman, Hitachi, busmouse, Mousesystems, and PS2 are supported. |
Table 62.3 shows the command options supported on the DOSemu command line. Options specified here override conflicting parameters specified in the dosemu.conf file. A few other options are available, but those are either intended for development use or are not completely supported yet. Use the -? option to get a complete list of the command options.
Table 62.3. DOSemu command-line options.
| Option | Meaning |
| -A | Boot from floppy A |
| -C | Boot from hard drive C |
| -D | Set debug options |
| -F | Number of floppy disks to use from dosemu.conf (1-4) |
| -H | Number of hard disks to use from dosemu.conf (1 or 2) |
| -P | Copy debug information to file, same as using 2> |
| -V | Turn on VGA emulation |
| -c | Optimize video performance under virtual consoles |
| -e | Specify the amount of EMS memory to make available |
| -f | Flip definition of A: and B: floppy |
| -k | Use raw keyboard console (rawkeyboard in dosemu.conf) |
| -t | Deliver time interrupt 9 |
| -x | Specify the amount of XMS memory to make available |
| -? | Print command summary only |
| -2 | Emulate a 286 |
| -3 | Emulate a 386 |
| -4 | Emulate a 486 |
DOSemu is not perfect yet. Development is underway, with many known opportunities for speed optimizations and improvements.
Perhaps the most significant application that does not run under DOSemu is Windows 3.1. As with Linux in general, volunteers are working to correct this limitation. Other software that requires DOS Protected Mode Interface (DPMI) is also likely to cause problems. To find an up-to-date list of software that has been successfully used under DOSemu, look for the file /doc/EMUsucess.txt in the DOSemu distribution.
Not all video cards are currently supported under DOSemu. More popular cards are supported simply because developers are more likely to have them. Some nontypical hardware is reported to work under DOSemu with some patches.
Some sound cards are problematic under DOSemu. They have the potential to perform DMA (direct memory access) to memory the Linux kernel had allocated elsewhere. A generic sound-card interface that interacts with the kernel's built-in sound card support would solve this problem.
DOSemu runs slower than a native MS-DOS session. I have successfully run a few older benchmark programs under DOSemu to compare the performance degradation with that of native MS-DOS. Benchmark results are not a perfect measure, but they do demonstrate potential performance in some distinct areas. I measured three different areas: CPU performance, disk performance, and video performance, each of which produced strangely different results. CPU Performance DOSemu's raw CPU speed depends on what else is happening under Linux. With an otherwise idle Linux box, DOSemu's compute speed is close to that of a native MS-DOS session. The Landmark Version 2.0 and PC-Bench Version 5.6 show similar performance, with perhaps a 10 to 20 percent performance penalty under DOSemu for the instruction mix, CPU, and FPU measurements. Disk Performance Determining the disk-speed degradation under DOSemu proved to be difficult. In some cases there was a performance decrease, and in others a performance increase. This discrepancy seems directly related to the quality of support of the controller and disk drive from the underlying Linux kernel, as well as the built-in caching provided by Linux.
Linux runs as a pure 32-bit operating system and handles I/O operations to disk controllers in bait mode. This, combined with much better SCSI support, can lead to equal or better disk benchmark numbers under DOSemu than under native DOS. Not all disks are as fast under DOSemu, with performance degradation ranging from small to huge. As with CPU speed, disk speed depends on what other Linux tasks are doing. Video Performance Video support is Linux's Achilles' heel. Text performance is much slower when DOSemu is not being run under a virtual console. Under a virtual console, benchmarked text speed approaches that achieved with native MS-DOS. When you are using real-world applications, the text speed is dramatically slower, with an observed speed as low as 20 percent of the speed under native MS-DOS. Graphics speed is even worse.
For mouse support, you can get Microsoft-compatible mouse drivers from oak.oakland.edu:/pub/msdos/mouse/mouse701.zip (mscmouse). Make sure that you have the correct port assigned to the mouse. Even so, some mice do not get recognized for up to 62 seconds, so be patient.
Another known problem is that DOSemu is not able to use COM4 after DOSemu finishes execution. This port is at 0x2E8, /dev/cua3 in Linux, and uses interrupt 5. You can run the following command:
setserial /dev/cua3 irq 5
Another cure is to disable the allowvideoportaccess on line in the config file.
A few changes will help DOS performance under DOSemu, short of buying a faster PC.
Garrot is an MS-DOS-based Terminate and Stay Resident (TSR) program, written by Thomas G. McWilliams, that releases CPU time from a DOSemu process back to Linux. Some MS-DOS applications poll endlessly on events such as keyboard input. Garrot keeps track of how long a DOS application has been running without giving control back to Linux. After a threshold of time has expired, control returns to Linux. The Garrot threshold is best determined by trial and error. A good initial value is half the bogo-mips value. Bogo-mips is the value that the Linux kernel for internal delay loops, and it is displayed during bootup of the Linux kernel.
For CPU-intensive DOS applications, Garrot causes a minor degradation in CPU speed. For non-CPU-intensive applications, Garrot shows a dramatic decrease in overall CPU usage, as measured by the Linux utility called top.
The following parameters in dosemu.conf can help speed up various aspects of DOSemu:
Because DOSemu runs as a Linux process, any general Linux optimizations should also help performance under DOSemu. Typical optimizations include having enough swap space, optimizing the kernel, and killing unneeded Linux processes.
The DOSemu manual (dosemu.texinfo), written by Robert Sanders, has not been updated in some time but is still a good source of information. It is distributed with DOSemu.
The "dosEMU Novice's Altering Guide," or DANG, is a road map to the inner workings of DOSemu. It is designed for the adventurous, those people who want to modify the source code themselves. DANG is maintained by Alistair MacDonald (am20@unix.york.ac.uk) and is posted periodically to the MSDOS channel of Linux Activists.
The EMU success list (EMUsuccess.txt) is a list of all programs that have been reported to work with DOSemu. It is posted periodically to the mailing list. The most recent version can be found on dspsun.eas.asu.edu:/pub/dosemu.
Of course, there is the DOSemu FAQ/HOWTO. But you already know about that, don't you? It is also posted frequently to the mailing list. The most recent version can be found on dspsun.eas.asu.edu:/pub/dosemu.
Try subscribing to the linux-msdos-digest mailing list. To subscribe, send e-mail to Majordomo@vger.rutgers.edu with the following command in the body of your message:
subscribe linux-msdos-digest your_username@your.email.address
To get rid of these messages, send e-mail to Majordomo@vger.rutgers.edu with the following command in the body of your e-mail message:
unsubscribe linux-msdos-digest your_username@your.email.address
DOSemu works similar to the DOS feature of MS-Windows in that it uses the virtual 86 (vm86) feature of the i386 and above chips. Under vm86, a process runs under a private 80x86 environment that is isolated by the i386 processor from any other process.
In addition to private access to an 80x86 processor, MS-DOS and MS-DOS applications need to interact with PC hardware through port accesses and interrupt functions. In vm86 mode, both port access and interrupts return vm86 back to the DOSemu.
For port access attempts, DOSemu tries to recognize the port and either simulates its function or passes the request to the real hardware. Ports that DOSemu is allowed to map are configured by the Port parameter in dosemu.conf. Direct access to hardware ports is possible under Linux through /dev/kmem support.
DOS interrupt functions are widely understood and well-documented. Interrupts are caught from virtual 86 mode and are implemented by executing the equivalent functionality as Linux system calls.
The first release of DOSemu was written by Matthias Lautner in September 1992. Since that time, many other people have contributed major pieces of functionality. There are too many authors to name, but some of the more significant contributors include Robert Sanders, James MacLean, Andres Tridgell, Stephen Tweedie, and Andreas Kies. Other parts of DOSemu functionality were borrowed from Carnegie-Mellon's MACH DOS emulator.
The Bochs emulator is a new contender as a DOS emulator for Linux. The emulator fully emulates the 80286 instruction set. A beta version for the 80386 was under development when this book went to print. The author of this program is Kevin P. Lawton. You can send mail to the developers via the address boac@world.std.com. Information that is more up-to-date than any printed matter can be seen on the Web pages at http://world.std.com/~boch.
The Bochs software is shareware and is not entirely free. There is a US $25 charge for using Bochs in a commercial application and an "optional" fee for personal use. Maybe the cost of a pizza will do? Send mail to the author for an exact amount. Also, pronounce Bochs as "box," not as "Boches." Looking at the source code in some of the C files revealed that the Bochs product is labeled a commercial product, as opposed to a shareware product.
The main advantage of Bochs over DOSemu or Wine is that Bochs requires no x86 instruction set to run on. All BIOS and the instruction set are emulated in software. This causes Bochs to run slower than DOSemu, but it also makes Bochs portable to other UNIX platforms, such as Sun Microsystem Inc.'s Solaris. The Bochs emulator literally emulates a CPU in software and processes instructions individually.
Bochs runs Windows 3.1 with enhanced mode support and runs DOS up to version 6.22. Only monochrome monitors are supported. There is neither support for networking nor support for mice. The maximum hard drive size I worked with was 20MB, although the documentation mentions that up to 30MB can be supported.
Before you install Bochs, you must have a DOS bootable floppy on hand. Bochs does not provide a way for you to create a DOS bootable floppy. Find or make such a floppy while you download Bochs. Also, you will need the FORMAT.COM and FDISK.EXE programs on the floppy. Be sure to copy these DOS files onto the bootable floppy. The size of the bootable floppy will depend on what /dev/fd0 points to in your Linux machine. In my case, it points to /dev/fd0H1440, a 1.44MB floppy drive.
Now let's go get the distribution files. The latest version of the software was 962928a.tar.gz in the ftp site and directory world.std.com/pub/bochs. (You will most likely get a later version.) The format for file archives is
bochs-YYMMDD.tar.gz
where YY is the year, MM the month, and DD the day. The way to unzip and install the program is to use the following commands in the directory where you download the archive:
$ gunzip -d bochs-962928a.tar.gz $ tar -xvf bochs-962928a.tar
You will find a subdirectory called bochs-YYMMDD in the directory where you untarred the files. Go to this subdirectory and then modify the environment to set the CFLAGS variable to "-O3 -Wall -m486" even if you use a Pentium processor:
$ CFLAGS="-O3 -Wall -m486"; export CFLAGS
Then run the configure script like this:
$ ./configure --enable-80286 --enable-native-floppy $ make
The make program might complain about not finding the VGA font. The INSTALL file in the Bochs archive contains information about how to install this software. Copy the file vga.pcf into the /usr/lib/X11/fonts/misc directory as root, and run the make file again. The vga.pcf file is in the fonts subdirectory of the Bochs distribution.
Now put the 1.44 boot floppy in drive A, and issue the following command to copy the image to a file called 1.44:
$ dd if=/dev/fd0 of=1.44 ibs=512
Then create a 20MB hard drive image with a bunch of zeroes in it. Here is the command to do this:
$ dd if=/dev/zero of=20M bs=512 count=41820
Now modify the contents of the .bochrc file in the source tree root to contain the following lines:
floppya: file=./1.44 floppyb: diskc: file=./20M
The floppyb line is empty to indicate that there is no drive B. With the floppy disk still in drive A, start the Bochs emulator with this command:
$ bochs -bootA
After a brief flurry of messages, you will see a DOS prompt. The emulator somehow manages to bypass the DOS standard request for date and time and presents the prompt directly. If you have an autoexec.bat file in the boot floppy whose image you created, the autoexec.bat file will be used instead.
When you first boot up, drive C (your 20MB file) is empty. You have to run the FDISK program to set up the partitions and format them. Sounds scary, doesn't it? Don't worry; as long as you have set up the file names correctly in the .bochrc file, you should be working only with diskimages. I did not have the guts to change the filenames in the .bochrc file to a device name just yet.
Within FDISK, choose the Create Primary Partition option. Assign all 20MB to this primary partition by allowing for the maximum size. After the FDISK program is done, you must reboot the Bochs emulator. Stopping the emulator is easy; just click once with the mouse on the screen.
Restart Bochs and then format drive C:
$ bochs -bootA A> format /s C:
After the format is complete, stop the emulator by clicking your mouse on the window.
Now, let's see whether we can access the floppy on the Linux machine from within Bochs. Modify the floppyb in the .boschrc file to this:
floppyb: file=1_44=/dev/fd0
Now drive B is the physical floppy /dev/fd0 on the Linux machine. To boot via drive C, run the Bochs emulator with this command:
$ bochs -bootC
At this point, you can do several things, including installing Windows 3.0 or 3.1. Do not install Windows for Workgroups 3.11 because THE SETUP program for 3.11 locked up the emulator. (I had to dig out my old Windows 3.0 disks for this one.) Also, the Windows keyboard support is for the All AT Keyboards selection only. Other standard entries for the Windows setup worked as promised.
The DOS print command did not work at all. Also, the printer support did not work at all in Windows. There is no mention of work toward such a venture in documentation outlining future work.
Another important point to remember is that, even though you are running Windows, there is no mouse support. One click of the mouse in the window under Bochs brings the emulator to a screeching halt. Also, the documentation mentions limited CMOS and BIOS interrupt emulation, so even some DOS games might not work correctly. This is still in beta stages.
All in all, the Bochs emulator is a good package even in its beta state. Its future enhancements such as support for the mouse and for the use of color VGA monitors will make Bochs a very lucrative, portable DOS emulator. Stay tuned to the Net for further releases.
Several DOS emulators are available for UNIX (and Linux). This chapter provides only a very brief introduction to a few of these emulators. Just keep in mind that an emulator will probably never work as fast as the "real thing," such as a PC running DOS. Given that there will be some limitations in performance, you have to make your own choice on when to reboot and when to run an emulation program. Sometimes, a DOS emulator might work for your simple programs quite well and obviate the need to reboot. Sometimes, you will find it easier to reboot.