SvarDOS community forum

In July I sent a report to ecm about the long-standing DIR bug, and with changeset 175 she corrected it: https://hg.pushbx.org/ecm/edrdos/rev/7616ed590558 But it seems to be undead, at least a little bit ;-) With Kernel 20240914 (I did not test the releases in between, however), a 'dir' on my CDROM drive now reports: 4.294.705.152 Bytes free (in the last line) Changeset 175 reported "0 Bytes free" as expected.

Hello Cryptus, the Kernel you currently use should have the patch included. I installed the XCDROM SvarCOM package, loaded it via config.sys and made SHSUCDX make use of the driver. It reports zero bytes free, as it should. Directory listings show no implausible file sizes. This is also the case with VIDE-CDD.SYS. So I currently cannot reproduce your problem. I tested it with different CDs. Can you give further details on your setup, and does the ECM kernel work for you? This is the commit I adapted from ECMs repo in July. commit 4132acc0a37fb9253da46487935b1cadbc4aea39 Author: Bernd Boeckmann <bernd-github@boeckmann.io> Date: Wed Jul 3 19:06:47 2024 +0200 fix, LFN search on redirected drive should not read plus size (ecm) imported from https://hg.pushbx.org/ecm/edrdos/rev/7616ed590558 diff --git a/drdos/header.asm b/drdos/header.asm index 6466115..2d35792 100644 --- a/drdos/header.asm +++ b/drdos/header.asm @@ -1367,6 +1367,10 @@ lfn_find_handle_heap_free: lfnpathflag: db 0 + Public lfn_search_redir^M +lfn_search_redir:^M + db 0^M +^M PCMODE_CODE ends PCM_CODEND segment public para 'CODE' diff --git a/drdos/lfn.asm b/drdos/lfn.asm index 5cee95e..99cd5eb 100644 --- a/drdos/lfn.asm +++ b/drdos/lfn.asm @@ -39,7 +39,7 @@ PCMODE_CODE segment public word 'DATA' extrn lfn_find_handle_heap_end:word extrn lfn_find_handle_heap_free:word extrn lfnpathflag:byte -; extrn lfn_search_redir:byte + extrn lfn_search_redir:byte^M PCMODE_CODE ends BDOS_CODE segment public word 'CODE' @@ -381,7 +381,7 @@ f714e_entry: mov FD_FUNC,ax ; mov FD_LFNSEARCH,1 ; use FAT+/LFN extensions mov fdos_pb+10,1 ; use FAT+/LFN extensions - mov lfnpathflag, 1 + mov word ptr lfnpathflag, 1^M push di ; handle push ds push ss:dma_segment ; save old DTA @@ -434,7 +434,10 @@ f714f_10: xor ax,ax ; zero high dword stosw stosw + rol ss:lfn_search_redir, 1^M + jc f714F_redir_no_plus_size^M mov al,[si-7] ; extended file size +f714F_redir_no_plus_size:^M stosw xor ax,ax stosw diff --git a/drdos/redir.asm b/drdos/redir.asm index 16f4b64..b687fa1 100644 --- a/drdos/redir.asm +++ b/drdos/redir.asm @@ -58,7 +58,7 @@ title 'REDIR - DOS file system network redirector interace support' ; ENDLOG PCMCODE GROUP BDOS_CODE -PCMDATA GROUP PCMODE_DATA +PCMDATA GROUP PCMODE_DATA,PCMODE_CODE^M ASSUME DS:PCMDATA @@ -102,6 +102,10 @@ PCMODE_DATA segment public word 'DATA' PCMODE_DATA ends +PCMODE_CODE segment public word 'DATA'^M + extrn lfn_search_redir:byte^M +PCMODE_CODE ends^M +^M BDOS_CODE segment public byte 'CODE' Public islocal @@ -280,6 +284,7 @@ redir_accept: ;============ ; We have decided to accept an FDOS function. ; Note by this time the functions have been validated as legal + mov lfn_search_redir, 0FFh^M mov file_attrib,16h ; default search attribs to all pop si ; discard the near return address mov si,2[bp] ; SI -> parameter block

I'll get to test this later this week. The revision 175 change is only about file sizes. You're reporting that the free space display is wrong; this uses a different interface so it isn't the same bug or the same cause, despite a similar result.

