DOS ain't dead

I released new versions DRDOS 7.01.7 & 7.01.8

Files with the "org" extension are uncompressed, while the others are.

Here are some changes:

Does not scan LBA drives when dx<80h,
For unsupported functions, 71xx returns ax=7100h again,
Handling interrupts 0x00 and 0x06 (division by zero and invalid opcode) as in FreeDos.

You can download it from here:
https://megawrzuta.pl/download/252a1cd7d21a0187e9e04a5fbc4dbc86.html

nico7550 can you test this version?

> I released new versions DRDOS 7.01.7 & 7.01.8
>
> Files with the "org" extension are uncompressed, while the others are.
>

Fantastic !

I did not know that anyone was working on new versions.

Question: Do either of them have 'native' FAT32 support
and/or 'native' LFN support ?

---
--
http://glennmcc.org/

Hi, for sure I love to see new version of old kernel, so it's based on EDR-DOS 7.01.08 WIP ?

What kind of tests do you need ?

I'm finishing to integrate Paragon DOS 7.01 in my bootdisk and I will take a look at it.

Hi,
ehhmmm, where to click to download it?
There is only advertisement.

> Hi,
> ehhmmm, where to click to download it?
> There is only advertisement.

Click the 'Pobierz plik' button.

English translation... 'download file'

---
--
http://glennmcc.org/

> What kind of tests do you need ?

Booting on real hardware with multiple drives. It would be useful to test individual system functions (checking the operation of interrupts - 21h, 2Fh etc.) in order to detect bugs.

> > What kind of tests do you need ?
>
> Booting on real hardware with multiple drives. It would be useful to test
> individual system functions (checking the operation of interrupts - 21h,
> 2Fh etc.) in order to detect bugs.

Sadly, I give old my old computers to a local computer club in order to make room in the house. I'm using 86Box for some years and I'm relly happy with it.

But I will test it for sure. Can you give some info about the compression process (did you remove the loader at the begining of the file to turn it into an exe, patch it a lot, compress it and reinject the loader to turn it back to sys as Mercury127 did with his IOPACK suite of tools based on aPACK) ?

> But I will test it for sure. Can you give some info about the compression
> process (did you remove the loader at the begining of the file to turn it
> into an exe, patch it a lot, compress it and reinject the loader to turn it
> back to sys as Mercury127 did with his IOPACK suite of tools based on
> aPACK) ?

Not exactly, but I used the aPACK and UPX programs for the BIOS and DOS parts respectively and some tricks.

Love you are bringing back the EDR-DOS project!


> I released new versions DRDOS 7.01.7 & 7.01.8
>
> Files with the "org" extension are uncompressed, while the others are.
>
> Here are some changes:
>
> Does not scan LBA drives when dx<80h,
> For unsupported functions, 71xx returns ax=7100h again,
> Handling interrupts 0x00 and 0x06 (division by zero and invalid opcode) as
> in FreeDos.
>
> You can download it from here:
> https://megawrzuta.pl/download/252a1cd7d21a0187e9e04a5fbc4dbc86.html
>
> nico7550 can you test this version?

---
Visit my personal blog at https://www.javiergutierrezchamorro.com

Here is another improved version of EDR-DOS. Now the interrupt vectors saved at startup are again at the fixed address 0070h:0100h.

There is also MS.COM (Memory Statistics) at the request of nico7550.

https://megawrzuta.pl/download/e7c2a5ace1d02143ea0c64ac15b49135.html

> Here is another improved version of EDR-DOS. Now the interrupt vectors
> saved at startup are again at the fixed address 0070h:0100h.
>
> There is also MS.COM (Memory Statistics) at the request of nico7550.
>
> https://megawrzuta.pl/download/e7c2a5ace1d02143ea0c64ac15b49135.html

Hi,

Thanks for this update

Should the behaviour be different when using the compressed ot the uncompressed version ?

Why working on .7 instead of only .8 ?

Thanks for the MS tools it's great, small and a lot of info, can I ask one thing please:
can the default scren be the summary screen (last screen) and a switch to have the details screen instead of all screen at once ? (you can also take a look to the memory tools source by Japheth (EMSSTAT, XMSSTAT and MEMSTAT) if you want to add more stuff ? Maybe produce a lightweigh version also ? With only a summary scren) Anyway great I will use MS now.

Hi CandyMan. Can you upload the sourcecode or some diff?
I have been messing around DRDos source, mostly to add a few options to make the booting process and command com less verbose, and I'd love to see what you did.

> Hi CandyMan. Can you upload the sourcecode or some diff?
> I have been messing around DRDos source, mostly to add a few options to
> make the booting process and command com less verbose, and I'd love to see
> what you did.

Here is the source code:

https://megawrzuta.pl/download/cbef417c0f85eeaed244828d5915c6e5.html

> Why working on .7 instead of only .8 ?
I am curious too.

---
Visit my personal blog at https://www.javiergutierrezchamorro.com

Today I added the INT21.AX33FF.DX0000 function as in RxDOS and FreeeDOS.

I also removed exception handling 0x6 due to some BIOSes using invalid CPU instructions prefixed with 0xF0 (LOCK) generating this exception.

New kernel files are here:
https://megawrzuta.pl/download/61b85729a033da2c534aab878da404c0.html

