Bernd Böckmann

Code tries to pin it to 0600h, which it cannot. Code also mentiones that this is located at 061Bh in DOS 4. Should be checked by inspecting MS-DOS 2 and...

Interesting. I asked because the [parse_path](https://github.com/SvarDOS/edrdos/blob/e62ca5db79db138ca656ec5760ea27816640fafd/drdos/utils.fdo#L1274) routine does not seem to handle this case. It could be made to accept this with reasonable effort, but if this is generally not...

This originates most likely from: https://github.com/SvarDOS/edrdos/blob/1b985bd5a62500da51c24e3790d2d64eb9567f31/drbio/genercfg.asm#L148-L158

Correction, in [1] there is already a check for EDR-DOS. [1]: https://hg.pushbx.org/ecm/callver/file/58cf27ed3876/callver.asm#l173

The version at https://hg.pushbx.org/ecm/callver/ already seems to work with the updated https://github.com/SvarDOS/edrdos/commit/6ea9b7f4715366c4ba752108be0d477f26526657 EDR kernel. @ecm-pushbx anything that speaks against making FreeDOS and SvarDOS packages from it? Otherwise I can prepare...

System freezes when SHSUCDX opens the UDVD2 device driver https://github.com/adoxa/shsucd/blob/f905b43436107b9238c11d5f9a1759c98eb5cc7d/shsucdx.nsm#L2959

This runs fine when launched from SvarCOM after installing lDebug with `install indos`, `tsr`. It hangs when running directly under lDebug with `ldebug C:\svardos\shsucdx.com /D:SVCD0001`, then `install indos` and `g`....

This thing behaves very randomly when running under lDebug. Single-stepping through its source makes it run perfectly. Simply running it via `g`, likely results in stack corruption (sometimes)?!? At least...

> I realized only now that this issue is probably about the COMMAND from EDR-DOS, not SvarCOM. Correct :)

Implementation of this is done in the [fatplus](https://github.com/SvarDOS/edrdos/tree/fatplus) branch. I uploaded an initial version.