>>> The main bug/feature that I plan to work on is FAT+ support, >>> the working with 4GB files goes along with this since it adds >>> support for 4+GB files. > >> Please keep this out of production kernels. > > I agree - modifying FAT to support files > 4 GB is asking > for trouble. Of course you can add it to the unstable > branch so people can try it there nevertheless...
Uhm, now that seemingly some people are working on the kernel again, it's good to proceed the forking? I agree that FAT+ support is controversial, but it doesn't have to be build into unstable only. This would just differentiate unstable more from stable again. I plan on implementing FAT+ as optional feature not included in the default kernel. Even a kernel compiled with FAT+ support could be configured (via *CONFIG.SYS or online configuration utility) to deactivate the ability for any or specific drives. EDR-DOS users might patch/hack/... their FAT32+ drives to contain a filesystem version of 0.1 if they want the DOS-C kernel with FAT+ support to recognize the drive immediately. > Support for files between 2 and 4 GB size, on the other hand, > is very well-defined, compatible and safe to add, I already > have some notes about which knobs need fiddling for that :-). On the other hand, you've a point here. Why tie 4 GiB file size support to FAT+? You (all kernel developers, not necessarily Eric) could write that first, and then someone might proceed to add FAT+ support. >> this involves the risk of breaking stuff inside the kernel, and is >> not (and never will be) supported of any other operating system. > > If you ask me, it would be even better to have a MINIMAL (eg only > readonly, only root directory) ISO9660 / EXT2 / NTFS / whatever > driver in the kernel and load a separate full driver for that file > system later. Well, that's almost what DOS-C currently does. The "minimal driver" here is the boot sector which loads the kernel file. The kernel then continues to access the same filesystem with its own FAT drivers, but it doesn't necessarily have to access the same drive/filesystem as the boot sector because the FreeDOS boot sector fortunately loads the full kernel file. >>> EDR already supports this. >> who cares ? > > My personal opinion that some recent filesystem tweaks in EDR DOS > are a big pain for lowlevel tools... For example EDR DOS might try > to "play nice" for FAT16 apps and as a side effect lure FORMAT into > making "8 GB almost-FAT16" filesystems when it tries to hide FAT32. Err, what? Please explain that better. Even if EDR FORMAT does create FAT16 filesystem with "long" (128 sector) or "long long" ;) (256 sector) clusters by default, where is the problem? Low-level tools should make sure that the "sectors per cluster" field of the BPB/DPB is valid. If they don't support large clusters they would detect values 128 and 0 as invalid then. If they don't check the field, that's not EDR-DOS's fault. > Another example are EDR-specific extensions of the FAT32 BPB that > make it necessary to modify DEVLOAD to work with EDR DOS etc ;-). First, there are no EDR-specific extensions to the BPB, you're talking about the DPB here. (The difference is important!) Second, 4 of 6 additional bytes are required for better FAT16 MS-DOS compatibility, and the EDR-DOS DPB will be fixed so that the LAYOUT will match that of FAT32 MS-DOS. Getting the correct DPB size is not as difficult, really, and should *not* be limited to "hack for EDR-DOS only" because other DOS versions might use larger DPBs too. (Should I add a few bytes beyond the normal DPB just for the argument? Nah.. Notice however that previous RxDOS versions additionally stored the volume ID in the DPB for good reason.) And since you mention only EDR-DOS's "tweaks" requiring a better DEVLOAD, shouldn't I add that DEVLOAD already contains handling for some DR-DOS oddities and therefore contains proper DR-DOS detection code anyway? (This code however isn't used to detect EDR-DOS in DEVLOAD, *that* code completely relies on unreliable (via CONFIG.SYS settable) MS-DOS version values.) I'll answer to the initial reply and to Eric's other mail here, too: > I THINK you could make some components "compile time omitable" > but I also think that "support only OW" is a risky idea as you > will still need drivers and drivers typically are what forces > you to include and keep all sorts of compatible cruft. Well, if he meant only the kernel then that's probably no problem. At least I didn't see any driver "plug-ins" delivered as source for DOS-C recently. >>> Anyway, my future work on the dev branch is now done as a separate >>> project (I call it the DOS-C kernel as opposed to the kernel discussed >>> on this list, the FreeDOS kernel). Uhm, don't you want to search a new name? ;-) I still* like calling the kernel DOS-C, since "FreeDOS kernel" sounds like it was designed to be just this. And calling it "the kernel" sounds like there are no other DOS kernels (commercial or "Free") around. * That doesn't really apply. I just like to call it that way, even though no one did anymore when I heard of FreeDOS. >>> basically my >>> intent is to only support OW so I can simplify some of the code I support that decision. I would prefer if that would be done for the current DOS-C (FreeDOS kernel), too. >>> may break some backward compatibility, hence the spin off. Yup, some people prefer to exactly re-create MS-DOS instead of allowing new features. Regards, Christian ------------------------------------------------------------------------------ The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com _______________________________________________ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