Tested using the .iso from https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/test/FD14-LegacyCD.zip I tested the edrdos.com + command.com pairs from the following builds: https://pushbx.org/ecm/download/old/edrdos/20240914.zip https://pushbx.org/ecm/download/old/edrdos/20241002.zip https://pushbx.org/ecm/download/old/edrdos/20241003.zip https://pushbx.org/ecm/download/old/edrdos/20241020.zip https://pushbx.org/ecm/download/old/edrdos/20241104.zip I'm using "HimemX 3.38 [11/21/22]", "XCDROM V2.2, 2-08-2006.", and SHSUCDX "Version 3.09 (2 September, 2022)." All tests resulted in free space of zero bytes. Please upload or link an image that has the problem for you, or check whether the program versions match yours.

I'm using "QEMU emulator version 5.2.0 (Debian 1:5.2+dfsg-11+deb11u3)" with a command line of "qemu-system-i386 -fda diskedr.img -boot order=a -fdb onefatd.img -display curses -chardev serial,id=serial2,path=/tmp/vptty-dos -serial null -serial chardev:serial2 -hda onefat.img -cdrom FD14LGCY.iso"

dconfig.sys contents: switches=/f files=128 device=a:\himemx.exe /verbose /method:bios device=a:\xcdrom.sys /d:cd$$$ shell=a:\dcommand.com /e:2048 /p:drautoex.bat history=on dos=high,umb installlast=a:\shsucdx.com /d:cd$$$

Thanks Bernd and ecm. Well, I could have done more tests yesterday, but it was late... In meantime I did some more testings, too. Found out that the wrong free space display (as described above) only occurs when loading ELTORITO.SYS (!) as CDROM driver (indeed not with VIDE-CDD.SYS, so both of you could not reproduce it). I am working a lot with bootable CDROMs, thats where ELTORITO.SYS comes in. Yet I did not burn a real CDROM to do testing on real hardware, so my findings are from 86Box 4.2.1 (build 6130), from an older PCem v14 and from VMware Workstation Player 14. Will do some more tests with QEMU. Nevertheless it must be "somehow" EDR-DOS related, as it does NOT occur when booting MS-DOS 6.22, PC DOS 7.0 rev 1 (from 1998), Novell DOS 7, or the original DR-DOS 7.03 from 1999 (using the same ELTORITO.SYS driver). (Edit: I am using the same SHSUCDX version) It might also be related to the memory driver, as it does happen with EMM386.EXE from DR-DOS 7.03, but not with JemmEX 5.84 or HIMEMX.EXE v3.38. But for me it's really ok to give up here, as this might be a very special and rare (and not so important) problem/constellation. Don't want to waste Bernds or ecms precious time :-)

Frank, that's no waste of time but a valid bug report of yours ;) As this might be a kernel related problem we should try to isolate and fix it.

Do you boot from the CD or are you using eltorito.sys despite not having booted from the CD? Also, is this the correct version? http://ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/1.4/drivers/eltorito.zip

Yes, I am booting from CDROM. Yes, eltorito version is correct. Floppy boot images are standard 1.44MB images. Bootable iso is generated from my directory 'cdiso' with: genisoimage -r -J -N -l -no-iso-translate -relaxed-filenames \ -b isolinux/isolinux.bin -c isolinux/boot.cat \ -no-emul-boot -boot-load-size 4 -boot-info-table \ -hide-joliet-trans-tbl -hide-rr-moved \ -o /path/to/cdrom.iso cdiso (genisoimage comes with Debian, but is compatible to mkisofs) (I am using isolinux 3.61 with memdisk, as newer versions seem to have problems with PTS-DOS)

Frank, I took the opportunity to have a look at mkisofs and isolinux. So I created a bootable CD of SvarDOS including the ELTORITO driver. With that ISO, the driver seems to work as expected. You can download it from: https://nextcloud.iww.rwth-aachen.de/index.php/s/ZcDX9tFcDyTescs Can you verify if this also works for you? I used a less complex command line for creating the image: mkisofs -o svardos.iso -b isolinux/isolinux.bin -c isolinux/boot.cat -no-emul-boot -boot-load-size 4 -boot-info-table cdroot Can you also upload your non-working image? You should be able to upload it directly to the link I posted (may seem unresponsive for some time depending on the image size).