Here is my final version of EDR-DOS 7.01.8 for now, checked by nico7550.

https://megawrzuta.pl/download/52f9590ae302e4d20b693e7e1b79ca72.html

> Here is my final version of EDR-DOS 7.01.8 for now, checked by nico7550.
>
> https://megawrzuta.pl/download/52f9590ae302e4d20b693e7e1b79ca72.html

The older latest EDR-DOS had a bug when 64-bit seek (int 21h function 7142h) was called on redirector handles. DOS should either return an error then, or try to pass it to the dosemu2 extension service int 2Fh function 11C2h/1142h (as my seekext TSR does). Perhaps you can include a fix to that?

---
l

> The older latest EDR-DOS had a bug when 64-bit seek (int 21h function
> 7142h) was called on redirector handles. DOS should either return an error
> then, or try to pass it to the dosemu2 extension service int 2Fh function
> 11C2h/1142h (as
> my
> seekext TSR does). Perhaps you can include a fix to that?

Maybe we can fix this bug together. I don't want to spoil what I have.

Is what I changed enough? Should I add anything else?

> Is what I changed enough? Should I add anything else?

The problem is the calls to redir_dhndl_offer, on line 128 (of the 2011-07-21 WIP release) / label f7142_handle_ok as well as on line 335 / label f71a6_handle_ok.

Those branch into file redir.a86 line 125:

redir_dhndl_offer:
;================
; The FDOS has called this hook to see if we are operating on an MSNET drive.
; We return if we are not, or stay and process function here if we are
        test    es:byte ptr DHNDL_WATTR+1[bx],DHAT_REMOTE/100h
         jnz    redir_dhndl_accept
        ret
redir_dhndl_accept:

This eventually branches to line 263 / label redir_accept:

redir_accept:
;============
; We have decided to accept an FDOS function.
; Note by this time the functions have been validated as legal
        mov     file_attrib,16h         ; default search attribs to all
        pop     si                      ; discard the near return address
        mov     si,2[bp]                ; SI -> parameter block
        mov     si,ds:[si]              ; fdos code number
        add     si,si                   ; make it a word offset
        jmp     cs:redir_tbl-(39h*WORD)[si]     ; call the relevant function

It appears that the "fdos code number" is uninitialised (0). Perhaps the pointer expected in word [bp + 2] is uninitialised, too, it also reads as zero here when entered from the 7142h code.

This causes the table dispatch to jump to line 1537 of file funcs.fdo, below label fdos_select. For me, this happens to load a zero into AX and to then branch to fdos_select30, which is a retn instruction. This returns to pcmif.a86 line 292, after the label int21_e60. As AL is zero, this sets the application's AL to zero too.


The proper initialisation of the parameter block and FDOS code number appears to happen in fdos_entry, line 41 in file funcs.fdo. For example, disk.a86 line 676 label func40 calls the fdos_handle function, at line 723 in the same file, which chains to fdos_crit line 121 in file support.a86, which calls fdos_nocrit line 177 same file, which finally calls fdos_entry. Finally, the function 40h dispatches to file funcs.fdo function fdos_write (line 829), which calls vfy_dhndl_ptr and then redir_dhndl_offer.

The FD_FUNC field of fdos_data is populated by function set_retry, then fdos_nocrit passes the offset of fdos_data to fdos_entry which finally uses this code to read the parameter block and store some of it on the stack:

;==========
fdos_entry:                     ; FDOS module entry point
;==========
;       On Entry:
;               DS:DX -> parameter block
;       On exit:
;               AX = BX = return code
;               (DS/ES corrupted)
;       entry:  DS:DX = argument
;
;       exit:   AX,BX = return code

        mov     si,dx
        lodsw                           ; AX = FDOS number
        sub     ax,39h                  ; base it at zero
         jc     fd_error                ; stop if too low
        cmp     ax,FDOS_MAX             ; check if function in range
         jae    fd_error                ; yes, continue

        push    ds                      ; save parameter segment
        push    dx                      ; save parameter offset
        push    ax                      ; save sub-function
        mov     bp,sp                   ; SS:BP -> working variables
        mov     bx,ax
        add     bx,ax
        add     bx,ax
        call    fdos_tbl[bx]

The redir_dhndl_offer function reads word [bp + 2] which is the DX pushed by fdos_entry.

All this to say that redir_dhndl_offer should not be called from lfn.asm at any point, because it does not set up the FDOS stack frame and data structures. Both calls of this should go away.

However, you do not need most of the code that you copied from seekext. The call to vfy_dhndl_ptr_AX_call already sets up ES:BX -> the SFT entry. You can copy this line from the redir_dhndl_offer function to check for redirector SFTs:

         test    es:byte ptr DHNDL_WATTR+1[bx],DHAT_REMOTE/100h

Then branch to a part that sets DI to the passed BX value, and call the int 2Fh functions 11C2h and 1142h as you do already. I'm not quite sure how to pass errors back to the interrupt 21h dispatcher but you seem to have the correct code already in your attempt:

_iret_CF:
         jc     f71_error
        jmp     return_AX_CLC

(Just the label name is not accurate here, because this is not an IRET handler as such.)

