>> support still is larger and slower than a 386 kernel on 386, so >> you are just needlessly tempting 386+ owners to run extremely >> retro-compatible, less optimized kernels ;-) Also, FAT32 is not >> just a module which could easily be unloaded, it is the entire >> set of MS DOS 7.10 compatibility things compared to MS DOS 5/6 >> and using 8086 FAT32 kernels wastes a lot of memory on the 99.99% >> of PC-XT which have less than 2 GB disk size, while using 8086 >> kernels of any type on 386 or newer CPU is generally not cool.
> Oh, I just meant for the 8086 kernel. > And yes, without that being the intent prior to creating the support for > FAT32, it would probably be a major pain to restructure it into an > easily loaded/unloaded driver. some facts, from my head, and 19 years old. your exact mileage may vary, depending on compiler, 86 or 386, but the general outline should be still correct. FAT16, FAT12 and FAT32 code are the mostly the same; there is no separate FAT32 driver. there is some code for FAT32 where FAT32 is really different from FAT16/FAT12. most of the size increase (~3,5 K) is because a CLUSTER is no longer 16 bit, but 32 bit as required for FAT32, so the code can be used for both FAT16 and FAT32. some size increase (~1,5 K) comes from actual FAT32 specifics, that at least theoretically could be unloaded. a hugely better investment of programmer time would be to teach FreeCOm to swap to disk (instead of swap to XMS), reusing the code for XMSSwap. probably easier, and easier to debug (it's a mostly normal program) for the benifit of 60+K instead of ~1K. still, my personal opinion remains: if a virtual PC allows 8086 CPUs, it should give them 256 KB memory and at most 20 MB disk space and at most 8 MHz performance. 8086 PC's are museum pieces, and should be running MSDOS 2.01 or whatever they happen to have installed. Tom _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