Bernd, I downloaded your 'svardos.iso' image. Boots fine. Now I am confused even more. My first command after booting was 'dir f:\' (where F: is the CDROM drive), because I was curious, and there was no mistake ("0 bytes free"). Then I thought about what I was usually checking first: the mem command. I issued several 'mem' and also 'mem /c /p' commands (all from A: drive) and then suddenly 'dir f:\' showed '4.294.705.152 Bytes free' ... After another single 'mem', the output of 'dir f:\' was correct again. First tested with 86Box 4.2.1 (and PCem v14). Then I fired up QEMU (at the moment I only have an older version installed: 2.1.2 (Debian 1:2.1+dfsg-12+deb8u15), as I rarely use it and for me it seems ok to boot DOS-Live-CDROMs - but with the same results. First ok, after some (several) 'mem' and 'mem /c /p' commands in no particular order: '4.294.705.152 Bytes free' (it's always the same number, with all 3 emulators) (all tests done with your iso) Can this be some weird interaction with the emulators? Can the 'mem' command trigger something? If you want, I can integrate my EDR-DOS-floppy-image in your iso and send it back, but I guess this won't help too much, as I did the tests with your iso...

Well, that one will be a troublemaker I guess. I finally could reproduce the error. Problem is that it only occurs sporadically, making it very hard to debug. But with the MEM / DIR combination I can eventually trigger it. Frank, if time permits it, can you please test if the three images including 525b4188 in the file name all cause problems to you? You get them through the link I posted above. My findings regarding this are, that only svardos_525b4188.iso shows this behaviour. But has to be tested more extensively, as like I said, sporadically... The images contain three different configurations: SvarCOM, SvarCOM with 256 byte environment, and EDR COMMAND.COM...

This does not seem to be ELTORITO driver related. I converted the boot image to use XCDROM.SYS instead and made a floppy boot. The above MEM / DIR sequence also triggeres. If the free space displayed is wrong, it always is the value 0xFFFC0000.

Bernd, if you reproduce it once and then rerun DIR does it always have the error again, or is it still rare then?

Yes, once it shows this number, it stays like that. But I can enumerate the directory entries just fine with their right size. It is only the free space that when it displays wrong, it stays like that. Interesting thing: when I spawn a new SvarCOM child process from inside SvarCOM, it displays correct. If I exit the child process to the parent shell, it displays wrong again.

If you can get it to reproduce repeatedly you can run the debugger and trace the DIR command? Cryptus, did you also use SvarCOM? (I only tested using EDR-DOS command.com.)

EDR COMMAND uses a different function to query the size. While SvarCOM uses INT21,36, EDR COMMAND uses INT21,7303 at first, and only falls back to INT21,32 if it fails. RBIL writes regarding INT21,36: "this function does not return proper results on CD-ROMs; use AX=4402h"CD-ROM" instead". But I do not think that this affects the EDR kernel, or does it?!?

According to the interrupt list https://fd.lod.bz/rbil/interrup/dos_kernel/2136.html AX = sectors per cluster BX = number of free clusters CX = bytes per sector DX = total clusters on drive And the CD drive returns ax=1 bx=0 cx=2048 dx=65535. So it should calculate the free space as zero bytes, as expected. lDebug (2024-07-09) -a 31AB:0100 mov ax,3600 31AB:0103 mov dl,4 31AB:0105 stc 31AB:0106 int 21 31AB:0108 nop 31AB:0109 -t AX=3600 BX=0000 CX=0000 DX=0000 SP=FFFE BP=0000 SI=0000 DI=0000 DS=31AB ES=31AB SS=31AB CS=31AB IP=0103 NV UP EI PL ZR NA PE NC 31AB:0103 B204 mov dl, 04 - AX=3600 BX=0000 CX=0000 DX=0004 SP=FFFE BP=0000 SI=0000 DI=0000 DS=31AB ES=31AB SS=31AB CS=31AB IP=0105 NV UP EI PL ZR NA PE NC 31AB:0105 F9 stc - AX=3600 BX=0000 CX=0000 DX=0004 SP=FFFE BP=0000 SI=0000 DI=0000 DS=31AB ES=31AB SS=31AB CS=31AB IP=0106 NV UP EI PL ZR NA PE CY 31AB:0106 CD21 int 21 - AX=0001 BX=0000 CX=0800 DX=FFFF SP=FFFE BP=0000 SI=0000 DI=0000 DS=31AB ES=31AB SS=31AB CS=31AB IP=0108 NV UP EI PL ZR NA PE NC 31AB:0108 90 nop -

