> >> 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 co
Hi Tom,
> 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.
Qui
>> 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 compatibil