DOS ain't dead

Support for LASTDRIVE=27 up to LASTDRIVE=32 (Developers)

posted by ecm  , Düsseldorf, Germany, 27.09.2025, 19:42

DR-DOS and MS-DOS v7 introduced an expanded LASTDRIVE directive in dconfig.sys/config.sys that allows to create a CDS array with more than 26 entries, ie drive letters beyond Z:. According to the ASCII encoding, the "letters" above Z: are [:, \:, ]:, ^:, _:, and `:.

I added EARLYLASTDRIVE and LASTDRIVE support of the high letters to the lDOS kernel recently: https://hg.pushbx.org/ecm/msdos4/rev/1ed1e77d75b2

During testing I found that DEVLOAD already supports the new drive letters. It allcapses its command line tail alphabetically (rather than forcing the bit mask 20h set or clear) and subtracts capital 'A' to find the drive number. Then it checks that the number is below the CDS size from the List of Lists.

lDebug and its Extensions for lDebug also supported the new drive letters already. They all capitalise alphabetically, subtract 'A', and check for the number being < 32.

https://hg.pushbx.org/ecm/ldebug/file/863794199328/source/eld/dosdrive.asm#l155

https://hg.pushbx.org/ecm/ldebug/file/863794199328/source/eld/dosspace.asm#l808

https://hg.pushbx.org/ecm/ldebug/file/863794199328/source/eld/dpb.asm#l796

SRDISK, the reSizeable RAM Disk, was easy to adapt to the new drive letters: https://hg.pushbx.org/ecm/srdisk/rev/bbdae817d9a0

FreeCOM partially worked, but failed for some cases. The pull request was merged today: https://github.com/FDOS/freecom/pull/180

dosemu2 was easy to patch too, but they rejected my pull request for now: https://github.com/dosemu2/dosemu2/pull/2602 If you want to see support for this for dosemu2's lredir, please do weigh in there!

MS-DOS v7.10 supports LASTDRIVE=31, but fails to access the drive `: for LASTDRIVE=32. I found the patch site in the binary msdos code segment by studying lMS-DOS sources, the macro2.nas DriveFromText function. It sets the bit mask 20h unconditionally then subtracts 60h to get the 1-based drive number, but this doesn't get 20h for ` as needed, instead resulting in 00h which is rejected. Like my lDOS (source text) patch I prepared a binary patch that fixes the `: access, which can be installed by running ldebug /t /cytestlett.sld from the file here: https://pushbx.org/ecm/test/20250926.3/

qa
s ptr ri27p l 3 B8 00 31
r vC := srs
if (src) then goto :doslow
s ptr ri27p l 10 2E FF 2E
if (! src) then goto :eof
r vC := word [ri27s : word [srs:sro + 3] + 2]
:doslow
s vC:0 FFFF AD 0C 20 2C 60 75
if (src != 1) then goto :eof
u srs:sro l 6

a 100
 ; xor cx, cx
 ; xchg cx, [2C]
 ; jcxz 100
 ; mov ah, 49
 ; int 21
 xor bx, bx
 mov cx, [32]
 .
r vF := aao
a
 mov ah, 3E
 int 21
 inc bx
 loop (vF)
 mov ax, 3100
 mov dx, 18
 int 21
 .
r v0 := aao
a
 lodsw
 cmp al, (#'a')
 .
r v1 := aao
a
 jb 100
 sub al, 20
 .
r v2 := aao
a
 sub al, 40
 retf
 .
if (aao > 180) then goto :eof
a v1
 jb (v2)
 .
a srs:sro
 call far (psp):(v0)
 .
g

The resident memory is required to store the patched code, as it doesn't fit in the original spot in the kernel code segment. A proper executable could save some more space and be able to install in the UMA too, but would require replacing all the Script for lDebug scripting with proper code.

Enhanced DR-DOS had a similar problem with redirected drives, which I fixed in https://hg.pushbx.org/ecm/edrdos/rev/8ab6ce75cc58 and offered as a patch to the SvarDOS fork https://github.com/SvarDOS/edrdos/issues/161 In this case it cleared the bit mask 20h unconditionally then subtracted 41h to get a 0-based drive number, which results in -1 for `.

MS-DOS v7.10 appears to only log in HDD partitions or block device units from config.sys up to drive Z:, emitting error messages noting the overflow. EDR-DOS appears to never initialise the new letter CDS entries, so it may install eg devicehigh=srdisk.exe xms for eg drive [: but the CDS isn't set up properly. I may patch this at a later point.

---
l

Complete thread:

• Support for LASTDRIVE=27 up to LASTDRIVE=32 - ecm, 27.09.2025, 19:42 (Developers)