[net.micro.pc] DOS 2.0 Device Driver Quirks

romkey@MIT-CSR@sri-unix.UUCP (08/30/83)

From:  John L. Romkey <romkey@MIT-CSR>

I've been working on a block device driver for DOS 2.0 for a while
now, and I thought people might be interested in some of the things
I've run up against.

One has already been mentioned: system calls on 2.0 are NOT reentrant.
It's a real disaster to do a DOS call from a device driver because it
blows away the stack of the original system call which caused the
device to be called in the first place.  On the other hand, it appears
that a device can call DOS when DOS tells it to initialize itself.  I
haven't really checked this out too much, but it appears to work.

Ioctls are real fun.  The first problem is with BPB's.  These are
descriptions of the disk: how many sectors it has, the size of the
FAT, etc.  When DOS thinks that the disk has been changed, it tells
the driver to make a new BPB for it.  It does this before issuing read
or write requests to the driver.  It also does it before doing
ioctl's.  This might seem quite innocent at first, but I was using the
ioctl call before there was even any disk there, so no BPB could be
made.  The solution was to construct a valid-looking, phony BPB.

The real nastiness with ioctl's is that the unit number that the
driver gets passed is always 0.  MS-DOS figures out what device driver
to call and then tells it that the ioctl was done on unit 0 of that
device, no matter what unit you really said it was done on.  I would
claim that this is really a BUG.

The last problem that I've really hit is that there is no DOS utility
to construct an empty MS-DOS file structure on a disk.  Format only
seems to understand floppies.  It seems to bypass the device drivers
and call BIOS.  This is useful for laying out the actual tracks on the
disk, but they really should have provided something with the
functionality of the Unix mkfs.

Flaming about MS-DOS is fun.  Writing device drivers for it isn't
always.

	- John Romkey
	  romkey@mit-csr