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?

> Note that I accidentally edited your post rather than replying to
> it. Here's my reply as its own post as it should have been posted.
>
> > Thanks, used the inc bp you proposed, and left in the jump.
>
> You can actually get rid of the inc if you just adjust all the references
> with BP in this function.

Thanks for the hint.

I now have DRBIO.SYS, DRDOS.SYS and COMMAND.COM linked with WLINK, and each has its own makefile.

For COMMAND.COM I had to change the reloading code and the loading of the appended help file, because the code assumed a fixed 512 byte EXE header. Its now variable in that the size of the header is determined by offset 8 of the EXE header itself. I changed COMMAND.COM to behave normally if it is fed with a .BAT file containing LF endings. I by accident created such a file and COMMAND.COM freaked out over it.

Regarding DRBIO.SYS, it should now create default FAT-32 BPBs conformant to MS-DOS / FreeDOS. But the code calculating the FAT size still produces non-optimal results, in that the size of the FATs themself is not respected when calculating it, wasting a few sectors. Unformatted partitions can now be formatted under DR-DOS with an unaltered FreeDOS format.

Note that I accidentally edited your post rather than replying to it. Here's my reply as its own post as it should have been posted.

> Thanks, used the inc bp you proposed, and left in the jump.

You can actually get rid of the inc if you just adjust all the references with BP in this function.

---
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

it anything changed in DR-COMMAND.COM?
Udo's COMMAND.COM can display short filenames in NTVDM(otvdm/msdos.exe) after patching DR-check
but yours shows no file when running `dir/w`

> Looks good to me. Dispatching to either the two-step division or a single one is new to me. I do think you could save code space at the cost of some performance by just dropping the test and jz. Zero divided by CX is always zero.

Thanks, used the inc bp you proposed, and left in the jump.

> > You can convert the code below for Int64 to Int32 and replace the 32-bit
> > registers with 16-bit registers to skip the 32-time loop.
>
> Thanks for the code. I can not convert it one by one, because the DRSYS
> div32 procedure also returns the remainder, but I get the idea...
>
> However, for now I decided to leave the shifting algorithm as it is, mainly
> because it is a code path not often taken, and i want to fix more things
> than I break
>
> The div32 procedure is mainly called with 512 as the divisor (to calculate
> sectors and offsets into the FAT). So 99% of the time, the optimized 16-bit
> shortcut is used, I guess.
>
> The current version is here:
> https://github.com/SvarDOS/edrdos/blob/8fa1acd6576...9fd7f283a9119e3494036ce7/drdos/bdevio.a86#L2029
>
> It should yield correct results (kernel behaves as expected). But perhaps
> someone with more assembly experience might double-check (from div32_full
> on it is the original code).


div32:                                    ; 32-bit division
;--------
; On Entry:
;       32-bit dividend & divisor on stack
;       space for 32-bit quotient & remainder reserved on stack
;       SP-16
; On Exit:
;       32-bit quotient & remainder on stack
;       SP-16
; Modified registers:
;       AX,CX,DX,BP
        mov     bp,sp                   ; base address of temporary variables
        add     bp,2

Twice `inc bp` is cheaper in code space.

  xor     dx,dx
        cmp     10[bp],dx               ; if divisor high != 0 => 32bit div
         jne    div32_full
        mov     cx,8[bp]                ; CX <- divisor low
        mov     2[bp],dx                ; clear remainder high, guaranteed to
                                        ; ...be zero here
        mov     ax,14[bp]               ; AX <- dividend high
        test    ax,ax                   ; if both dividend and divisor are
                                        ; ...16bit, perform one 16bit division
         jz     div16                   ; ...else perform two 16bit divisions
dix2x16:
        div     cx                      ; divide dividend high by divisor low
div16:  mov     6[bp],ax                ; 6[bp] <- quotient high
        mov     ax,12[bp]               ; AX <- dividend low
        div     cx                      ; divide dividend low by divisor low
                                        ; ...DX -> remainder of previous
                                        ; ...      division or zero
        mov     [bp],dx                 ; store remainder low
        mov     4[bp],ax                ; store quotient low
        ret
div32_full:

Looks good to me. Dispatching to either the two-step division or a single one is new to me. I do think you could save code space at the cost of some performance by just dropping the test and jz. Zero divided by CX is always zero.

---
l

> You can convert the code below for Int64 to Int32 and replace the 32-bit
> registers with 16-bit registers to skip the 32-time loop.

Thanks for the code. I can not convert it one by one, because the DRSYS div32 procedure also returns the remainder, but I get the idea...

However, for now I decided to leave the shifting algorithm as it is, mainly because it is a code path not often taken, and i want to fix more things than I break

The div32 procedure is mainly called with 512 as the divisor (to calculate sectors and offsets into the FAT). So 99% of the time, the optimized 16-bit shortcut is used, I guess.

The current version is here:
https://github.com/SvarDOS/edrdos/blob/8fa1acd6576...9fd7f283a9119e3494036ce7/drdos/bdevio.a86#L2029

It should yield correct results (kernel behaves as expected). But perhaps someone with more assembly experience might double-check (from div32_full on it is the original code).

> > I first thought that the xor cx,cx can be eliminated too, by clearing
> the
> > result after the xor dx,dx. But the xor cx,cx leaves the flags in a
> defined
> > state, which the div does not. So I think it is safer to leave this xor
> > cx,cx in.
>
> It probably IS save. Because everytime div32 is used in the source, an
> addition follows that sets the flags anyway. So I will try to further
> optimize this and incorporate your suggestion regarding the two divisions
> on 16-bit divisor.

You can convert the code below for Int64 to Int32 and replace the 32-bit registers with 16-bit registers to skip the 32-time loop.

function ModU(const A,B:Int64):Int64;
assembler;{&FRAME-}{&USES EBX,ESI,EDI}
var
  I:Int64;
  J:Int64;
asm
        MOV     EBX,A
        MOV     EAX,[EBX+0]
        MOV     EDX,[EBX+4]
        MOV     DWORD [I+0],EAX
        MOV     DWORD [I+4],EDX
        MOV     EBX,B
        MOV     ECX,[EBX+4]
        MOV     EBX,[EBX+0]
        MOV     DWORD [J+0],EBX
        MOV     DWORD [J+4],ECX
        MOV     EAX,EBX
        OR      EAX,ECX
        JZ      DivisionByZero
        MOV     EAX,DWORD [I+0]
        TEST    ECX,ECX
        JNZ     @@BigDivisor
        CMP     EDX,EBX
        JAE     @@TwoDivs
        DIV     EBX
        MOV     EAX,EDX
        MOV     EDX,ECX
        JMP     @@Done
@@TwoDivs:
        MOV     ECX,EAX
        MOV     EAX,EDX
        XOR     EDX,EDX
        DIV     EBX
        MOV     EAX,ECX
        DIV     EBX
        MOV     EAX,EDX
        XOR     EDX,EDX
        JMP     @@Done
@@BigDivisor:
        MOV     EDI,ECX
        SHR     EDX,1
        RCR     EAX,1
        ROR     EDI,1
        RCR     EBX,1
        BSR     ECX,ECX
        SHRD    EBX,EDI,CL
        SHRD    EAX,EDX,CL
        SHR     EDX,CL
        ROL     EDI,1
        DIV     EBX
        MOV     EBX,DWORD [I+4]
        MOV     ECX,EAX
        IMUL    EDI,EAX
        MUL     DWORD [J+0]
        ADD     EDX,EDI
        SUB     EBX,EAX
        MOV     ECX,DWORD [I+4]
        MOV     EAX,DWORD [J+0]
        SBB     ECX,EDX
        SBB     EDX,EDX
        AND     EAX,EDX
        AND     EDX,DWORD [J+4]
        ADD     EAX,EBX
        ADC     EDX,ECX
@@Done: MOV     ECX,@Result
        MOV     [ECX+0],EAX
        MOV     [ECX+4],EDX
end;

function DivU(const A,B:Int64):Int64;
assembler;{&FRAME-}{&USES EBX,ESI,EDI}
var
  I:Int64;
  J:Int64;
