Hi Christian, >>>> 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. Sorry but it IS an unstable feature, actively breaking compatibility. Of course you can implement it in a way that makes it easy to port but honestly - I think changing several data structures into NON DOS compatible variants is a very bad thing to plan for a "stable" patch. And again: Tell me ONE thing where you want files above 4 GB size and where you have more than a single app that would use them, as that single app can just as well split the big data over N files. Also - do not overestimate the number of developers we have. I have the feeling that you love adventure and features, so I would say it would be a good idea if you start by completing the technical overview page of the unstable branch. Then you can do several things...: Find suitable patches for backporting to stable. Help with that "third kernel branch". Do careful review of the "too experimental" patches and help on the long road to making unstable more stable again. Or, of course, add more fancy things, such as FAT+, to unstable ;-). The technical overview of the unstable branch wiki page is here: http://apps.sourceforge.net/mediawiki/freedos/index.php?title=Unstable_Kernel_Branch > On the other hand, you've a point here. Why tie 4 GiB file size > support to FAT+? You misunderstand me :-) Of course we should support files of 2-4 GB size in the STABLE kernel very soon! Just do not support ABOVE 4 GB because the latter would be severely incompatible with everything. >> 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... That is not what I meant... The boot sector loads only the kernel. A minimal built-in driver would be able to load FURTHER drivers from a non-FAT filesystem, such as NTFS4DOS or EXT2 drivers... Note that it would be bad to have those linked into the kernel binary - they are way too big for that and there are license issues. >> 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. To explain: EDR DOS tries to return "as FAT16 style as possible" data even for FAT32 filesystems, to make life easier for lowlevel (!) DOS apps of the old times which do not know FAT32 yet. This has the bad side effect that apps might actually believe that the drive really IS FAT16 but of course then you get miserable failures of OTHER lowlevel tools... Note that this is not related to support for 64kB and 128kB clusters, even FreeDOS supports 64kB clusters although I strongly suggest to use FAT32 in cases where you would need 64kB clusters for FAT16 :-). > 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 I am talking about the int 21.7302 FAT32 DPB. Instead of that compatible structure, EDR DOS uses a strange modification of the FAT16 DPB, related to the reasoning mentioned above. You cannot improve FAT16 MS DOS compat of what actually is a FAT32 filesystem because FAT32 just is no FAT16. Or to put it in other words: If you make the trunk of an elephant look like a cat, it might smell though the cat door but it will still break your house when the rest of the elephant follows, so you better keep the elephant looking like an elephant :-p. > should *not* be limited to "hack for EDR-DOS only" because other DOS > versions might use larger DPBs too... Name one... One that is reasonably compatible, that is. Not PTS-DOS... > 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? Actually I had hoped DR DOS would eventually grow *more* compatible so devload could be simplified at the cost of only supporting new DR DOS. >> I THINK you could make some components "compile time omitable" >> but I also think that "support only OW" is a risky idea as... This was a comment on the "third branch"... >>>> 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. In what way would it make FreeDOS better if we make it crash MORE apps?? Eric ------------------------------------------------------------------------------ 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