The use of redir_dhndl_offer in f71a6_handle_ok is equally wrong. dosemu2 also has an extension function for this, at int 2Fh function 11A6h.

Additionally, the two checks for DHAT_DEV also seem wrong. They appear to return to the interrupt 21h dispatcher without properly setting up error codes, and neither do they fill in either of the passed buffers. (For comparison, in file funcs.fdo the label lseek_dev at line 1051 makes sure to return a new seek position of 0000_0000h for device handles, so presumably function 7142h should also zero the output buffer when called on a device.)

---
l

I don't think I can make these changes alone. I'm not that familiar with the DOS kernel.

> I don't think I can make these changes alone. I'm not that familiar with
> the DOS kernel.

I can prepare a patch later.

I tested MSWindows 95 (on pcjs) and a device handle works a little differently than on EDR-DOS:

* Function 42h allows to seek anywhere, as if the device is a file of length zero.

* Function 71A6h returns with CY set (even if input was NC, that is not "CF unchanged"), AX=7100h.

---
l

> > I don't think I can make these changes alone. I'm not that familiar with
> > the DOS kernel.
>
> I can prepare a patch later.
>
> I tested MSWindows 95 (on pcjs) and a device handle works a little
> differently than on EDR-DOS:
>
> * Function 42h allows to seek anywhere, as if the device is a file of
> length zero.
>
> * Function 71A6h returns with CY set (even if input was NC, that is not "CF
> unchanged"), AX=7100h.

Running function 71A6h on a file on a redirector file system (Phantom 3.0) MSW 95 also appears to return CY, AX=7100h.

---
l

>
> I can prepare a patch later.
>

Thanks for your commitment and help.

PS: I noticed that you are also working on the RxDOS kernel. Is it stable?

> >
> > I can prepare a patch later.
> >
>
> Thanks for your commitment and help.

I took the opportunity to create an EDR-DOS repo on our server, at https://hg.pushbx.org/ecm/edrdos (I interpret the new CP/M and derivatives license agreement as of 2022-07-07 as including EDR-DOS, so it should be fine to host it. This license agreement is in the file license.htm in the repo's root directory.)

I added one patch to COMMAND that was needed to build with OpenWatcom 1.9 (from a DOS host system, running in dosemu2) fixing a bug.

I fixed the redirector support for functions 7142h and 71A6h, both to support the dosemu2 extensions and to never crash on a redirector handle. (If the extensions are not supported, 7142h returns an error code of CY, ax=0001h and 71A6h an error code of CY, ax=7100h (like MSWindows).)

Further, I modified both the old-style function 42h and 7142h to work on device handles in the same way as MSWindows, allowing to seek as if the device was an empty file. I also changed it so function 71A6h returns CY, ax=7100h on a device handle.

> PS: I noticed that you are also working on the RxDOS kernel. Is it stable?

No, far from it. And I'm not technically working on it currently. Haven't in a long time. You can view the current state in the repo: https://hg.pushbx.org/ecm/rxdos-7.2x/

I prefer contributing to the FreeDOS kernel now. I also use it for most of my developments (primarily the lDebug debugger).

---
l

> I released new versions DRDOS 7.01.7 & 7.01.8
>

Question...

What ever happened to Udo ?

---
--
http://glennmcc.org/

Thanks for making these changes. My most important fix is the one below (last two lines posted - in "disk.asm"). Without it, the system freezes on my computer with grub4dos.

        push    cx
        push    si
        pushx   <es,di,dx>
        mov     ah,ROS_LBAPARAM         ; get extended drive parameters
        lea     si,int13ex_para         ; DS:SI -> drive parameter buffer
        int_____DISK_INT
        popx    <dx,di,es>
         jc     equip_type_nolba        ; error, assume standard FDD
        test    word ptr 2[si],4        ; removable drive?
         jnz    equip_type_nolba        ; no
        cmp     dl,80h                  ; Hard Disk? - CandyMan
         jb     equip_type_nolba        ; no - CandyMan


> Thanks for making these changes. My most important fix is the one below
> (last two lines posted - in "disk.asm"). Without it, the system freezes on
> my computer with grub4dos.

If you allow it, I want to add your changes to my repo. I already downloaded the source archive you uploaded earlier:

> Here is the source code:
>
> https://megawrzuta.pl/download/cbef417c0f85eeaed244828d5915c6e5.html

Other than what you quoted here I am also interested in the other changes you mentioned:

> Files with the "org" extension are uncompressed, while the others are.
>
> Here are some changes:
>
> Does not scan LBA drives when dx<80h,
> For unsupported functions, 71xx returns ax=7100h again,
> Handling interrupts 0x00 and 0x06 (division by zero and invalid opcode) as in FreeDos.

and

> Not exactly, but I used the aPACK and UPX programs for the BIOS and DOS parts respectively and some tricks.

and

> Here is another improved version of EDR-DOS. Now the interrupt vectors saved at startup are again at the fixed address 0070h:0100h.

and

> Today I added the INT21.AX33FF.DX0000 function as in RxDOS and FreeeDOS.
>
> I also removed exception handling 0x6 due to some BIOSes using invalid CPU instructions prefixed with 0xF0 (LOCK) generating this exception.

Did you actually not use the EDR-DOS packer to compress your kernel files? https://pushbx.org/ecm/download/edrdos/pack100.zip and https://pushbx.org/ecm/download/edrdos/pack101.zip

---
l

> Did you actually not use the EDR-DOS packer to compress your kernel files?

I used aPACK, UPX and FASM for compression.

My actual code:
https://megawrzuta.pl/download/535349ee2e5dbc3a2d9afc8bc2330325.html

By the way, I noticed that the 714E/714F function in EDR-DOS doesn't seem to work. After running Dos Navigator 2 (DN2 for Win32) using HX dos extender only directories are visible (no files).

> > Did you actually not use the EDR-DOS packer to compress your kernel
> files?
>
> I used aPACK, UPX and FASM for compression.
>
> My actual code:
> https://megawrzuta.pl/download/535349ee2e5dbc3a2d9afc8bc2330325.html

Thanks, I will look into this later.

> By the way, I noticed that the 714E/714F function in EDR-DOS doesn't seem
> to work. After running Dos Navigator 2 (DN2 for Win32) using HX dos
> extender only directories are visible (no files).

Can you upload the exact files you're using? If I can reproduce this bug I may be able to fix it.

---
l

> > By the way, I noticed that the 714E/714F function in EDR-DOS doesn't
> seem
> > to work. After running Dos Navigator 2 (DN2 for Win32) using HX dos
> > extender only directories are visible (no files).
>
> Can you upload the exact files you're using? If I can reproduce this bug I
> may be able to fix it.

Also, the 7Z archiver started with the *.* mask only sees directories.
I don't know if it's the fault of DOS or the dos extender.

Below are the programs I use:
https://megawrzuta.pl/download/400807cf0f611833d8248747468acd74.html

What do you think about adding to EDR-DOS and maybe to FreeDOS an extended Exec() function with variants with for example bit 6 of the AL register set (Int21.AX=4B40, Int21.AX=4B41 etc.) to run the program with the line command longer than 127 bytes? The long command line would be copied into the program environment and would be available under the name CMDLINE as the 4DOS interpreter does. It annoys me that it's so short.

> What do you think about adding to EDR-DOS and maybe to FreeDOS an extended
> Exec() function with variants with for example bit 6 of the AL register set
> (Int21.AX=4B40, Int21.AX=4B41 etc.) to run the program with the line
> command longer than 127 bytes? The long command line would be copied into
> the program environment and would be available under the name CMDLINE as
> the 4DOS interpreter does. It annoys me that it's so short.

It's unnecessary to add new DOS function(s) for this -- there's already a "standard" way to do it. Check the byte value at PSP:80h (the number of characters in the command-line string) and if it's at least 7Eh then look for a CMDLINE environment variable. If the CMDLINE variable doesn't exist then 7Eh is the actual size of the command-line string.

Just as a cautionary note, you shouldn't just automatically look for a CMDLINE environment variable since the user can set that environment variable called CMDLINE to anything they want that has nothing to do with the command-line. You should only use it if the value at PSP:80h is >= 7Eh.

BTW this also works in at least some versions of the Windows command-line shell.

Thanks for the exhaustive explanation. Who asks not stray.

> > Did you actually not use the EDR-DOS packer to compress your kernel
> files?
>
> I used aPACK, UPX and FASM for compression.

Do you want to share scripts or descriptions for this too? Your latest sources only seem to add the load-fix.inc file as a part that seems related to compression.


> My actual code:
> https://megawrzuta.pl/download/535349ee2e5dbc3a2d9afc8bc2330325.html

I have some questions:

Why do you want to clear only 12h bytes at 0:500h rather than 20h bytes?

Can you describe the failure without your disk.asm change not to do something with diskette units?

Why did you change the colour offset? It seems like 24, 25, 26 points after the CON device header and its "COLOUR" signature while you subtract 6. So it actually uses the signature as data.

I don't think unsupported subfunctions of a partially supported int 21h service 71h function should return 7100h.

Both FreeDOS and RxDOS do not check for DX being zero for function 33FFh. I did call it like that in callver as well as in comcom32 but that is just to harden the check on whether it is supported.

Finally, what name (if any) do you want me to enter into the repository for changes I pick from your patches?

---
l

> > > By the way, I noticed that the 714E/714F function in EDR-DOS doesn't
> > seem
> > > to work. After running Dos Navigator 2 (DN2 for Win32) using HX dos
> > > extender only directories are visible (no files).
> >
> > Can you upload the exact files you're using? If I can reproduce this bug
> I
> > may be able to fix it.
>
> Also, the 7Z archiver started with the *.* mask only sees directories.
> I don't know if it's the fault of DOS or the dos extender.
>
> Below are the programs I use:
> https://megawrzuta.pl/download/400807cf0f611833d8248747468acd74.html

Can you list the exact commands or actions that I can do to reproduce the errors, please?

---
l

> Can you list the exact commands or actions that I can do to reproduce the
> errors, please?

Also, I haven't used it in a long time so I'm unsure what setup (if any) the HX extender needs in order to run MSWindows programs.

---
l

>1. Why do you want to clear only 12h bytes at 0:500h rather than 20h bytes?

>2. Can you describe the failure without your disk.asm change not to do something with diskette units?

>3. Why did you change the colour offset? It seems like 24, 25, 26 points after the CON device header and its "COLOUR" signature while you subtract 6. So it actually uses the signature as data.

>4. I don't think unsupported subfunctions of a partially supported int 21h service 71h function should return 7100h.

>5. Finally, what name (if any) do you want me to enter into the repository for changes I pick from your patches?

>6. Also, I haven't used it in a long time so I'm unsure what setup (if any) the HX extender needs in order to run MSWindows programs.

>7. Can you list the exact commands or actions that I can do to reproduce the errors, please?

1. I did it for my own use. On my boot disk, I use a different kernel loader and store interrupt vectors 13h and 15h Linux/GRUB4DOS at address 0:0512 for later transfer to UMB memory and back after Int19h. Data at this address was probably used only by GWBasic.

2. I don't remember now, it was 3 years ago. I'm using a little Linux and GRUB4DOS to run DOS because I don't have a floppy drive anymore. The disk drive is emulated and is somewhere in memory above 1MB. Without this fix, it just freezes.

3. I did it so that the DOS interrupts were stored at a fixed address 0070h:0100h

4. Some programs (7zip launched with the command to unpack the archive using HX-DOS) only understand the code 7100h. When the code 0001h is returned, they assume that the file/directory cannot be created and abort without executing short file name function (39h).

5. You can use any name (e.g. CandyMan fix).

6. HX configuration: any XMS driver and C:\HX\BIN in the PATH environment variable and running HXLDR32.EXE resident

7. Programs to reproduce the error: just run DN.EXE or 7Z a -mx Archive.7Z *.*

The way it compresses the kernel:
https://megawrzuta.pl/download/c3100b23f1dc691db9e9e9b693d256d4.html

> >1. Why do you want to clear only 12h bytes at 0:500h rather than 20h
> bytes?
>
> >2. Can you describe the failure without your disk.asm change not to do
> something with diskette units?
>
> >3. Why did you change the colour offset? It seems like 24, 25, 26 points
> after the CON device header and its "COLOUR" signature while you subtract
> 6. So it actually uses the signature as data.
>
> >4. I don't think unsupported subfunctions of a partially supported int 21h
> service 71h function should return 7100h.
>
> >5. Finally, what name (if any) do you want me to enter into the repository
> for changes I pick from your patches?
>
> >6. Also, I haven't used it in a long time so I'm unsure what setup (if
> any) the HX extender needs in order to run MSWindows programs.
>
> >7. Can you list the exact commands or actions that I can do to reproduce
> the errors, please?
>
> 1. I did it for my own use. On my boot disk, I use a different kernel
> loader and store interrupt vectors 13h and 15h Linux/GRUB4DOS at address
> 0:0512 for later transfer to UMB memory and back after Int19h. Data at this
> address was probably used only by GWBasic.

Okay, I can do that. I don't think this patch will do any harm.

> 2. I don't remember now, it was 3 years ago. I'm using a little Linux and
> GRUB4DOS to run DOS because I don't have a floppy drive anymore. The disk
> drive is emulated and is somewhere in memory above 1MB. Without this fix,
> it just freezes.

All right.

> 3. I did it so that the DOS interrupts were stored at a fixed address
> 0070h:0100h

Oh, I missed that you also commented out the db "COLOUR" signature itself. This is the wrong way to achieve the correct address for vecSave. In my repo I already did it the right way.

> 4. Some programs (7zip launched with the command to unpack the archive
> using HX-DOS) only understand the code 7100h. When the code 0001h is
> returned, they assume that the file/directory cannot be created and abort
> without executing short file name function (39h).

Does this apply to all uses of error code 0001h in lfn.asm or only some? At least function 7142h with cl > 2 should return error 0001h I think.

> 5. You can use any name (e.g. CandyMan fix).

Okay.

> 6. HX configuration: any XMS driver and C:\HX\BIN in the PATH environment
> variable and running HXLDR32.EXE resident
>
> 7. Programs to reproduce the error: just run DN.EXE or 7Z a -mx Archive.7Z
> *.*

Thanks. I may have time to try this later, probably within the week.

> The way it compresses the kernel:
> https://megawrzuta.pl/download/c3100b23f1dc691db9e9e9b693d256d4.html

Interesting, thanks! I do have some comments:

Can you describe fix-bio's use of virtual and load dword / store dword? I am not used to FASM specific directives. The load and store access and change data that is already assembled? file is like NASM incbin? virtual assembles into a space that is discarded afterwards, just for access with load?

The registers don't all need to be preserved by fix-bio. es, di, si, bx, and cx are probably not used by the EDR-DOS load protocol. dl, ds, bp, ss, sp may be used.

I don't like the use of the memory at 004F0h for saving the registers. It would be better to use the stack or at least 005F0h.

The fix-bio expects the compressed file to be < 64 KiB. Fair enough.

The mov word [cs:0], ax could be replaced by directly storing a 16-bit immediate to the memory, instead of going through AX. Hmm, may actually be the same length of instruction bytes.

The retf in fix-bio can be replaced by a jmp far immediate because the kernel must be loaded at 70h:0 (currently).

What are the first 8 bytes supposed to be in the upx-compressed drdos.com that are replaced by fix-dos? I think you could add load directives to check that those instructions match what you expect.

In the batch file you use "vasm". Is that a typo for "fasm"?

What versions of apack and upx do you use?

---
l

> Interesting, thanks! I do have some comments:
>
> Can you describe fix-bio's use of virtual and load dword / store dword? I
> am not used to FASM specific directives. The load and store access and
> change data that is already assembled? file is like NASM incbin? virtual
> assembles into a space that is discarded afterwards, just for access with
> load?
>
> The registers don't all need to be preserved by fix-bio. es, di, si, bx,
> and cx are probably not used by the EDR-DOS load protocol. dl, ds, bp, ss,
> sp may be used.
>
> I don't like the use of the memory at 004F0h for saving the registers. It
> would be better to use the stack or at least 005F0h.
>
> The fix-bio expects the compressed file to be < 64 KiB. Fair enough.
>
> The mov word [cs:0], ax could be replaced by directly storing
> a 16-bit immediate to the memory, instead of going through AX. Hmm, may
> actually be the same length of instruction bytes.
>
> The retf in fix-bio can be replaced by a jmp far immediate because the
> kernel must be loaded at 70h:0 (currently).
>
> What are the first 8 bytes supposed to be in the upx-compressed drdos.com
> that are replaced by fix-dos? I think you could add load directives to
> check that those instructions match what you expect.
>
> In the batch file you use "vasm". Is that a typo for "fasm"?
>
> What versions of apack and upx do you use?

In fix-bio.asm I add a small procedure at the end of dosbio.sys.
In the virtual block, I set a new jump instruction for this procedure and then copy the previous compressed jump instruction to drbio.sys (4 bytes) to be able to recreate it and run the unpacking procedure to the address CS-10h:IP+100h
The "file" directive works exactly like the "incbin" in nasm, but you can also specify the start and size of the loaded file block.

The memory at address 4F0h (16-bytes) is for the user and I took advantage of that.

The first 8 bytes of compressed drdos.com should be:

CMP SP,constant
JA Above
INT 20h
Above:

"vasm" is my replacement for "fasm" run by the D3X dos extender.

I use aPACK v1.0 and UPX v3.96.

You didn't reply about the int 71h function error codes. Apart from the compression support and the colour signature removal, this is the only patch of yours I didn't add to my repo yet.

> In fix-bio.asm I add a small procedure at the end of dosbio.sys.
> In the virtual block, I set a new jump instruction for this procedure and
> then copy the previous compressed jump instruction to drbio.sys (4 bytes)
> to be able to recreate it and run the unpacking procedure to the address
> CS-10h:IP+100h

Yes, I do think 3 bytes would suffice though. A near jump instruction is 3 bytes.

> The "file" directive works exactly like the "incbin" in nasm, but you can
> also specify the start and size of the loaded file block.

Actually, NASM's incbin does have that too: https://www.nasm.us/xdoc/2.16.01/html/nasmdoc3.html#section-3.2.3 It might be a little known feature however, as I didn't know about it when I originally wrote my bootimg FATFS format script.

Unlike this, NASM really does not have fasm's load and store directives. Those are more powerful, even though 3 of your fix files' uses of them can be replaced by using incbin with various parameters. (The replacement of the last byte of the compressed drdos.com by a pop ax can only be done with incbin by knowing the size of the file beforehand. NASM has no way of detecting the size without including the file data up to and including the last byte.)

Writing of which, how does the far address of the DOS kernel file end up on the stack so that by modifying the last byte of the compressed drdos.com to a pop ax and retf you have it branch where you want?

Oh, I just noticed that your DOS compression is exactly copied from pack101. Except that shipped with upx 1.25d. I was about to write, I would implement this with an lDebug script. (The pack100/pack101 debug scripts do work with lDebug, though I assume they were written for DR-DOS Debug.)

I found out how the address gets on the stack: https://hg.pushbx.org/ecm/edrdos/rev/c2e9bc4c642b#l27.50

> The memory at address 4F0h (16-bytes) is for the user and I took advantage
> of that.

Oh, yes, you're correct. The interrupt list calls it "intra-application communication area": http://fd.lod.bz/rbil/memory/other/m004000f0.html
I didn't know that and assumed it may be used by the ROM-BIOS.

> The first 8 bytes of compressed drdos.com should be:
>
> CMP SP,constant
> JA Above
> INT 20h
> Above:
>
> "vasm" is my replacement for "fasm" run by the D3X dos extender.

Is there a need for that here? Why did you use one once and the other once, rather than twice the same?

> I use aPACK v1.0 and UPX v3.96.

Thanks!

---
l

> You didn't reply about the int 71h function error codes. Apart from the
> compression support and the colour signature removal, this is the only
> patch of yours I didn't add to my repo yet.
>
I didn't answer because I'm not entirely sure. Perhaps it is enough for HX-DOS to understand the return code 0001h as it understands 7100h.

> Is there a need for that here? Why did you use one once and the other once,
> rather than twice the same?
>

I just forgot to change. When I run under Win64 I can't use "vasm", and when I don't have HX loaded in DOS I can't use "fasm".

I now know, though not exactly, why the system freezes. After loading DRDOS.SYS (also uncompressed) it jumps to the wrong place for me and after the RET instruction to the next one. However, I don't know exactly how to fix it. The only correct solution was the amendment I proposed. I used Dark Debugger to trace the boot process.

> Also, the 7Z archiver started with the *.* mask only sees directories.
> I don't know if it's the fault of DOS or the dos extender.

I believe that the source of this problem, or a part of it, may be that EDR-DOS's functions 714Eh, 714Fh, and 71A1h do not really allow concurrent searches. It may require some amount of work to fix this.

What happens now is 7-Zip finds a directory, recurses into it, and tries to start a new search. After finishing processing the directory, it closes the Find handle and tries to continue the search of the original working directory. This is corrupted from the recursive search.

Another part is with 7z a ..\t.7z *.* nothing is found, but I believe this is intentional on the part of 7-Zip. (All files and directories in my test directory do not contain dots in their names.) It does mean that you may have mistakenly specified the *.* mask when it should be *. (The DOS functions are documented as finding everything with either, but 7-Zip also applies its own pattern matching.)

---
l

>
> By the way, I noticed that the 714E/714F function in EDR-DOS doesn't seem
> to work. After running Dos Navigator 2 (DN2 for Win32) using HX dos
> extender only directories are visible (no files).

I was confused by your wording here, you wrote "after running DN2" but I think you meant *when* running DN2 then in the application only directories are visible.

If I am correct in that then I fixed that bug. It also affected 7-Zip which wants to get all files for a * pattern, but EDR-DOS's 714Eh/714Fh exposed the DOSism that *.* is required to get all files and * only finds files without a dot in their name. 7-Zip, however, does globbing itself to postprocess the DOS found files and it interprets *.* as meaning "only files with a dot in their name", unlike DOS.

> Also, the 7Z archiver started with the *.* mask only sees
> directories. I don't know if it's the fault of DOS or the
> dos extender.

Please test with my build that will be updated later today (in 22h from now), at https://pushbx.org/ecm/download/old/edrdos/20230820.zip

---
l

> Please test with my build that will be updated later today (in 22h from
> now), at https://pushbx.org/ecm/download/old/edrdos/20230820.zip

I just tested your latest version. Everything seems to work perfectly. Thanks a lot.

I have one question like this. Why have I never been able to build an EDR-DOS kernel by running BAT files on a system other than FreeDos? RASM86.EXE seems to use FCB functions that have been deprecated from M$DOS and are only in FreeDos. Do the FCB functions work in EDR-DOS? I ask because when I try to build an EDR-DOS kernel in a system other than FreeDos (also in EDR-DOS itself) I get the message: "Sector not found reading drive ?:" - ? - drive number here (C drive when building on C, and drive Y when building on RAMDISK Y).

> > Please test with my build that will be updated later today (in 22h from
> > now), at https://pushbx.org/ecm/download/old/edrdos/20230820.zip
>
> I just tested your latest version. Everything seems to work perfectly.
> Thanks a lot.

Good to hear.

> I have one question like this. Why have I never been able to build an
> EDR-DOS kernel by running BAT files on a system other than FreeDos?
> RASM86.EXE seems to use FCB functions that have been deprecated from M$DOS
> and are only in FreeDos.

According to my understanding, MS-DOS 7.10+ disables FCB I/O on FAT32 FS. I did not test that yet but the interrupt list hints at this. Perhaps it would work better on a FAT12 or FAT16 FS?

> Do the FCB functions work in EDR-DOS? I ask
> because when I try to build an EDR-DOS kernel in a system other than
> FreeDos (also in EDR-DOS itself) I get the message: "Sector not found
> reading drive ?:" - ? - drive number here (C drive when building on C, and
> drive Y when building on RAMDISK Y).