asm
        MOV     EBX,A
        MOV     EAX,[EBX+0]
        MOV     EDX,[EBX+4]
        MOV     DWORD [I+0],EAX
        MOV     DWORD [I+4],EDX
        MOV     EBX,B
        MOV     ECX,[EBX+4]
        MOV     EBX,[EBX+0]
        MOV     DWORD [J+0],EBX
        MOV     DWORD [J+4],ECX
        MOV     EAX,EBX
        OR      EAX,ECX
        JZ      DivisionByZero
        MOV     EAX,DWORD [I+0]
        TEST    ECX,ECX
        JNZ     @@BigDivisor
        CMP     EDX,EBX
        JAE     @@TwoDivs
        DIV     EBX
        MOV     EDX,ECX
        JMP     @@Done
@@TwoDivs:
        MOV     ECX,EAX
        MOV     EAX,EDX
        XOR     EDX,EDX
        DIV     EBX
        XCHG    EAX,ECX
        DIV     EBX
        MOV     EDX,ECX
        JMP     @@Done
@@BigDivisor:
        MOV     EDI,ECX
        SHR     EDX,1
        RCR     EAX,1
        ROR     EDI,1
        RCR     EBX,1
        BSR     ECX,ECX
        SHRD    EBX,EDI,CL
        SHRD    EAX,EDX,CL
        SHR     EDX,CL
        ROL     EDI,1
        DIV     EBX
        MOV     EBX,DWORD [I+0]
        MOV     ECX,EAX
        IMUL    EDI,EAX
        MUL     DWORD [J+0]
        ADD     EDX,EDI
        SUB     EBX,EAX
        MOV     EAX,ECX
        MOV     ECX,DWORD [I+4]
        SBB     ECX,EDX
        SBB     EAX,0
        XOR     EDX,EDX
@@Done: MOV     ECX,@Result
        MOV     [ECX+0],EAX
        MOV     [ECX+4],EDX
end;


> I first thought that the xor cx,cx can be eliminated too, by clearing the
> result after the xor dx,dx. But the xor cx,cx leaves the flags in a defined
> state, which the div does not. So I think it is safer to leave this xor
> cx,cx in.

It probably IS save. Because everytime div32 is used in the source, an addition follows that sets the flags anyway. So I will try to further optimize this and incorporate your suggestion regarding the two divisions on 16-bit divisor.

> > I made some changes to the latest EDR-DOS sources maintained by ecm:
> >
> > - fixed bug in DRDOS.SYS div32 function, leading to division errors on
> > partitions with more than 66535 FAT sectors. There is also a div32
> function
> > in DRBIO.SYS present, but it did not contain the bug.
>
> https://github.com/SvarDOS/edrdos/commit/167fe71ec058f80b7da47f11f2a34fc66938ad57
>
> div16:
> mov       ax,12[bp]
> mov  dx,14[bp]
>
> Surely you can xor dx, dx here if you already checked that
> word [bp + 14] is zero?
>
> More to the point if the divisor high word is zero, a two-step division of
> two 32/16=16 divisions can be done on a 32-bit dividend (with 32-bit
> quotient) which would be faster than the full 32-bit division (that fully
> supports 32-bit divisors in addition to dividends/quotients).
>
> The division functions in DRBIO both do not offer the fast path for smaller
> numbers:
>
> https://github.com/SvarDOS/edrdos/blob/f6584d40d6dda553e63f7682ad672536f53ae6ff/drbio/disk.asm#L3286
>
> https://github.com/SvarDOS/edrdos/blob/f6584d40d6d...e63f7682ad672536f53ae6ff/drbio/bdosldr.a86#L772

Yes, by re-arranging a little bit, the unconditional jump can also be eliminated, like so:

div32:                                  ; 32-bit division
;--------
; On Entry:
;       32-bit dividend & divisor on stack
;       space for 32-bit quotient & remainder reserved on stack
;       SP-16
; On Exit:
;       32-bit quotient & remainder on stack
;       SP-16
; Modified registers:
;       AX,CX,DX,BP
        mov     bp,sp                   ; base address of temporary variables
        add     bp,2
        cmp     word ptr 10[bp],0       ; if divisor high => 32bit div
         jne    div32_full
        cmp     word ptr 14[bp],0       ; if dividend high => 32bit div
         jne    div32_full
