>> 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.
Just in case you're talking about the extended SFT: I'll use a FAT32-extended SFT (probably compatible to EDR-DOS's extensions for FAT32) even without FAT+. Somewhere *at least the beginning cluster* of the file has to be stored, and the MS-DOS SFT provides no space for the high word of a 32-bit cluster value. If programs assume the SFT size of MS-DOS these can be used with FAT16 kernels which don't extend the SFT. As mentioned previously, redirectors are not affected by larger SFTs since they get passed only pointers to the SFT by DOS. (BTW, the funny Windows method to detect the SFT size which involves opening CON five times will be supported like in MS-DOS 5+ by writing the CON strings with the correct displacement into low memory, below the kernel code at segment 70h.) > 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. DVD/BRD and partition images. > Also - do not overestimate the number of developers we have. I don't. That's the reason I said "seemingly some people". I criticized your attempts to proceed the forking of the kernel. Even though some features might not be considered "stable" they could be integrated into the "trunk" build but disabled by build options for the official "stable" release. (As the Win3.x compatibility patches are in the latest "unstable" version, requiring the option to be enabled to build the "winkern".) > I have > the feeling that you love adventure and features, Yes, in a way. Another good reason not to develop "the" FreeDOS kernel. I guess I'm not that much into "stable", but don't want to work on a program which is basically just a fork either. > Or, of course, add more fancy things, such as FAT+, to unstable ;-). I've solid plans to add "fancy things" such as proper FAT32 and LFN support, file sharing, advanced memory tweaking and FAT+ to RxDOS. I can't work on your C kernel thingy as well, but would enjoy helping you by pointing out bugs and such. >> On the other hand, you've a point here. Why tie 4 GiB file size >> support to FAT+? > > You misunderstand me :-) Err, no? > 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 [...] This is exactly what I said. "Why tie 4 GiB file size support to FAT+?" == "You should support file sizes up to 4 GiB even if you don't support FAT+." >> 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... The kernel and boot sector could be modified so the kernel could use the boot sector's code to load more files from the root directory (only). > 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. With the above solution, the "full" driver COULD go into the kernel. It doesn't HAVE to, just as I mentioned the kernel actually doesn't have to contain FAT drivers to be loaded by a FAT boot sector. You could also replace the "kernel uses boot sector's code" by "kernel provides code for same access method as boot sector", which then is the same as what you suggested (minimal driver in kernel, but nothing more). Another solution would be to expand the kernel file by a small boot disk image that fits in low memory along with the kernel itself. The boot sector won't have to know about this image, it just loads a very large kernel file. I think you suggested something similar previously. >>> 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... You might argue apps could detect FAT32 drives as FAT16 due to different DPB, but how is that related to FORMAT? I'll tell you: It isn't at all. Also, it's very bizarre to say a FAT32 app (that walks DOS internal data instead of calling Int21.32 and Int21.7302, doh!) would think that a drive is FAT16 because the "free clusters" value read by the app is that read by FAT16 apps as well. FAT32 is of course not detected by checking the "free clusters" value (because the number of free clusters could easily just be below 64 Ki) but instead by checking whether the "root directory size" or "number of FAT sectors" (word) field of the FAT16 DPB is zero. > 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 :-). The FORMAT thing IS related to 128 or 256 sectors per cluster values because only this way you get large FAT16 file systems. >> 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. On Int21.7302, if the size of the buffer is that for MS-DOS EDPBs, the same data as for MS-DOS 7.10 is returned. >> 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... Might as well add that volume ID field to RxDOS 7.30 again ;D (BTW, *does* PTS-DOS have a larger DPB?) >> 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. Well. But what about the DR-DOS detection code not used to detect EDR-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"... YES it was. Mine as well... >>>>> 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. ... see? >>>>> 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?? Which app crashes from running on a FAT+ kernel? (Presuming you don't even have that large files, or that the app doesn't access these files.) Excluding low-level disk utilities such as defragmenting or disk checking programs of course, because EVERY new or extended filesystem breaks them. Note also that the FAT+ specification provides a method to avoid access by low-level programs or operating systems which don't know FAT+ on FAT32 filesystems by setting the version number to 0.1. DOS-C's FAT+ support could be set by default (if the build option for that support was enabled at all) to support/create large files only on drives with the version number set that way. Since DOS-C doesn't (yet) support FAT16 file systems larger than 4 GiB, FAT16+ is no option anyway. Regards, Christian ------------------------------------------------------------------------------ Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects _______________________________________________ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