@ecm: Yes, I (only) used SvarCOM in my settings. With the combination of Kernel-changeset 175 and EDR command.com I never saw this. Last week I updated to Kernel 20240914 and SvarCOM, and from then on it started. @Bernd: I think I'll have time to test in the afternoon, will report. Like Bernd writes, it only occurs sporadically. Sometimes it even disappears and displays "0 Bytes free" again, but I can't find a 'rule'... My personal impression was that 'mem /c /p' triggers it more likely than 'mem' alone, but this might be wrong. I also must correct an earlier report that it only happens with EMM386 and not with HIMEMX, that was not true .

FYI, the "free space trailing DIR" is computed and displayed here: https://github.com/SvarDOS/core/blob/master/svarcom/trunk/cmd/dir.c#L145 I also use a custom mul32() function there for multiplication of values because using the C * operator makes the compiler try using libc (which is unavailable). Maybe the problem is there. Mateusz

I could not trigger it with EDR command either. I also queried the INT21,32 like ECM did. And even when SvarCOM reports fffc0000 as size, the INT21,32 returns the expected results under debug. Exiting debug and doing a dir e: still shows that fffc0000 value.

I uploaded a little screencast demonstrating the behaviour to the Nextcloud. If someone has other stuff, you may upload it to the same link. https://nextcloud.iww.rwth-aachen.de/index.php/s/ZcDX9tFcDyTescs

If interested, there is a patch that will make SvarCOM display the AX/BX/CX values at each DIR command so it should be easy to validate whether or not this is a SvarCOM issue or a kernel thing. Index: cmd/dir.c =================================================================== --- cmd/dir.c (revision 2368) +++ cmd/dir.c (working copy) @@ -174,6 +174,19 @@ pop ax } + { + char dbgbuff[8]; + output("INT 0x36 --> AX="); + ustoa(dbgbuff, sects_per_clust, 1, '0'); + output(dbgbuff); + output(" BX="); + ustoa(dbgbuff, avail_clusts, 1, '0'); + output(dbgbuff); + output(" CX="); + ustoa(dbgbuff, bytes_per_sect, 1, '0'); + outputnl(dbgbuff); + } + /* multiple steps to avoid uint16 overflow */ *freebytes = mul32(sects_per_clust, avail_clusts); *freebytes = mul32(*freebytes, bytes_per_sect); Mateusz

While I do not think that's the fault of the mul32 C code (looks good), we may check the generated assembly, as the mul16 is defined as inline assembly. Perhaps there is something wrong with the specified register usage (no modify). I uploaded the disassembled file CMD.LST. Its large. Search for mul32_. I have an appointment now, will likely have a look at this tomorrow, if noone else looked at it before... We should optionally include multiplication and division routines in WMINCRT.

You can use lDebug like so: ldebug /t tsr install indos bp new ptr ri21p when value ah in 36, 73 g Then run the DIR command. On uninteresting calls just run "g". On the interesting call, run "g ptr [ss:sp]" to skip the syscall until it returns to the caller (SvarCOM). Then inspect the returned values. If they are good at that point, single step the calculation to see how it yields the error value.

@Bernd: Tried your 3 "images including 525b4188". With svardos_525b4188.iso I can reproduce the fault, not with the other ones. Also: As seen before, after one or two more mem commands, the fault disappeared again.

ECM thanks for the commands! That the debugger is capable of going resident and debug DOS without launching it prior to DOS is very helpful. I performed your commands. I waited until the error occured and then installed the debugger. Sadly, I have bad news: the values come directly from the kernel. I uploaded a screenhot with the values, file int21_32_failure_ldebug.png. I will try to single-step through the kernel the next days to find out what is happening...

Do you know how to use TracList with the drdos.tls file that I ship with my lEDR-DOS builds? It is greatly more convenient than to trace through the source or listing files manually.