div16:  mov     ax,12[bp]               ; AX=low 16 bits of dividend
        xor     dx,dx
        div     word ptr 8[bp]
        xor     cx,cx
        mov     [bp],dx
        mov     2[bp],cx                ; clear high part of remainder
        mov     4[bp],ax
        mov     6[bp],cx                ; and quotient result
        ret
div32_full:
        ...

I first thought that the xor cx,cx can be eliminated too, by clearing the result after the xor dx,dx. But the xor cx,cx leaves the flags in a defined state, which the div does not. So I think it is safer to leave this xor cx,cx in.

> I made some changes to the latest EDR-DOS sources maintained by ecm:
>
> - fixed bug in DRDOS.SYS div32 function, leading to division errors on
> partitions with more than 66535 FAT sectors. There is also a div32 function
> in DRBIO.SYS present, but it did not contain the bug.

https://github.com/SvarDOS/edrdos/commit/167fe71ec058f80b7da47f11f2a34fc66938ad57

div16:
        mov     ax,12[bp]
        mov     dx,14[bp]

Surely you can xor dx, dx here if you already checked that word [bp + 14] is zero?

More to the point if the divisor high word is zero, a two-step division of two 32/16=16 divisions can be done on a 32-bit dividend (with 32-bit quotient) which would be faster than the full 32-bit division (that fully supports 32-bit divisors in addition to dividends/quotients).

The division functions in DRBIO both do not offer the fast path for smaller numbers:

https://github.com/SvarDOS/edrdos/blob/f6584d40d6dda553e63f7682ad672536f53ae6ff/drbio/disk.asm#L3286

https://github.com/SvarDOS/edrdos/blob/f6584d40d6d...e63f7682ad672536f53ae6ff/drbio/bdosldr.a86#L772

---
l

I made some changes to the latest EDR-DOS sources maintained by ecm:

- re-implement proprietary FIXUPP utility with open source version
- fixed bug in DRDOS.SYS div32 function, leading to division errors on partitions with more than 66535 FAT sectors. There is also a div32 function in DRBIO.SYS present, but it did not contain the bug.
- create FAT-32 default BPB for FAT-32 partitions instead of FAT-16 default BPB, which prevented FreeDOS format from formatting such a partition as FAT-32
- make DRDOS.SYS linkable with OpenWatcom wlink by adding missing group definitions and running FIXUPP on all RASM86 produced object files.
- create Watcom makefiles for DRBIO.SYS and DRDOS.SYS (using wlink)

Repository is located at https://github.com/SvarDOS/edrdos

