DOS ain't dead

> TSR's are actually "easier" to write. While CONFIG.SYS is being processed,
> many of the DOS services that you generally take for granted (even very
> basic things like writing text to the screen, manipulating files, and
> redirection/piping) are limited or non-existent.

I think this assumption is a bit too pessimistic. When a driver is loaded, DOS usually HAS a current PSP - its value is 84xxh for MS-DOS 7.1, for FreeDOS it's 0060h. So file operations are possible, also screen output. What's probably missing, are environment variables.

Here's the test driver ("testdrv.asm") which I used to display the PSP from within a driver. Create it with "jwasm -mz testdrv.asm".



;--- dummy driver which displays the current PSP

        .286
        .model small
        .386

iodat struc
cmdlen  db      ?       ;+ 0:laenge der struktur
unit    db      ?       ;+ 1:
cmd     db      ?       ;+ 2
status  dw      ?       ;+ 3
        db      8 dup (?); reserviert
media   db      ?       ;+ 0d
trans   dd      ?       ;+ 0e
count   dw      ?       ;+ 12   bei init:offset parameterzeile
start   dw      ?       ;+ 14   bei init:segment parameterzeile
drive   db      ?       ;+ 16
iodat ends

        ASSUME DS: _TEXT

_TEXT SEGMENT

        dw 0ffffh
        dw 0ffffh
        dw 8000h                        ;attribute
        dw offset devstrat      ;device strategy
        dw offset devint        ;device interrupt
        db 'TESTDRV$'         ;devicename

befptr  dd 1 dup(?)

devstrat proc far
        mov cs:word ptr[befptr],bx
        mov cs:word ptr[befptr+2],es
        ret
devstrat endp

devint  proc far
        pusha
        push ds
        push es
        lds bx,cs:[befptr]
        mov [bx.iodat.status],8103h
        cmp [bx.iodat.cmd],00
        jnz devi1
        mov [bx.iodat.status],0100h
        mov word ptr [bx+0eh],0000
        mov word ptr [bx+10h],cs
        call main
        lds bx,cs:[befptr]
        mov word ptr [bx+0Eh],0
        mov [bx+10h],cs
devi1:
        pop ds
        pop es
        popa
        ret
devint  endp

dwordout:
        push ax
        shr eax,16
        call wordout
        pop ax
wordout:
        push ax
        mov al,ah
        call byteout
        pop ax
byteout:
        push ax
        shr al,4
        call nibout
        pop ax
nibout:
        and al,0Fh
        add al,30h
        cmp al,'9'
        jbe @F
        add al,7
@@:
if 1
        mov dl,al
        mov ah,02h
        int 21h
else
        mov ah,0Eh
        push bx
        xor bx,bx
        int 10h
        pop bx
endif
        ret

stringout:
        mov ah,09
        int 21h
        ret
charout:
        mov ah,02
        mov dl,al
        int 21h
        ret

dLF  db 13,10,'$'
dPSP db "PSP=$"

main PROC NEAR
        push cs
        pop ds
        mov dx,offset dPSP
        call stringout
        mov ah,51h
        int 21h
        mov ax,bx
        call wordout
        mov dx,offset dLF
        call stringout
        mov cx,8
        mov es,bx
        xor bx,bx
nextline:
        push cx
        mov cx,16
nextbyte:
        push cx
        mov al,es:[bx]
        inc bx
        call byteout
        mov al,' '
        call charout
        pop cx
        loop nextbyte
        mov dx,offset dLF
        call stringout
        pop cx
        loop nextline
        ret
main endp

exeint proc
        call main
        mov ax,4C00h
        int 21h
exeint endp

_TEXT ENDS

        .stack 200h

        END exeint


---
MS-DOS forever!

> So it's not that dire, they just want you to presumably be able to actually
> unpack it to its original form (esp. for using newer UPX with better
> compression).
Thank you for your comments and others for their private messages re drivers. I have updated what will be RJDUMP v2.00 (with SYS driver support) so that it will display if a driver has been compressed with UPX, e.g:

RJDUMP v2.00a - (c)Copyright 1996-2010 Richard L. James