So I tested ECMs latest kernel and the SvarDOS latest kernel. I was not able to re-produce the behaviour with ECMs kernel. At least not with the exact same configuration. So my current estimation is that it is not affected. This rules out the TracList debugging for the next time. As ECMs version has a) the better debugging method and b) seems somehow not affected by the bug, we should decide what to do. I would like to find out what is flawed in the SvarDOS kernel, but that may take its time. I have some ideas on what might be the cause. For example, the segment alignment differs slightly. So maybe its an alignment issue anywhere in the code. However, in an effort to "ship" the best distribution we can, my current proposal would be switch to ECMs kernel for the next SvarDOS kernledr package release. This would release me from some pressure of find this bug, as my holidays are over and my next weeks will be quite work intensive. If we make the switch, it has to be in a way that the user can accomplish. So it would be best if the kernel is named kernel.sys and speaks the FreeDOS load protocol. That would safe the user from doing a SYS. Does anyone have objections against this procedure, and would it be possible to adapt ECMs kernel in the way above mentioned?

That shouldn't be a problem, just chose any one kernel file from bin/ -- they all "speak" FreeDOS load.

I have to revert my previous statement that the problem does not occur with the ECM kernel. It indeed does. The reason why it did not trigger yesterday was that I removed the /E:512 from the SHELL= config.sys line. Without it I was not able to trigger it with either SvarDOS or ECM kernel. I uploaded a ready-to-go ISO image with the ECM kernel to the Nextcloud. Steps to reproduce: - mem/d a few times - dir e: - repeat until error occurs

Bernd, your last link pops up "Log in to IWW cloud"

> Bernd, your last link pops up "Log in to IWW cloud"

Sorry for that. This is a shared link to the whole folder: https://nextcloud.iww.rwth-aachen.de/index.php/s/ZcDX9tFcDyTescs Have a look at the files containing "ecm".

Direct links: ISO Image: https://nextcloud.iww.rwth-aachen.de/index.php/s/ZcDX9tFcDyTescs/download?path=%2F&files=svardos_ecmkernel.iso

I reproduced with svardos_ecmkernel.iso. However, while repeated dir E: does keep the error behaviour, running int3.com and assembling an int 21.36 call seems to have reverted the state to the original (expected) output. I'll play with this more later.

Screenshot: https://nextcloud.iww.rwth-aachen.de/public.php/dav/files/ZcDX9tFcDyTescs/func36_error_ecmkernel.png

> running int3.com and assembling an int 21.36 call seems to have reverted the state to the original (expected) output

May I ask what int3.com is and where it comes from? I did not find this file in the lDebug package.

Very simple executable to break into a resident debugger: E:\>ldebug int3.com -d 100 l bxcx 2B03:0100 CC B8 00 4C CD 21 - ...L.! -u 100 l bxcx 2B03:0100 CC int3 2B03:0101 B8004C mov ax, 4C00 2B03:0104 CD21 int 21 - I also have a similar int19.com

Ok, so what you basically did was creating a new child process (INT3.COM) before running the INT21,36h test. Running another command.com from inside the command.com where the error occured also reverted the behaviour for me. But when exiting to the parent shell, free space display was broken again. However, I was able to see the error inside lDebug with the breakpoint method you described. I made lDebug resident after the error materialized. But that should not have made any difference?

> Ok, so what you basically did was creating a new child process (INT3.COM) before running the INT21,36h test.

Exactly.

> However, I was able to see the error inside lDebug with the breakpoint method you described. I made lDebug resident after the error materialized. But that should not have made any difference?

After I terminated the int3.com process the error was gone, in the same shell that had it before. So I'd guess *installing* lDebug could also make the error disappear. Of course, without exacting knowledge of the bug's cause it could be anything. Luckily we don't need to install lDebug only once the error occurs. There are two ways to install it before: Either using the conditional permanent breakpoint (like I showed earlier). This is tedious because you need to enter G every time to proceed until you observe the error. The other way is to "install timer serial" (needs to configure an appropriate serial port with a terminal application connected to the other end) then run the test. Once the error occurs, enter Double Control-C to the serial terminal. Now you can re-enable or newly add a permanent breakpoint on the int 21h handler and G once more to return control to the shell. I suspect this may preserve the error state where running int3.com did not.

This is where it gets the wrong values https://hg.pushbx.org/ecm/edrdos/file/8a412e478d23/drdos/disk.nas#l469 This is probably where it should get initialised? https://hg.pushbx.org/ecm/edrdos/file/8a412e478d23/drdos/redir.nas#l1083 I'll have to dig more for where the "byte [es:DDSC_MEDIA + bx],8fh" comparison should be set up.

