SvarDOS community forum

Liam Proven has gifted us with a very nicely written article about SvarDOS for "The Register": https://www.theregister.com/2024/12/23/svardos_drdos_reborn/

Thanks for the pointer! I think it doesn't credit you enough for the EDR-DOS kernel changes you contributed. While I did work on the toolchain *some* you also helped with that. I want to investigate whether the drdosprojects recommended share.exe (from DR-DOS v7.01?) actually works as intended on (FAT32 enabled) current EDR-DOS. I've found that the dispatch table before DOSDATA:0CCh is just a placeholder in (E)DR-DOS, it contains default offsets but segments of all zeroes. According to the interrupt list, https://fd.lod.bz/rbil/interrup/dos_kernel/2152.html#table-01636 "sharing hooks are not supported by DR DOS 5-6; they appear to be supported by Novell DOS 7, with a segment of 0000h indicating the DOS data segment". That's probably nonsense, the hooks at this spot https://hg.pushbx.org/ecm/edrdos/file/8a412e478d23/drdos/header.nas#l277 are never called, and if they were it wouldn't make sense to use segments of zero as a special value which would much complicate the calling of these hooks. EDR-DOS does contain another share dispatch table that looks similar at https://hg.pushbx.org/ecm/edrdos/file/8a412e478d23/drdos/header.nas#l782 and this one is actually used. As I mentioned elsewhere https://retrocomputing.stackexchange.com/questions/31031/does-dos-require-partitions-to-be-aligned-at-a-cylinder-boundary#comment111998_31032 , EDR-DOS's extensions of the SFT entry structure for FAT32 and FAT+ are cleaner than MS-DOS v7.10's and FreeDOS's for FAT32, and don't re-use sharing offset or sharing next SFT pointers, so the appropriate share.exe structures could be used without changes. (MS-DOS share.exe never seems to walk SFTs on its own, using the 2F.12 DOS internal function for that instead. So it is hardened against larger SFT entries, and DR-DOS share.exe likely is too.) There is a problem with at least one of the hooks, MS-DOS's sharer may decide to reset the two "current cluster" fields of an SFT. If this is true of DR-DOS's sharer as well then it should be patched for proper operation with FAT32 EDR-DOS kernels. (Aside: The cleaner SFT extension in EDR-DOS means that at DOSDATA:CCh there live only 3 SFT entries, not 5 like in MS-DOS and FreeDOS.)

Search for "clus" in here https://hg.pushbx.org/ecm/msdos4/file/796bf2a276d3/src/CMD/SHARE/gshare2.nas to see the uses of cluster fields of the SFTs in the MS-DOS v4 sharer.

This sharing / SFT thing sounds interesting. I wonder if the WfW 3.11 VSHARE.386 problem [1] might be connected to this. Definitely worth checking out. Will be for the next year, I think. VSHARE.386 is 14K in size. I will try to do a little reverse engineering on this to find out how it works. Win 3.11 debugging. I have the feeling this one will be a rabbit hole :) ... [1]: https://github.com/SvarDOS/edrdos/issues/126

It worries me when Liam told about no disk check utility working on SavrDOS by default. It can be a serious issue.

There is CHKDSK in the base installation. This works for FAT-16. It would be great to have a working FAT-32 filesystem checker. Sadly, all the tools "on the market" require a 386+ and DPMI. This is because the FAT of a FAT-32 filesystem may become quite large, and the current tools require the FAT being in memory as a whole while performing the consistency checks. There are some thoughts about a new FAT-32 CHKDSK. So chances are not zero that this eventually will be resolved.

> It worries me when Liam told about no disk check utility working on SavrDOS by default.

As Bernd stated already, this is about the lack of a FAT32 disk check utility. The reason being that there is no such (free) tool compatible with 8086. There is a bugz issue about this: https://github.com/SvarDOS/bugz/issues/29 Mateusz