Filename                                              'xmgr.sys'
DOS File Size                                         0FA4h  ( 4004d )

DOS SYS Header
Offset Address of Next Driver                         FFFFh  ( 65535d )
Segment Address of Next Driver                        FFFFh  ( 65535d )
DeviceName                                            ???????? [UPX compressed]
Device attributes          1010000000000000b          A000h  ( 40960d )
   Bit 15  =  1    Device driver type                 Character
   Bit 14  =  0    Supports functions 03h and 0Ch?    No
   Bit 13  =  1    Supports function 10h?             Yes
   Bit 12  =  0    Reserved
   Bit 11  =  0    Supports functions ODh and OEh?    No
[verbose snip]
   Bit  3  =  0    Current clock$ device?             No
   Bit  2  =  0    Current NUL driver?                No
   Bit  1  =  0    Current standard output driver?    No
   Bit  0  =  0    Current standard output driver?    No
Offset address of strategy routine [UPX compressed]   000Ah  ( 10d )
Offset address of Interrupt routine                   0BEDh  ( 3053d )

The above is however "work in progress", so be aware the released version may change how information is displayed (comments/requests for features welcome). I may NOT however include UPX EXE detection in this version (for the sake of time) even though the EXE decoding does recognize other EXE headers. e.g. TLINK.

In addition I have also included support in RJDUMP that will be helpful for those of us interested writing SYS drivers/experimenting with combined drivers, e.g. I have a personal long term interest in the possibilities of a combined driver and can see that functionality as useful, e.g. for ROMOS. I have also now added code to flag if reserved bits are set, e.g:

RJDUMP v2.00a - (c)Copyright 1996-2010 Richard L. James

Filename                                              'block1.sys'
DOS File Size                                         1070h  ( 4208d )

DOS SYS Header
Offset Address of Next Driver                         FFFFh  ( 65535d )
Segment Address of Next Driver                        FFFFh  ( 65535d )
Device attributes          0010100011000000b          28C0h  ( 10432d )
   Bit 15  =  0    Device driver type                 Block
   Bit 14  =  0    Supports functions 03h and 0Ch?    No
   Bit 13  =  1    Non-IBM format?                    Yes
   Bit 12  =  0    Reserved
   Bit 11  =  1    Supports functions 0Dh and 0Eh?    Yes
[verbose snip]
   Bit  7  =  1    Reserved                           [NON-ZERO!]
   Bit  6  =  1    Supports functions 17h and 18h?    Yes
[verbose snip]
   Bit  1  =  0    Supports devices larger than 32Mb?  No
   Bit  0  =  0    Reserved
Offset address of strategy routine                    0057h  ( 87d )
Offset address of Interrupt routine                   0066h  ( 102d )

Note: I still plan/wish to reference some additional resources so that the information displayed is as complete as I can make it before a public release, in other words the reserved bits above are according to limited references that I have so far referenced as I have also been busy elsewhere.

Welcome Bret.

> > TSR's are actually "easier" to write.
Basic device drivers are very easy to write in the same way that basic TSR's are. The only real difference between the two is historically there has been better support for creating TSR's, e.g. Borland's keep routines have a lot to answer for making it far too easy for anyone to easily create "bloated" TSR's.

> > While CONFIG.SYS is being processed,
> > many of the DOS services that you generally take for granted (even very
> > basic things like writing text to the screen, manipulating files, and
> > redirection/piping) are limited or non-existent.
>
> I think this assumption is a bit too pessimistic.
I fully agree. Indeed if the exact opposite was true then it wouldn't be possible for SYS "drivers" like wrapper.sys to load TSR's, would it?

> What's probably missing, are environment variables.
I seem to remember that in some DOS situations there may be environment variables as well, e.g. WINDIR/TMP/TEMP (set via IO.SYS) and even COMSPEC if SHELL= has already been used? I suspect it may depend on the DOS version used.

From distant memory I seem to remember that SHELL= was supposed to be the last entry in a CONFIG.SYS (as I use now limited CONFIG.SYS files I may be remembering this wrong). Still I guessed that other people probably put SHELL earlier in CONFIG.SYS files before other drivers and did a quick search returned an example in the second "MS-DOS 6+" CONFIG.SYS example on Wikipedia which shows the SHELL line before COUNTRY.SYS.