It seems the calculation that follows in disk.nas is intended to do this: https://fd.lod.bz/rbil/interrup/dos_kernel/2136.html#sect-2790

> (FAT32 drive) the reported total and free space are limited to 2G-32K

> should they exceed that value

SeeAlso: AH=1Bh,AH=1Ch,AX=4402 However, it returns FFFEh clusters free, 64 sectors/cluster, and 2048 bytes/sector which results in the dreaded FFFC_0000h bytes. With the same clamped bx and SpC but 512 bytes/sector we'd get: !-h bx * ax * 200 7FFF0000 decimal: 2147418112 !-h as bytes bx * ax * 200 7FFF0000 2047 MiB This is close to the 2 GiB minus 32 KiB that the interrupt list contains: !-h 2 *#1024*#1024*#1024 - #32 *#1024 7FFF8000 decimal: 2147450880 !- It seems that returning the fictional SpC = 64 and BpS as = 512 then if we return bx=FFFFh we'd get the value the interrupt list contains. The 32-bit amount free clusters field contains uninitialised garbage from whatever previously used the sec_pathname buffer (used by redir.nas as the temporary DPB). This is likely to contain a very high number of clusters if the high 8 bits are not all zeroes. So that explains why we always clamp in 21.36. But we need to figure out how the CD/redirector conditional should be taken.

I also made some initial remarks at: https://github.com/SvarDOS/edrdos/issues/128 Better to shift the discussion to Github from now on...

If the 32-bit amount free clusters of the DPB shim contains zeroes then we also return zero clusters free, which happens to be correct for a CDFS but would not be correct for other redirectors that actually return a meaningful non-zero free space.

I uploaded a patch for the first and second bugs (non-zero free space and 0FFFFh clusters total space) to https://hg.pushbx.org/ecm/edrdos/rev/bf4f4ec281b2 My build will be uploaded to https://pushbx.org/ecm/download/old/edrdos/20250110.zip in a few hours. Please drop in one of the kernel files from that archive and repeat your tests with this revision.

I also fixed two more bugs: Function 7303h didn't preserve its buffer size for a check, and the check itself had the wrong sense (jbe to accept large enough buffer whereas it should be jae): https://hg.pushbx.org/ecm/edrdos/rev/3c1d7e3f8ff2

fix: prevent calculation of CHS values on LBA rw to bootsector https://github.com/SvarDOS/edrdos/commit/9d842c1193bcbb25dfa7509ea23db489e5111964 also, I think the microoptimizations done by javiergutierrezchamorro introduced a flag invalidation error. Actually only the first line that the fix changes is needed: https://github.com/SvarDOS/edrdos/commit/cbe67f487a94a6a67b0c22ae86c896f75af05b64

These both commits (first derived from ECMs patches) should fix the issue: https://github.com/SvarDOS/edrdos/commit/6e1496ceffb993d2b34b27c0bb3e1e693c560be3 https://github.com/SvarDOS/edrdos/commit/c383bcf824458ed877f222073f610870c0f8a8da A SvarDOS kernel package was generated as a build artifact (Github account required): https://github.com/SvarDOS/edrdos/actions/runs/12723491279 I suggest to adapt SvarCOM to use function INT21.7303 for detecting free disk space, and only in case of error resort to INT21.36, as function 36 may saturate / overflow depending on the implementation.

I think using the 16-bit FAT size field == 0 as a FAT32 indicator is more common. Indeed one of the checks did just that, and you changed it. Why?

DDSC_DIRENT is also used as a check in func7303. Seems to me a good idea to have them do the check in the same way. Whether its better to use DDSC_DIRENT or DDSC_NFATRECS, I am not certain.

> fix:

> prevent calculation of CHS values on LBA rw to bootsector

> https://github.com/SvarDOS/edrdos/commit/9d842c1193bcbb25dfa7509ea23db489e5111964

Picked to https://hg.pushbx.org/ecm/edrdos/rev/f1f0db098fd0

> also, I think the microoptimizations done by javiergutierrezchamorro introduced a flag invalidation error. Actually only the first line that the fix changes is needed:

> https://github.com/SvarDOS/edrdos/commit/cbe67f487a94a6a67b0c22ae86c896f75af05b64

Picked to https://hg.pushbx.org/ecm/edrdos/rev/ff802f1e2f0e