SvarDOS
Making FAT+ support optional, SFT changes
I am thinking about making FAT+ support optional by introducing a build flag FATPLUS (in fact I already started doing it). I saw that the SFT entries can then be modified by removing some 32-bit high parts of the 64-bit values introduced to support files larger than 4GB, namely DHNDL_SIZEX and DHNDL_POSX.
https://github.com/SvarDOS/edrdos/blob/acbbd883bda4ae9f4a4bc0cbed2b1d3aadfb8874/drdos/doshndl.def#L118-L126
I noticed that when removing these fields there are still differences in the SFT layout of the EDR kernel and the FAT32 enabled FreeDOS kernel.
While thinking about the SFT layout I questioned myself if there is already some documentation about how the SFT entries look under FAT32 enabled MS-DOS versions. Until now I only found the layout for DOS4+. Does perhaps the FreeDOS SFT match the FAT32 enabled MS-DOS one? Then I could use that as a reference.
As there seem to be some incompatibilities likely caused by the SFT differences, it would be beneficial if the SFT layout would match that of the FAT32 enabled MS-DOS versions. However, that may be a medium to long term goal, as the EDR kernel seems to make heavy use of some values like DHNDL_BLK1H, DHNDL_IDXH, DHNDL_DBLKH, DHNDL_BLKH. Also, some locations of the source code depend heavily on the order of the fields (mainly movs etc. when copying / filling in SFTs), making re-ordering the fields non-trivial.
So I see this a a two-step process. 1) making FAT+ optional and 2) in a next step apdapting the SFT structure further to make it more compatible. While 1) can be acomplished with reasonable effort, 2) would be more elaborable...
I have written about this before but yes, FAT32 enabled FreeDOS seems to mirror MS-DOS v7.10 SFT layout. (Unlike the UPB/BDS/DDT/UDSC where FreeDOS iirc isn't compatible to MS-DOS.)
I prefer EDR-DOS's extensions to the SFT layout actually as they are cleaner. The FreeDOS one re-uses at least one of the words reserved for the sharer in MS-DOS v4 to v6, which is one reason the sharer of these versions is incompatible with MS-DOS v7.10.
Other than the SFT layout extensions, if FAT+ is disabled you can also drop support for all the 21.71 subfunctions that EDR-DOS supports as these are purely for the larger possible file sizes, including LFN Find First/Next, LFN File Handle Info, and of course the 64-bit seek function 7142h introduced by EDR-DOS.
https://github.com/SvarDOS/edrdos/commit/6f90911256b5a24b453a151aa998c8b6f4b44202#diff-6599a6a49847d664e4417ff2bf7aa6e9b1a69c16dd2164e46624867aae54f23bR884 this probably should not be disabled for the non-FAT+ build.
what would be the advantage of not having that feature enabled ? (and is FAT+ identical to FAT32?)
what would be the advantage of not having that feature enabled ? (and is FAT+ identical to FAT32?)
FAT+ is a highly incompatible extension to FAT16/FAT32 to allow files larger than 4GB. As this is not supported by any major OS, chances of a data loss when editing such files under a non FAT+ enabled OS (basically anything else than the EDR kernel) are high.
what would be the advantage of not having that feature enabled ? (and is FAT+ identical to FAT32?)
Advantage is smaller SFT layout, more compatible SFT handling, and saving some amount of (DOSCODE/drdos) code space.
FAT+ is an extension to allow file size of up to 38 bits rather than 32 bits. This raises the file size limit from 4 GiB - 1 Byte to 256 GiB - 1 Byte. This requires to use 6 bits of the DOS directory entry for the on-disk size field extension, and extensive reworking of DOS internal structures (chiefly the SFT as Bernd mentioned) to add support for 38 (or 64) bits for file sizes and seek offsets. The specification is archived at https://web.archive.org/web/20150219123449/http://www.fdos.org/kernel/fatplus.txt (You can find this link as a source on the english Wikipedia article for FAT FS.)
FAT+ is typically used on FAT32 drives, but on large FAT16 drives (exceeding 4 GiB in size) you may also encounter FAT16+. With 512 Bytes per sector, and FAT16 limiting things to < 64 kilo binary clusters, only EDR-DOS extension style 256 Sectors per Cluster (ie, 128 KiB per Cluster) FAT16 file systems may have use for FAT16+ as they may exceed 4 GiB in total file system size.
You can drop FAT+ support while still supporting FAT32.
What exactly do you mean? Your link seems to show the whole commit diff?
I meant to link to some of the drdos/utils.fdo hunks. Deleting LFNs and detecting LFNs as not representing non-emptiness for RMDIR are probably useful convenience features not directly linked to FAT+.
(I think lDOS's RMDIR tries detecting non-empty directories by opening(?) or findfirsting(?) files in the directory, which treats both LFNs and volume labels as not representing any actually used directory entries so it "just works". But that was something I specifically had to check to make sure orphaned LFN entries do not prevent RMDIR.)
Deleting LFNs and detecting LFNs as not representing non-emptiness for RMDIR are probably useful convenience features not directly linked to FAT+.
Re-enabled for the non-FAT+ build via https://github.com/SvarDOS/edrdos/commit/2c9076548ef421f151b12a35d7c6531a3113c255.
FATPLUS branch is merged into MAIN. FAT+ is disabled by default. The 64-bit SFT field extensions are not included in the non-FAT+ build.