DOS ain't dead

tkchia,

Thank you, that makes more sense. If I understand it correctly, the device driver is compressed except for the unpacker, which should run when DOS calls the device driver init routine.

In that case the attribute word is still in the same location and can be modified by the unpacker installer routine.

It sounds like the comment about OpenDOS above is specific to OpenDOS, and not a general limitation of MS or PC DOS.

> Hello mbbrutman,
>
> > The code you linked looks like it's a UPX device driver for whatever
> > OpenDOS is. (I'm familiar with UPX as a command line program, not as a
> > device driver.)
>
> UPX can apparently compress device drivers for MS-DOS; and the code is
> (part of?) the decompressor stub for device drivers.

yes. UPX can compress device drivers, and even dual .EXE and device drivers.

background: early versions of HIMEM were a dual .EXE and device driver.
you could load it as DEVICE=HIMEM.EXE, but also for command line like
HIMEM /T
would run a regression test. Japeth removed this later on, but this is as HIMEM started.

however dual mode EXE/DRIVER executables could only by compressed by my own, non
public, compression program (EXEPACK). so I (as the original master HIMEM author)
compressed HIMEM.EXE with my proprietary program and published it in this binary form. but nobody else was able to produce the same (compressed) binary.

Bart Oldeman was annoyed by that, 'reengineered' my code and integrated it into UPX.

fine with me.

> Interesting! Is it really as simple as inserting the device driver in the
> chain?

For a character device, it really is as simple as inserting in the chain. It's not trivial, but is pretty simple. It also doesn't work with some Virtual Machines (like DOSBox and its extensions) since their DOS is not really DOS.

BTW, the way to find the device driver chain is to locate the DOS List of Lists and the NUL device header is stored in the LOL (not a pointer to the NUL device header, the actual NUL device header is stored there). NUL is always the first device driver in the chain.

For a block device, you need to do more than just insert the device into the chain. You also need to insert information into other DOS tables as well, including the Drive Parameter Block (DPB) and Current Directory Structure (CDS) tables.

> I suspect some things like DOS telling you your starting unit
> number get missed, so you have to compute that yourself.

Exactly. You need to manually store all the correct information into the various tables (in addition to the device driver chain) which includes pointers back and forth between the various tables.

If you let DOS load the block driver via CONFIG.SYS, it does all of that for you but you also have no control over how DOS assigns the drive letters (and not all DOS's do it the same way).

> I'm also assuming
> that are putting it last (first?) in the chain (the same way that DOS does
> it) so that you don't disturb drive ordering.

No, it really doesn't matter where it ends up in the chain since you have pointers back and forth between the various tables. E.g., in the table that contains information about the drive letters, DOS creates the table the size based on your LASTDRIVE setting (which can be up to 32 entries in MS-DOS 7). If a drive letter is unused, that particular table entry is empty. You can fill in any of the empty entries with your information, which means you can use any unused driver letter you want (as long as LASTDRIVE was set properly). DOS assigns letters from the bottom up, but you don't necessarily need to do it that way if you don't want to.

For some sample code, you can use my USBDRIVE program or the FreeDOS DEVLOAD program.

As with character devices, of course, it doesn't work with VM's like DOSBox but does work with VM's that use a "real" DOS.