I did not test this yet. I may get around to it within the week, though I would first test it in dosemu2 (MFS-redirected DOS drives). That may yield a different result than operating on a (to DOS) local FAT FS.

I found three FreeDOS bugs in the FCB directory search support while considering your post, though: https://github.com/FDOS/kernel/issues/112

---
l

> I have one question like this. Why have I never been able to build an
> EDR-DOS kernel by running BAT files on a system other than FreeDos?
> RASM86.EXE seems to use FCB functions that have been deprecated from M$DOS
> and are only in FreeDos. Do the FCB functions work in EDR-DOS? I ask
> because when I try to build an EDR-DOS kernel in a system other than
> FreeDos (also in EDR-DOS itself) I get the message: "Sector not found
> reading drive ?:" - ? - drive number here (C drive when building on C, and
> drive Y when building on RAMDISK Y).

I just updated my EDR-DOS repo on the local machine (running a recent dosemu2 with KVM, on a Debian amd64 desktop system) and booted my EDR-DOS + dosemu2 diskette image. Using the mak.bat file wouldn't work because of the required SET /E switch (FreeCOM specific), but instructing dosemu2 with the explicit lredir -f i: ... command, then setting the OpenWatcom variables (from C:\WATCOM) then running the make.bat in each directory, I get the exact same result files as on FreeDOS.