Another advantage is you may be able to share more code between the entire kernel than if you split it into two files. And some build time calculations may be possible to optimise things that a two-file kernel cannot do. (In lRxDOS's single-assembly build, NASM can potentially calculate things that even a single-file kernel build cannot if you use a linker to link multiple object files into one executable.)

---
l

> > I don't think it is required to combine the file. It is good for other
> reasons though.
>
> What are the other reasons?

Several:

* BIO and DOS file can get out of sync, potentially resulting in failures to boot or even data corruption.
* One more file to keep track of.
* Need a FAT FS read implementation in the BIO that is only ever used to read the DOS file, this is in bdosldr.a86 for EDR-DOS, called by the BIO init routines here.
* The BIO kernel has to locate the DOS file, meaning it will have to include a directory scanner. (Arguably, lDOS iniload contains just as much of a FAT FS reader (to read the remainder of the kernel file) as EDR-DOS's BIO file, but lDOS iniload certainly does not need a directory scanner.)
* Compression of kernel files also needs two bespoke solutions, one for each file, whereas lDOS iniload + inicomp has a single compression stage which depacks the entire remaining kernel. This can make for better compression ratio than compressing two files, too.

Back in the day I discussed this with Udo in the EDR-DOS forums. However, that thread is likely lost to time. I recall that Udo brought up you can update one of the files without the other, and vendors could get away with only providing a BIO file sharing a common DOS file that they wouldn't have to know much about. At the time I already noted that this last advantage is minor if the entire kernel is available as free software.

The second link that I included in my list also hints it is possible for the DOS to be resident somewhere already, and not have the BIO load it from a file. This means part of the work towards a single-file kernel may already be done.

---
l

> > I don't think it is required to combine the file. It is good for other
> reasons though.
>
> What are the other reasons?
>
>
> I think it's worth to reach out to Matthias Paul and Bryan Sparks (and
> other former team members, if you know any) to ask for DR-DOS binaries or
> sources.
> Especially since Matthias himself was mentioning that it'll be good to
> merge EDR-DOS 7.01.xx and DR-DOS 7.07.
> Maybe they can help also with the DOS memory maps in the load process.

I try myself to reach Paul but without success, I hope you will have more luck.

And same for CandyMan

> I don't think it is required to combine the file. It is good for other reasons though.

What are the other reasons?


I think it's worth to reach out to Matthias Paul and Bryan Sparks (and other former team members, if you know any) to ask for DR-DOS binaries or sources.
Especially since Matthias himself was mentioning that it'll be good to merge EDR-DOS 7.01.xx and DR-DOS 7.07.
Maybe they can help also with the DOS memory maps in the load process.

> Regarding version number - to avoid past confusion cases - would be nice
> if:
>
> - 6.5, 7.5, 8.5, etc. are reserved for use in emulators - by analogy with
> NTVDM
> - 7.01.08 WIP is kept as "work in progress" and version is not increased to
> 7.01.09. That's the case with this update here, which is good!

If I will do more work on EDR-DOS I am considering a 7.01.09 or beyond. But that remains to be seen.

> - 7.08 and 7.09 are reserved for IBMBIO/IBMDOS/COMMAND combination that
> provides all functionality of EDR-DOS 7.01.08 and DR-DOS 7.07
> - 7.1 is reserved for IBMBIO/IBMDOS/COMMAND combination that provides all
> functionality of MS-DOS 7.1, PC DOS 7.1, DR-DOS 7.07, EDR-DOS 7.01.08
> - 8.2 is reserved for IBMBIO/IBMDOS/COMMAND combination that provides all
> functionality of MS-DOS 8.0, PC DOS 7.1, DR-DOS 7.07, EDR-DOS 7.01.08,
> DR-DOS 8.0, DR-DOS 8.1, RxDOS 7.2x
> - 8.3 and up are reserved for UEFI versions or at least used with restrain
> - 9.x gets reserved for future substantial change.
> - incremental changes to get increase only in the x.xx.rr revision rather
> than the minor/major version number, e.g. use the 7.01.08 WIP until it gets
> merged with 7.07, then 7.09.rr until all 7.1 functionality is included,
> then 7.1x.rr until all 8.1 functionality is included, etc.

Don't have much of a comment on any of this.

---
l

> > 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.)
> >
> > > 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'm happy to see this updated EDR-DOS 7.01.08 WIP! EDR-DOS repository also
> got a Github mirror.
>
> Now that the
> license is
> opened - it
> would be great if the EDR-DOS branch gets reunited with
> DR-DOS 7.07.

This would require, at least, either descriptions of what changed, or actual files of that version. Preferably both. Neither seems to be provided in that thread.

> Matthias Paul
> once
> wrote:
>
> > I still have not completely lost hope, that at some fine day in the
> future the current owner of the DR-DOS assets may decide that its
> commercial life is finally over and that it is due to open source the
> system. This would make it possible to reunificate the different code
> branches to create the most advanced DR-DOS ever for all its fans. Well,
> well...
>
> So, if he gets contacted (e.g. via
> his
> Wikipedia talk page?) in these improved license circumstances, maybe
> he can help with:
>
> - DR-DOS 7.07 (Kernel and drive tools?) - binary/source?
> -
> WinGlue/WinBolt
> (ability to run Win9x) - in case that's not possible in DR-DOS 7.06 and
> 7.07.
> -- binary/source?

Never seen any of either.

> -- is combined BIOS+BDOS file mandatory? Or separate files IBMBIO.COM,
> IBMDOS.COM, MSDOS.SYS (settings text file), IO.SYS (if such kind of
> placeholder/redirect is needed) can exist at the same time?

I don't think it is required to combine the file. It is good for other reasons though.

