DOS ain't dead

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

No reply at-all ??

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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