Actually, I noticed that to non-interactively overwrite a file using COPY, FreeCOM requires the COPY switch /Y, while EDR-DOS command defaults to overwriting. I added a /Y switch to EDR-DOS, which is a no-op by default. (It does override /C if both are used.) This makes my modified make.bat files fully work on both shells.

---
l

> I just updated my EDR-DOS repo on the local machine (running a recent
> dosemu2 with KVM, on a Debian amd64 desktop system) and booted my EDR-DOS +
> dosemu2 diskette image. Using the mak.bat file wouldn't work
> because of the required SET /E switch (FreeCOM specific), but instructing
> dosemu2 with the explicit lredir -f i: ... command, then
> setting the OpenWatcom variables (from C:\WATCOM) then running the
> make.bat in each directory, I get the exact same result files
> as on FreeDOS.

I also built a HDD image like so: (This is a small FAT32 image, which is why a recent mtools is required. I downloaded it from GNU and built using ./configure then make commands. I did this to test that EDR-DOS works with a small FAT32 image.)

~/proj/edrdos$ hg clone repo selbau
updating to branch default
168 files updated, 0 files merged, 0 files removed, 0 files unresolved
~/proj/edrdos$ nasm -I ../lmacros/ ../bootimg/bootimg.asm -D_BPE=32 -D_ERROR_SMALL32=0 -D_MBR -D_ALIGNDATA -D_MEDIAID=0F8h -o selbau.img -D_SPI=256_000 -D_SPF=128 -D_SPC=16 -D_CHS_HEADS=16 -D_CHS_SECTORS=32 -D_PAYLOADFILE=::empty
../bootimg/bootimg.asm:472: warning: Too many FAT sectors specified (16384 entries (128 sectors), 15985 needed (125 sectors)) [-w+user]
../bootimg/bootimg.asm:523: warning: FAT would be detected as FAT16 (15983 = 3E6Fh clusters) [-w+user]
~/proj/mtools/mtools-4.0.43/mcopy -i selbau.img@@512s selbau/* ::

Then run dosemu2 with the HDD image configuration: -I "disk { hdimage /home/ecm/proj/edrdos/selbau.img }". Again set the OpenWatcom 1.9 variables for C:\WATCOM, then run each make.bat. (I think it will use the FreeDOS subst.exe that I have in C:\bin.)

After building, copy the files back to the host like so:

~/proj/edrdos$ mkdir selbau.res
~/proj/edrdos$ ~/proj/mtools/mtools-4.0.43/mcopy -i selbau.img@@512s ::drbio/bin/drbio.sys ::drdos/bin/drdos.sys ::command/bin/command.com selbau.res/

Finally, compare the files using bdiff like so:

~/proj/edrdos/dl$ for file in drbio/bin/drbio.sys drdos/bin/drdos.sys command/bin/command.com; do ls -l "../selbau.res/${file##*/}"; bdiff "../selbau.res/${file##*/}" "../repo/$file"; done
-rw-r--r-- 1 ecm ecm 35495 Aug 29 18:22 ../selbau.res/drbio.sys
File: ../selbau.res/drbio.sys
Files are identical.
-rw-r--r-- 1 ecm ecm 36973 Aug 29 18:22 ../selbau.res/drdos.sys
File: ../selbau.res/drdos.sys
Files are identical.
-rw-r--r-- 1 ecm ecm 63521 Aug 29 18:22 ../selbau.res/command.com
File: ../selbau.res/command.com
Files are identical.

---
l

Did the same test using a normal (non-small) FAT32 file system, filling it initially with a 120 MB file to avoid the source files ending up with low cluster numbers:

~/proj/edrdos$ nasm -I ../lmacros/ ../bootimg/bootimg.asm -D_BPE=32 -D_ERROR_SMALL32=1 -D_MBR -D_ALIGNDATA -D_MEDIAID=0F8h -o selbau.img -D_SPI=256_000 -D_SPF=2560 -D_SPC=1 -D_CHS_HEADS=16 -D_CHS_SECTORS=32 -D_PAYLOADFILE=::fill,120_000_000,0,zeroes.bin
../bootimg/bootimg.asm:472: warning: Too many FAT sectors specified (327680 entries (2560 sectors), 250866 needed (1960 sectors)) [-w+user]

---
l

And another test:

~/proj/edrdos$ nasm -I ../lmacros/ ../bootimg/bootimg.asm -D_BPE=32 -D_ERROR_SMALL32=1 -D_MBR -D_ALIGNDATA -D_MEDIAID=0F8h -o selbau.img -D_SPI=256_000 -D_SPF=2560 -D_SPC=1 -D_CHS_HEADS=16 -D_CHS_SECTORS=32 -D_PAYLOADFILE=::fill,120_000_000,0,zeroes.bin,::chdir,build
../bootimg/bootimg.asm:472: warning: Too many FAT sectors specified (327680 entries (2560 sectors), 250866 needed (1960 sectors)) [-w+user]
~/proj/edrdos$ ~/proj/mtools/mtools-4.0.43/mcopy -i selbau.img@@512s selbau/* ::build
~/proj/edrdos$ ~/proj/mtools/mtools-4.0.43/mcopy -i selbau.img@@512s ::build/drbio/bin/drbio.sys ::build/drdos/bin/drdos.sys ::build/command/bin/command.com selbau.res/

This puts the directory entries for the drbio, drdos, and command subdirectories into a directory cluster beyond the first 64 Kilo-binary clusters, too.

---
l