Using Linux and DOS Together

 in
Installing Linux on a machine for the first time is often a painful experience. There are a number of useful programs and techniques for running Linux on machines which run both DOS and Linux, some of which appeared in DOS 5. Understanding and using these techniques makes it possible to use them under DOSEMU whenever relevant.
DOSEMU's View of File Systems

DOSEMU can access files in several different ways, which integrate with DOS and Linux in different ways. The methods are:

image

A file which is arranged to look like a DOS hard disk. It is a “virtual” hard disk stored in a file.

partition

Direct access to an MS-DOS partition. If the partition is also being used on Linux, it should not be writable. Be aware that you can use mounted partitions as DOSEMU file systems, which can destroy the file system. It is safest if they are both used readonly; if you want to make them writable you should only make one of them writable at a time. In addition, if the DOS partition is writable from DOSEMU, multiple DOSEMU sessions can cause the same kinds of filesystem destruction.

whole disk

Use the whole disk directly. Be vary careful with this. When used, it is useful to set it [cw]readonly[ecw].

redirected access Access any Linux directory via a redirector. This is extremely

interesting—read on to learn more about this.

Typically, DOSEMU boots off a small image file (a specially constructed file which appears to DOSEMU like a hard disk, with its own file system and master boot record). Floppy disks are treated like conventional floppy disks. DOSEMU can read them—and you need a bootable MSDOS floppy to start the process. To start setting up the virtual hard disk as C: drive, you first boot off the bootable MSDOS floppy, and then do:

A>fdisk /mbr
A>sys c:

Then you can boot off the virtual hard disk C:. This is covered more fully in the DOSEMU documentation.

The image hard disk is often used just to get DOSEMU going. You can treat this image as a large virtual hard disk, but the disadvantage is you can only access this disk from DOSEMU. The other forms, which will be explained, can all be accessed from Linux, and MS-DOS partitions can be accessed from raw MS-DOS.

DOSEMU supports whole disk access (such as /dev/hdc) and partition access. I have never used whole disk access and there doesn't appear to be a good reason to do it. I have, however, used partition access. Those partitions cannot be mounted by Linux at the same time, since DOSEMU manipulates the physical partition, which will confuse the kernel, and potentially destroy the partition. DOSEMU needs to have access to the physical partitions (you have to make sure you have the permission to read and write).

The most interesting method I've found is the redirector. This allows you to treat a Linux file system as a network drive. If you redirect the root of your Linux file system, you can easily access all your linux files in DOSEMU. If you have NFS mounts or an auto mounter running, you can even traverse to other machines seamlessly. Note that everything it finds it must convert to an 8+3 MS-DOS namespace.

It works well if no munging is necessary. However, you may see this:

F:\dir a*

 Volume in drive F is s2/dist/X11
 Directory of F:\

ARCH                       05-26-95   1:01a
ACM-4~YX GZ        971,391 06-02-95  11:02p
ARENA    TAR       604,160 05-19-95   9:43p
ARENA~D0 GZ        530,468 05-22-95   8:35p

instead of

leisner@compudyne$ ls -d a*
acm-4.7.tar.gz   arch/
arena-96.tar.gz  arena.tar

Most of the time you can figure out what is meant. I've noticed some problems identifying files which are spelled the same way except for the case of some characters. On Unix they're distinct, but DOS has no notion of case in file names (you will have a problem with makefile and Makefile, for instance).

Booting DOSEMU on Linux

You shouldn't do much on your virtual hard disk beyond booting. I found it effective to have a directory ~/dos. My config.sys on the virtual hard disk looks like this:

# make sure we support ems
devicehigh=c:\ems.sys
# the last drive is m, it can range up to z:
# the default is f:
lastdrive=m
FILES=40
SWITCHES=/f
# make a copy of c: drive on l:
install=c:\subst.exe l: c:\
# this is the fun part
# change the concept of c: drive
install=c:\lredir.exe  c: LINUX\fs>{home}\dos

The last few lines are the most interesting. I'm making the virtual hard disk accessible to dosemu through the L: drive. If you want to “lock down” the virtual hard disk, you make the file readonly with the chmod command. Then, continue booting from the user's ~/dos directory (where an autoexec.bat is expected). This means that autoexec.bat is just a regular Linux file. You can edit it with any Linux editor, but you have to remember to put \r at the end of each line (that's a control-M character; in vi do

control-v-m,

in Emacs do control-q-m). In my autoexec.bat I have:

lredir f: linux\fs\${PWD}
lredir e: linux\fs\
set PATH=e:\dos\gnu\bin;e:\dos\c\dos;c:\;c:\bin
f:

The syntax ${...} allows environment variables to be substituted. PWD is the current working directory. Bash doesn't normally export it for you; I explicitly add

export PWD

to my .bashrc file.

I just map the F: drive to my current working directory. This is very convenient, because when I'm working with DOS files on Linux, I can start up DOSEMU wherever I am at the moment.

I map my entire filesystem to E:. This makes almost any file accessible under Linux also accessible under DOSEMU. This includes NFS files.

Some programs have a problem with a redirector, since it acts as a network drive. For these programs, you need to use either partition access, image access or a ram disk.

______________________

Webinar
One Click, Universal Protection: Implementing Centralized Security Policies on Linux Systems

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Learn More

Sponsored by Bit9

Webinar
Linux Backup and Recovery Webinar

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.

Learn More

Sponsored by Storix