> -- can DR-DOS 7.07 boot from Win9x/Me boot sectors? Does DR-DOS 7.07
> include all functionality from DR-DOS 7.06?
> -- boot logo, etc. Win9x settings in
> MSDOS.SYS/WINBOOT.INI - any issues with those?
> - optionally loadable multi-user security extension - (World/Group/Owner)
> access permission system - DR DOS "Panther" BETA 1 - birnary/source for
> that?

Never seen.

> - DR-DOS 7.03 source (Kernel or full software package)?

Also never seen.

> Did you ask Bryan Sparks (the DRDOS owner) if he can help with any of
> these?

No, I did not yet.

> Also, what about:
> - DR-DOS 8.0/8.1 - are there any Kernel/IBMBIO/IBMDOS/COMMAND.COM changes
> in comparison with 7.01.06 and 7.03? FAT32 DELWATCH and SHARE, but those
> are external files?
> - RxDOS - are there any changes not yet implemented in the EDR branch?

RxDOS isn't a "branch" of anything. It is not based on any other existing 86-DOS version. So this is very confusing.

> - What about functionalities from lDOS not yet implemented in the EDR
> branch? What is lDOS, actually?

lDOS is my name for a DOS that would be completely developed by me. Some components of it are actually implemented:

Most notably the ldosboot boot12/boot16/boot32 (with FSIBOOT) boot sector loaders and the multi-protocol iniload which is the initial stage of a kernel that can be loaded as MS-DOS v6 kernel, MS-DOS v7 kernel, IBM-DOS kernel, FreeDOS kernel, Multiboot1 or Multiboot2 specification kernel, or lDOS kernel. This is used for recent RxDOS revisions and more importantly (and usefully) for bootable lDebug. There is also some additional stages like fdkernpl (load wrapped FreeDOS-style kernel) and inicomp (compressed payload, depack during triple-mode execution) that can be added to iniload.

Another component is ldosmbr, which provides two different MBR loaders both based on original sources from syslinux but improved.

Finally there is the ldos repo which provides a few partial bits and bobs. This has some sectioning stuff, some relocations of DOSDATA (UMA/LMA) and DOSCODE (HMA/UMA/LMA), entrypoints using the relocated sections, and a replacement memory allocation (LMCB/UMCB) subsystem. This repo is integrated into the most recent revision of RxDOS. During development I called the combined kernel lRxDOS, but it's back to just RxDOS (in the file RXDOS.COM) more recently.

RxDOS is very immature in any case. The only things it definitely does better than EDR-DOS is the ldosboot stages and single-file kernel loading. To implement single-file loading requires some knowledge of the DOS memory maps at various points in the load process. (I don't have this knowledge for (E)DR-DOS.) The other advantage is it builds with NASM, rather than a hodgepodge of JWasm (open source but not free software), WarpLink (public domain with NASM sources but runs in DOS), and free-but-no-sources software RASM and linker.

---
l

> > > I released new versions DRDOS 7.01.7 & 7.01.8
> > >
> >
> > Question...
> >
> > What ever happened to Udo ?
>
> The last
> post by Udo Kuhnt in his forum, 2012-Feb-02 is mentioned
> here,
> but link is broken and I can't find an archive of it. Any clues on that?

Way back 10yrs ago in this thread, DOS386 insinuated that Udo had died
but never clarified if that statement was just figuratively
due to the status of his Enhanced DR-DOS project
or if it was meant literally and Udo was actually physically dead.

http://www.bttr-software.de/forum/forum_entry.php?id=12870

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

Regarding version number - to avoid past confusion cases - would be nice if:

- 6.5, 7.5, 8.5, etc. are reserved for use in emulators - by analogy with NTVDM
- 7.01.08 WIP is kept as "work in progress" and version is not increased to 7.01.09. That's the case with this update here, which is good!
- 7.08 and 7.09 are reserved for IBMBIO/IBMDOS/COMMAND combination that provides all functionality of EDR-DOS 7.01.08 and DR-DOS 7.07
- 7.1 is reserved for IBMBIO/IBMDOS/COMMAND combination that provides all functionality of MS-DOS 7.1, PC DOS 7.1, DR-DOS 7.07, EDR-DOS 7.01.08
- 8.2 is reserved for IBMBIO/IBMDOS/COMMAND combination that provides all functionality of MS-DOS 8.0, PC DOS 7.1, DR-DOS 7.07, EDR-DOS 7.01.08, DR-DOS 8.0, DR-DOS 8.1, RxDOS 7.2x
- 8.3 and up are reserved for UEFI versions or at least used with restrain
- 9.x gets reserved for future substantial change.
- incremental changes to get increase only in the x.xx.rr revision rather than the minor/major version number, e.g. use the 7.01.08 WIP until it gets merged with 7.07, then 7.09.rr until all 7.1 functionality is included, then 7.1x.rr until all 8.1 functionality is included, etc.

> 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.)
>
> > 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'm happy to see this updated EDR-DOS 7.01.08 WIP! EDR-DOS repository also got a Github mirror.