Japheth:

Let me explain what I do in my programs, and you (or somebody) can tell me whether it's possible to do this directly (or some equivalent with perhaps a different syntax) in a CONFIG.SYS driver.

For text output, I always use INT 21.40. If it is "regular" text, I use handle 1 (STDOUT), and I use handle 2 (STDERR) if it is an "error" message. This allows the user, if they want to, to suppress the "regular" text (including the Copyright message, if they don't want to see my name plastered on their screen all the time) by redirecting the output to NUL, or redirecting/teeing the output to a printer or a file in some unusual circumstance. Yet, this still sends any possible "error" messages directly to the screen, e.g.:

Program [options] > NUL

I also use input redirection. Some of my programs may require LOTS of input options, far too many to fit in the 126 character limit of a traditional command-line tail. For example, in the USB keyboard driver the user may want to remap virtually the entire keyboard, which requires the input of many, many parameters. To allow for a "long" command-line tail, I use input redirection, e.g.:

Program < "C:\Option Files\Program.Options"

(I personally don't normally use LFN, but simply did that to exaggerate the point).

While CONFIG.SYS is being processed, DOS is "incomplete". Documentation I have seen states that the only DOS functions that are available while CONFIG.SYS is being processed are 01-0Ch (basic console I/O stuff) and 30h (Get DOS version). DOS-based file/device manipulation, either using FCB's or handles, is unavailable. It is certainly possible that redirection and piping are available (I've never actually tried it), but I would be very surprised. Exactly what's available during CONFIG.SYS processing may also vary depending on the manufacturer and version of DOS, but I don't know that for sure, either.

I realize there are other ways of accomplishing some of the same things, e.g. with additional command-line options, but that is not the point. The point is that a TSR has access to many "nice" DOS functions that can make it "easier" to write a program, especially a complicated program, than a device driver has. With a TSR, the programmer has a choice of whether or not to use those "extra" features, but with a device driver there is no choice.

> While CONFIG.SYS is being processed, DOS is "incomplete". Documentation I
> have seen states that the only DOS functions that are available while
> CONFIG.SYS is being processed are 01-0Ch (basic console I/O stuff) and 30h
> (Get DOS version). DOS-based file/device manipulation, either using FCB's
> or handles, is unavailable.

This might be true for some old DOS versions.

> It is certainly possible that redirection and
> piping are available (I've never actually tried it), but I would be very
> surprised.

I think no, it isn't available. AFAIR this feature is implemented by COMMAND.COM, which isn't even loaded at that point. So I also doubt that redirection will work if your TSRs are loaded with CONFIG.SYS's "INSTALL=" command.

---
MS-DOS forever!

If anyone is interested, here is an example of exe driver (for config.sys) written in Turbo Pascal. The actual driver is in pasdev.pas. It converts text to morse code.

> This might be true for some old DOS versions.
I believe a lot of this will be true for versions prior to DOS version 4 (/3.2). It would also appear that earlier DR DOS Plus didn't implement the Int 21h 44xxh IOCTL side of things, however there are no similar comment re DOS internal IOCTL, e.g. Int 2F/AX=122Bh etc.

As I noted earlier on this forum the PSP was introduced in DOS version 3., obviously as you know SYS drivers start at org 0h so don't have their own PSP which contains "helpful" things like environment, fcb, command-line parameters etc.

As Jaspeth points out there is a the DOS PSP which should also be obtainable via either Int 21h ah=61h or Int 21h ah=52h.

However you are right things are easier from a TSR side. Indeed don't also forget there is the far easier (later DOS) option of coding an EXE device driver like EMM386 which more TSR than true SYS device driver. When I wrote an EXE driver sometime back I used Michael Tischer/(PC Intern)'s EXESYS.ASM as a reference point and that was at least a fairly straight forward exercise then. Certainly I would recommend PC Intern as a really good book to have on the bookshelf - my now very worn copy is from 1993 (there were newer versions). I would however agree with the comments on the Amazon link above, e.g. in my own book the block device table has the heading "header of the character driver". Still in technical books this detailed these types of error will always creep in.
Note: it isn't the only book I have on which covers device drivers in detail but it is the one to hand and has 40 pages (out of 1356) on device drivers and 44 pages on TSR's, memory management/PMode are separate sections again.

Also noted elsewhere I did also write some SYS drivers a long time ago. Indeed the reason I have been adding SYS driver support to RJDUMP is I have something else that I've been working on not exactly a WRAPPER.SYS replacement but it could provide similar if I choose to use it that way.

Indeed I am planning to use the release of RJDUMP to "test" some of my other work further but this time with device drivers as compared to say bootsectors which is what I was testing my work with prior to getting taking this step to the left. Still the long and the short of it is I'm doing a lot of chicken before the egg coding at the moment, so I do know where you are coming from and am actually interested in finding solutions to the apparently impossible.

Still I would like to directly apologize re my earlier ill informed thoughts re combined drivers as I was forgetting about some of the problems that exist in the middle of DOS loading having worked around some chicken and the egg situations elsewhere (e.g. prior to DOS loading or after DOS has loaded) but not yet in the middle of DOS loading as required here. So apologies for that!

> If anyone is interested, here is an example of
> exe driver (for
> config.sys) written in Turbo Pascal. The actual driver is in pasdev.pas. It
> converts text to morse code.

Thanks for sharing. Note: The second EXE.ZIP contained within exevsys.zip contains a second copy of the source code rather than compiled EXE's. I have successfully compiled them all with TP but noted TPPATCH or replacement CRT is required on PASDEV.EXE due to its use of CRT.PAS for the sound/delay procedures.

Also good to see someone else correcting books like PC Intern which clearly says "It is not possible to write device drivers in a high level language". :)

> > If anyone is interested, here is an example of
> > exe driver
> (for
> > config.sys) written in Turbo Pascal. The actual driver is in pasdev.pas.
> It
> > converts text to morse code.
>
> Thanks for sharing.
Secondary thanks also for providing another EXE device driver of the type of which I had not yet implemented for RJDUMP [EDIT: see update below]. In short for anyone interested you can detect an EXE driver by looking for the SYS header ($FFFFFFFF) after the EXE image ("Paragraphs in header" field value * 16). If using HIEW you can just hit [F8] and then [F4] to go there rather than [F8] then [F5] as you would do if interested in the EXE entry.

Likewise in the case of HIEW, you can use [CTRL] + [F5] change the base which is important as SYS drivers start at org 0h. e.g. In the case of PASDEV.EXE if viewing with HIEW you would for example first do [CTRL] + [F4] and then do [CTRL]+[F5] to change the base, type -B0 which will enable you to easily view view PASDEV as SYS driver in HIEW rather than an EXE. I hope this basic info is helpful for anyone interested in using this high-level example to learn.


[EDIT]
I have now added support for identifying/displaying EXE device headers to RJDUMP and have successfully tested it with many EXE based drivers already (e.g. JEMM, JLOAD for example). I hope to be finish coding/testing an initial public version of RJDUMP later on this week. In the meantime for anyone following this thread who may be studying PASDEV as a high-level example, the following partial RJDUMP of PASDEV.EXE may be helpful to you:

RJDUMP v2.00a - (c)Copyright 1996-2010 Richard L. James

Filename                                              'pasdev.exe'
DOS File Size                                         1240h  ( 4672d )

EXE Signature                                         5A4Dh  ( 'MZ' )
Load Image Size                                       FF90h  ( 65424d )
Relocation Table entry count                          0022h  ( 34d )
Relocation Table address                              001Ch  ( 28d )
Size of header record      (in paragraphs)            000Bh  ( 11d )
Minimum Memory Requirement (in paragraphs)            00E6h  ( 230d )
Maximum Memory Requirement (in paragraphs)            00E6h  ( 230d )
File load checksum                                    0000h  ( 0d )
Overlay Number                                        0000h  ( 0d )

Initial Stack Segment  (SS:SP)                  013Fh:0400h
Program Entry Point    (CS:IP)                  0000h:02C8h

DOS relocation table entries

0000:0021  0000:0085  0000:00C5  0000:00ED  0000:00F8  0000:00FD  0000:0106
0000:0117  0000:0137  0000:01EC  0000:01F1  0000:01F4  0000:0235  0000:023E
0000:024B  0000:025C  0000:0274  0000:02AF  0000:02CB  0000:02D0  0000:02D9
0000:0307  0000:030F  0032:0009  0032:0024  0032:0037  0032:013B  0096:0001
0096:011B  0096:02B5  0096:0676  0096:0691  0096:06A7  0096:06C6

Secondary device driver header detected

DOS SYS Header
Offset Address of Next Driver                         FFFFh  ( 65535d )
Segment Address of Next Driver                        FFFFh  ( 65535d )
DeviceName                                            'MORSE   '
Device attributes          1110000000000000b          E000h  ( 57344d )
   Bit 15  =  1    Device driver type                 Character
   Bit 14  =  1    Supports functions 03h and 0Ch?    Yes
   Bit 13  =  1    Supports function 10h?             Yes
   Bit 12  =  0    Reserved                           
   Bit 11  =  0    Supports functions ODh and OEh?    No
   Bit 10  =  0    Reserved                           
   Bit  9  =  0    Reserved                           
   Bit  8  =  0    Reserved                           
   Bit  7  =  0    Reserved                           
   Bit  6  =  0    Reserved                           
   Bit  5  =  0    Reserved                           
   Bit  4  =  0    Reserved                           
   Bit  3  =  0    Current clock$ device?             No
   Bit  2  =  0    Current NUL driver?                No
   Bit  1  =  0    Current standard output driver?    No
   Bit  0  =  0    Current standard output driver?    No
Offset address of strategy routine                    0015h  ( 21d )
Offset address of Interrupt routine                   0268h  ( 616d )


> This might be true for some old DOS versions.

My reference source for this is "DOS Programmers Reference", second edition, by Terry Dettmann, published in 1989. It claims to be accurate through MS-DOS 4.0, the latest version of DOS at the time the book was written. Given what I know about Microsoft, that's probably not something they would have changed in later versions of MS-DOS. However, it's also possible they might have added additional support for some INT 21h functions when they added support for dual EXE/Driver files (I think that was MS-DOS 5.0, but am not positive). I've never seen any kind of reference for that, though.

Anyway, it's certainly a possible point of concern if you write device drivers, but is something you don't even need to worry about with TSR's.

> > This might be true for some old DOS versions.
>
> My reference source for this is "DOS Programmers Reference", second
> edition, by Terry Dettmann, published in 1989. It claims to be accurate
> through MS-DOS 4.0, the latest version of DOS at the time the book was
> written. Given what I know about Microsoft, that's probably not something
> they would have changed in later versions of MS-DOS. ...

Never believe what your read (even in print, even if the source is MS - indeed, especially not if the source is Microsoft, or paraphrased from MS like so many bad textbooks !

In fact, starting with DOS 2.0 (where DOS device drivers and config.sys were introduced), the DOS int 21h API is loaded and (almost) properly initialised before the drivers in Config.sys are processed. Despite what MS ever said, all int 21h functions should be available.

With two caveats : - first, some functions make little to no sense in the context of loading drivers and shouldn't (normally) be used - but see WRAPPER.SYS for how one can arrange to run DOS programs from a driver without virtually any limits.

- secondly, there have been bugs in every versions of MS-DOS (cf. the "almost" in the above paragraph) which make some functions not work, unless one works around the bugs. See also discussions of my own "fixwrap.sys" in this forum.

---
Ninho

> snippety-snip... Just an detail which you may or may not remember
>
> >> The reason is that an FFFFFFFFh value denotes the LAST driver in the
> DOS
> >> driver list.

> Actually, when loading a driver, MS-DOS (others ?) check only the
> segment part (high word) of this double word for the special value
> FFFFh. This behaviour (by design?) will allow us to make a dual device
> driver/ dot com executable, using the first two bytes as a short jump over
> the rest of the driver header. Of course, the init routine for the 'sys'
> specific part of the init code should replace FFFF at offset zero before
> giving back control to the DOS system initialisation routines...
>

With the aid of RJDUMP and a single example of such 2 in 1 SYS file. I have established that there exists a multiple SYS device file format (at least on MS-DOS) which is also supported by LOADSYS. This explains why MS-DOS at the least does NOT expect the "Offset To Next Driver" value and indeed "Segment Address of Next Driver" to always be ZERO as sometimes they shouldn't be.

To explain, lets look the following RJDUMP snippet from such a driver:

Offset Address of Next Driver                         0012h  ( 18d )
Segment Address of Next Driver                        0000h  ( 0d )


Firstly note that neither value are FFFFh as most people would expect them to be. So effectively the logic here would "appear" to be that if "Segment Address of Next Driver" is set to 0000h and "Offset Address of Next Driver" is non-zero then DOS expects "Offset Address of Next Driver" to point to a another header *within* the same file. Indeed in this example case the value 00012h tells us that a second SYS header "follows" the first header at offset 0012h or 18 in decimal, all of which makes perfect sense since the SYS header structure is 18 bytes long. For those of you unfamiliar with it, here it is:


    OfsAddrOfNextDriver : Word;                    {2 bytes+}
    SegAddrOfNextDriver : Word;                    {2 bytes+}
    DeviceAttributes    : Word;                    {2 bytes+}
    OfsAddrOfStrategy   : Word;                    {2 bytes+}
    OfsAddrOfInterrupt  : Word;                    {2 bytes+}
    DeviceName          : Array[1..8] of Char;     {8 bytes=18 bytes!}


From this I thus now strongly suspect that many multiple SYS files can be combined/daisy chained together with the list ending with $FFFF $FFFF (as happens in memory). I haven't had the time or interest to test this yet but am providing the information here to enable others to investigate. It will also be interesting to see if this SYS logic is "correct" on non MS-DOS's.

Note: I also haven't seen *any* documentation on this and have just worked it out based on a 1 such device driver that I have/Ninho's earlier comments.
I am thus providing this technical information here for those of you who may be interested in testing further. Any info you find out would be appreciated.

Below is a complete RJDUMP for the driver that I have here after I updated RJDUMP to deal with the above logic. Again as you can see all of the driver information (which I haven't altered) makes perfect sense when viewed in this way:

DOS SYS Header
Offset Address of Next Driver                         0012h  ( 18d )
Segment Address of Next Driver                        0000h  ( 0d )
DeviceName                                            'COM5    '
Device attributes          1000100000000000b          8800h  ( 34816d )
   Bit 15  =  1    Device driver type                 Character
   Bit 14  =  0    Supports functions 03h and 0Ch?    No
   Bit 13  =  0    Supports function 10h?             No
   Bit 12  =  0    Reserved                           
   Bit 11  =  1    Supports functions ODh and OEh?    Yes
   Bit 10  =  0    Reserved                           
   Bit  9  =  0    Reserved                           
   Bit  8  =  0    Reserved                           
   Bit  7  =  0    Reserved                           
   Bit  6  =  0    Reserved                           
   Bit  5  =  0    Reserved                           
   Bit  4  =  0    Reserved                           
   Bit  3  =  0    Current clock$ device?             No
   Bit  2  =  0    Current NUL driver?                No
   Bit  1  =  0    Current standard output driver?    No
   Bit  0  =  0    Current standard output driver?    No
Offset address of strategy routine                    0056h  ( 86d )
Offset address of Interrupt routine                   0061h  ( 97d )

DOS SYS Header
Offset Address of Next Driver                         FFFFh  ( 65535d )
Segment Address of Next Driver                        FFFFh  ( 65535d )
DeviceName                                            'COM6    '
Device attributes          1000100000000000b          8800h  ( 34816d )
   Bit 15  =  1    Device driver type                 Character
   Bit 14  =  0    Supports functions 03h and 0Ch?    No
   Bit 13  =  0    Supports function 10h?             No
   Bit 12  =  0    Reserved                           
   Bit 11  =  1    Supports functions ODh and OEh?    Yes
   Bit 10  =  0    Reserved                           
   Bit  9  =  0    Reserved                           
   Bit  8  =  0    Reserved                           
   Bit  7  =  0    Reserved                           
   Bit  6  =  0    Reserved                           
   Bit  5  =  0    Reserved                           
   Bit  4  =  0    Reserved                           
   Bit  3  =  0    Current clock$ device?             No
   Bit  2  =  0    Current NUL driver?                No
   Bit  1  =  0    Current standard output driver?    No
   Bit  0  =  0    Current standard output driver?    No
Offset address of strategy routine                    0056h  ( 86d )
Offset address of Interrupt routine                   0078h  ( 120d )


Note: The "shared" common strategy routine but separate Interrupt handlers with the first driver pointing to the second and the second starting $FFFF $FFFF thus ending the chain.

> Hm this is used very often by users
> So you can just reboot and

But that's exactly how things should NOT be (see shot)



> choose different menu in config.sys
> With JEMM quick boot feature it's done in 5 seconds ;)

I don't use those

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

Just in case someone still cares about that:

DOS only checks the offset part, and never will look at the "next device header" field's segment. The offset indeed needs to be -1 to denote the last device header in an actual device chain, or the last device header in a multi-header device driver file. The trick is that (compatible) DOS doesn't care about the values until after the init request is issued to the device. This means you can fill the whole dword with garbage in the assembler and then initialize the first word with -1 (or the (near) pointer to your next header) in your init handler of the strategy or interrupt callback.

The FreeDOS kernel sources that I have examined again just now (2036 or maybe 2038) do handle this correctly, as do my current sources. (Which I wrote after I had examined MS-DOS 6.x and 7.x behaviour.)

The only thing to note on multi-header device drivers additionally is that DOS doesn't care about the segment field for these either. So all headers are in the same segment. (I.e. the first 64 KiB of the executable's image, no matter whether the .COM or .EXE file format is used.)

As for UPX, of course you can't use it on .COM/device driver executables unless it fully supported them. (As it does support .EXE/device driver executables. If it detects them correctly. It requires the whole dword to be initialized with -1 or something.) Even if you were to trick UPX into compressing the executable, it would do so either as .COM or as device driver, making the executable crash if invoked as the other format. This would make patching of the UPX header/decompressor necessary. I solved the problem by including a fake UPX header that reliably makes UPX output an error, i.e. protects the kernel/debugger from well-intentioned users that think UPX can handle everything.

---
l

> Just in case someone still cares about that:
> DOS only checks the offset part,
Thank you for your additional useful comments which also link up with a private email discussion with Jack after this thread. Most helpful input - cheers!

> Even if you were to trick UPX into compressing the executable,
Which it should be noted for anyone following / interested by this discussion would for completeness include recalculating UPX's CRC's etc.

> This would make patching of the UPX header/decompressor necessary.
Which it should also be noted is officially not allowed in the UPX license :(

> protects the kernel/debugger from well-intentioned users that
> think UPX can handle everything.
So nicely put :)

> Thank you for your additional useful comments which also link up with a
> private email discussion with Jack after this thread. Most helpful input -
> cheers!

[Insert generic rant about private email discussion referencing Eric Auer.] Pleased to hear my knowledge might be useful to someone (and that someone even read this old thread).

> > Even if you were to trick UPX into compressing the executable,
> Which it should be noted for anyone following / interested by this
> discussion would for completeness include recalculating UPX's CRC's etc.

Not necessarily. If the file would be accepted as .COM file (or device driver, but more unlikely because that requires the -1 dword) by UPX, you could just compress it as that without any patching necessary - but losing device driver functionality. The patching is probably aimed at UPX's decompressor only anyway, so that it would work for both formats. (See EDR-DOS stuff.)

> > This would make patching of the UPX header/decompressor necessary.
> Which it should also be noted is officially not allowed in the UPX license
> :(

Oh. Might tell that to Udo Kuhnt, his EDR-DOS BIO.SYS compressor does patch it a little. (Of course on the user's system, using a DEBUG script. How anticipatory.) The DOS.SYS uses unpatched UPX .COM file compression though, which works because the DOS.SYS file is loaded by BIO.SYS so this loader has been modified to load the file like a .COM file.

> > protects the kernel/debugger from well-intentioned users that
> > think UPX can handle everything.
> So nicely put :)

I didn't want to insult anyone, what!

---
l