|
|
|
|
|
|
|
|
by Marty Leisner
When machines come from a factory with DOS pre-installed on them, the hard disks are normally arranged so the whole disk is the C: drive. This is very inflexible, even if you only want to run DOS, and unbearable if you also want to run other operating systems. PC partition tables support the following configurations (with a total of 4 allowed):
In order to run Linux, you typically have to repartition your disk, which is often a good idea whatever operating system you run for the following reasons on (DOS or UNIX):
When you want to repartition your disk, standard procedure used to be:
This may have worked with a few meg to back up, but now PCs normally come with 200 Mb installed in a Microsoft Windows system, with little documentation about what's important and what's not. There is a very clever utility called fips, written by Arno Schaefer, schaefer@rbg.informatik.th-darmstadt.de. It is kept on sunsite.unc.edu in /pub/Linux/system/Install/fips12.zip.
fips non-destructively shrinks your primary partition, leaving all your files in place. You run defrag (an MS-DOS program) to pack all the files into contiguous sectors and then fips to shrink your primary partition.
You can then reboot and create an extended DOS partition (with the DOS fdisk program), and use Linux to create Linux partitions (with the Linux fdisk program). fips is a wonderful tool that solves a very real problem. Please read the instructions carefully before using it; any tool which writes your partition table, like fdisk, should be used with caution.
N.B.: Be very careful using fdisk. Don't do anything destructive to your media (i.e mkfs or format from DOS) until you are sure DOS and Linux agree on where the partitions are. I've noticed very ``unnice'' features with the DOS fdisk program---it read the free space as 100 Mb (which was correct), but when I allowed it to make a partition with all the free space, it made a 350 Mb partition (very naughty!)
Extended partitions are a way around the 4 partition limit on a physical disk. An extended partition can serve as a container for more partitions, which can be DOS, Linux (native or swap) or any other type. Remember, non-DOS partitions need to be made in a non-DOS version of fdisk. Extended partitions are handy for generating more than the 4 partitions normally found. I have never seen a good discussion of adding swap space to a system---a good way is using extended partitions.
Extended partitions are a good idea---for running DOS. Each logical partition in the extended partition is given a letter by DOS (i.e. D:, E: , F:). Each of these drives can then be formatted and used under DOS. I use an application called join, which as of DOS 6 is no longer distributed with DOS, but you can still get a copy via ftp from ftp.microsoft.com in /peropsys/msdos/public/supplmnt/. join essentially allows you to ``mount drives'' so you have a single hierarchical tree (like Linux).
For instance, I might configure a system with drive D: for personal stuff and E: for djgpp, a port of the GNU C compiler to DOS. Then, in my root directory on my C drive I create directories for \marty, \gnu, and in my autoexec.bat, I have:
join d: \marty join e: \gnu
so that I don't have to deal with drive letters. I also join A: to \a, so my floppy disks appears on the tree. But if you do something like this you'll break the DOS format program and almost every DOS install/setup program for commercial software. It seems that they can't deal with anything except A:.
Unfortunately, you can't use join with network drives. More on this later when we talk about DOSEMU.
I found it effective to use loadlin, a DOS-based loader; this has the distinct advantage of always booting a working system before running Linux. My experience with LILO has been if you don't do it right, your system is only useful as a paper weight. In my MS-DOS config.sys, I take advantage of the menus, and the result is shown in Listing 1.
menuitem=dos menuitem=simple.dos menuitem=linux.1.2.8 menuitem=scandisk menudefault=linux.1.2.8,5 [linux.1.2.8] SHELL=C:\loadlin\loadlin.exe \loadlin\zimage.128 root=/dev/hdc2 -v ro [simple.dos] [dos] DEVICE=C:\DOS\HIMEM.SYS DEVICEHIGH=C:\MAGICS20\CDIFINIT.SYS /T:X DEVICEHIGH=C:\MTM\MTMCDAI.SYS /D:MTMIDE01 DEVICEHIGH /L:2,12048 =C:\DOS\SETVER.EXE DOS=HIGH STACKS=9,256 [scandisk] SHELL=c:\dos\scandisk.exe /all /checkonly
I boot Linux with a delay of 5 seconds, the advantage being that the system can always boot DOS and will work in some capacity. I find this preferable to using LILO and modifying the master boot record on your hard disk (if you do anything wrong, you need to boot from floppy to recover).
One can easily select several kernels and/or configurations from the command line. Using loadlin, you have to make a compressed kernel (make zImage), and then put it on a DOS partition. I find this strategy effective even when installing Linux the first time (instead of dealing with a boot and root floppy, the system can boot the kernel with only a root floppy needed). You can easily add to the menu to have several different kernels to boot from. Remember, you can use the rdev utility to build defaults (like the root device) into the kernel.
In your autoexec.bat you can use the strategy:
goto %config% :simple.dos PATH=C:\marty\bin;C:\gnu\bin;C:\dos;C:\ goto end :dos SET SOUND16=C:\MAGICS20 C:\MAGICS20\SNDINIT /b SET BLASTER=A220 I7 D1 T4 C:\DOS\SMARTDRV.EXE 512 512 /C C:\DOS\IMOUSE.COM PROMPT $p$g SET PATH=c:\gnu\bin;C:\MARTY\BIN;C:\WINDOWS;C:\DOS; SET TEMP=C:\DOS JOIN d: \marty JOIN f: \gnu goto end :end
The simple.dos setting is conceptually the same as booting Linux in single user mode. I find it very useful for debugging a DOS system. If you want, you can add config.sys menu entries to boot different kernels, boot Linux in single user mode, boot Linux from floppies, etc.
In the standard Linux kernel configuration, the UMSDOS file system isn't enabled. UMSDOS has a number of major advantages if you need file systems to be shared between Linux and DOS. It retains full Unix semantics, so you don't have to always be handicapped by DOS problems such as:
Using UMSDOS you can take advantage of a file system shared between DOS and Linux, with the appearance of being a Linux file system when you run Linux. If you want files to be portable between MS-DOS and Linux, restrict yourself to DOS filenames (8+3 characters). Don't use links if you want the files to appear under DOS. With a Linux file system, it's easy do things like create ``dot files'', do gzip-r on trees, and create links and backup files. Any file is readable in MS-DOS; however, if you don't conform to the MS-DOS file naming conventions, files are ``munged'' (that is, their names are squeezed to fit within the 8+3 namespace). This munging is similar to what happens in mfs; those who use PC-NFS are probably familiar with this.
When you start running the UMSDOS file systems, remember to run the application called umssync, which creates consistency between the --linux-.--- files and the directory contents. You can have problems if you add or delete files under DOS without Linux knowing about it. Call umssync from /etc/rc.d/rc.local or /etc/rc.d/rc.M after the mount takes place, and this shouldn't be a problem.
I've noticed a problem in UMSDOS files systems---the mount points are owned by root, only writable by root, and the date is the beginning of the epoch. A simple workaround is after mounting, do chown/chmod to the mount points as appropriate (in your /etc/rc.d/rc.local file. Also, I find it useful to occasionally run scandisk from DOS (notice the scandisk target in config.sys).
There is a performance penalty for DOS and UMSDOS file systems compared to normal ext2. The penalty becomes severe if you have several hundred files in a single directory (when you do an ls, get a cup of coffee). What I've noticed is sequential I/O (with a tester called Bonnie) is marginally faster on ext2 than UMSDOS.
But UMSDOS is ideal if you're doing work with DOSEMU. You put DOS files on UMSDOS partitions, and you can easily access them from DOS, DOSEMU or Linux. If they keep within the DOS file system bounds of 8+3 characters, they look the same on both DOS and Linux. UMSDOS partitions provide a big advantage when sharing files with DOS (much more so then the MSDOS file system, since it treats Linux files as Linux files), but performance has to be watched.
DOSEMU can access files in several different ways, which integrate with DOS and Linux in different ways. The methods are:
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).
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.
Extending the above scenario further, we can actually boot from a DOS hard disk using
disk { wholedisk ``/dev/hda'' readonly }
This has a number of advantages---primarily the virtual hard disk does not have to be created and maintained (note the virtual hard disk is only readable within DOSEMU, making maintenance cumbersome). DOSEMU allows you to select the extension for the system files (config.sys and autoexec.bat) either in the configuration file (using EmuSys or EmuBat) or from the environment (using AUTOEXEC and CONFIG). This boot disk isn't writable, so switch to a writable C: drive with lredir.
I typically have a config.sys file for DOSEMU called config.emu. In it I just change the C: drive (from the virtual hard disk) to a ~/dos directory, and have an autoexec.bat file there. I also have links to commonly used DOS programs (i.e. command.com).
Win95 throws some curves into this scheme. I've been using Win95 since the official release and am favorably impressed with it (anything could improve on Windows 3.1 problems). Win95 uses the file MSDOS.SYS to control the boot process as another ASCII configuration file. In order to activate a config.sys menu to either boot DOS or Linux, the following works in MSDOS.SYS:
[Options] Logo=0 BootMulti=1 BootGUI=0 BootDelay=0
In this case, after you run Linux, booting DOSEMU will allow you to run DOS Version 7.
You can also run an older DOS (if this was an upgrade) if you press F4 when it starts booting. But in this case, if you boot Linux and then start up DOSEMU off the DOS hard disk, the boot loader gets hopelessly confused, since it shuffles files like msdos.sys, config.sys, and autoexec.bat between Win95 and an older DOS system, putting the appropriate file in the appropriate place for the appropriate DOS (Win95 config files end in .w40, and older DOS files end in .dos). Obviously, you aren't expected to run DOSEMU under Linux!
I use DOS occasionally, but do a lot of work in MS-DOS since I'm working on DOSEMU and an alpha djgpp. I have found that you can do very flexible things with your partitions through extended partitions, and that Linux treats DOS filesystems quite nicely (especially UMSDOS).
I've found cross-development of MS-DOS applications to be ideal for DOS software development, you can write portable software and try it on Linux---then use Linux compilers to generate .EXE djgpp files and run the djgpp binaries in DOSEMU.
Marty Leisner is a professional programmer for Xerox Corporation who was first exposed to Unix on a PDP 11 running V7. You can reach him at leisner@sdsp.mc.xerox.com