Now that the license is opened - it would be great if the EDR-DOS branch gets reunited with DR-DOS 7.07.

Matthias Paul once wrote:

> I still have not completely lost hope, that at some fine day in the future the current owner of the DR-DOS assets may decide that its commercial life is finally over and that it is due to open source the system. This would make it possible to reunificate the different code branches to create the most advanced DR-DOS ever for all its fans. Well, well...

So, if he gets contacted (e.g. via his Wikipedia talk page?) in these improved license circumstances, maybe he can help with:

- DR-DOS 7.07 (Kernel and drive tools?) - binary/source?
- WinGlue/WinBolt (ability to run Win9x) - in case that's not possible in DR-DOS 7.06 and 7.07.
-- binary/source?
-- is combined BIOS+BDOS file mandatory? Or separate files IBMBIO.COM, IBMDOS.COM, MSDOS.SYS (settings text file), IO.SYS (if such kind of placeholder/redirect is needed) can exist at the same time?
-- can DR-DOS 7.07 boot from Win9x/Me boot sectors? Does DR-DOS 7.07 include all functionality from DR-DOS 7.06?
-- boot logo, etc. Win9x settings in MSDOS.SYS/WINBOOT.INI - any issues with those?
- optionally loadable multi-user security extension - (World/Group/Owner) access permission system - DR DOS "Panther" BETA 1 - birnary/source for that?
- DR-DOS 7.03 source (Kernel or full software package)?

Did you ask Bryan Sparks (the DRDOS owner) if he can help with any of these?

Also, what about:
- DR-DOS 8.0/8.1 - are there any Kernel/IBMBIO/IBMDOS/COMMAND.COM changes in comparison with 7.01.06 and 7.03? FAT32 DELWATCH and SHARE, but those are external files?
- RxDOS - are there any changes not yet implemented in the EDR branch?
- What about functionalities from lDOS not yet implemented in the EDR branch? What is lDOS, actually?

> > I released new versions DRDOS 7.01.7 & 7.01.8
> >
>
> Question...
>
> What ever happened to Udo ?

The last post by Udo Kuhnt in his forum, 2012-Feb-02 is mentioned here, but link is broken and I can't find an archive of it. Any clues on that?

> > 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.
>
> %COPYCMD% was
> introduced in, what, MS-DOS 5? In .BAT files, COPY defaults to /Y,
> otherwise if interactive it asks you before overwriting.

Oh, right, FreeCOM does default to overwrite without asking in a batch file. I hadn't considered that it may differ.

---
l

> 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.

%COPYCMD% was introduced in, what, MS-DOS 5? In .BAT files, COPY defaults to /Y, otherwise if interactive it asks you before overwriting.

> > I released new versions DRDOS 7.01.7 & 7.01.8
> >
>
> Question...
>
> What ever happened to Udo ?

No reply at-all ??

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

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

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

> 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

> 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

> > 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

> 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).

>
> 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

> 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

> 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.

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

> 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.

> >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

>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

> 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

> > > 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

> > 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

Thanks for the exhaustive explanation. Who asks not stray.

> 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.

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.

> > 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

> > 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

> 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).

> 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

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


> I released new versions DRDOS 7.01.7 & 7.01.8
>

Question...

What ever happened to Udo ?

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

> >
> > 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