Ex-FAT support instead of FAT+ or FAT32+?? This idea seems more good like FAT+ instead :-)
And how is the support for Windows 3.1 / 3.11? ----- Original Message ----- From: <freedos-kernel-requ...@lists.sourceforge.net> To: <freedos-kernel@lists.sourceforge.net> Sent: Thursday, May 14, 2009 10:26 PM Subject: Freedos-kernel Digest, Vol 29, Issue 1 > Send Freedos-kernel mailing list submissions to > freedos-kernel@lists.sourceforge.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.sourceforge.net/lists/listinfo/freedos-kernel > or, via email, send a message with subject or body 'help' to > freedos-kernel-requ...@lists.sourceforge.net > > You can reach the person managing the list at > freedos-kernel-ow...@lists.sourceforge.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Freedos-kernel digest..." > > > Today's Topics: > > 1. Re: Hello again (Christian Masloch) > 2. Re: Hello again (Pat Villani) > 3. Re: Hello again (Eric Auer) > 4. Re: Hello again (Kenneth J. Davis) > 5. Re: Hello again (Eric Auer) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 14 May 2009 13:45:45 +0200 > From: "Christian Masloch" <c...@bttr-software.de> > Subject: Re: [Freedos-kernel] Hello again > To: freedos-kernel@lists.sourceforge.net > Message-ID: <op.utw4ajfez9d...@isor> > Content-Type: text/plain; format=flowed; delsp=yes; > charset=iso-8859-15 > >>>> 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 > > > > ------------------------------ > > Message: 2 > Date: Thu, 14 May 2009 10:37:53 -0400 > From: Pat Villani <wb2...@gmail.com> > Subject: Re: [Freedos-kernel] Hello again > To: freedos-kernel@lists.sourceforge.net > Message-ID: > <532d03b50905140737uaf23636n616bf37b17cf9...@mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > OK, let me chime in on this. Jim and I had several conversations on > topics like this before I took over. I want to share the current > thinking. > > We, as a group, have made a significant impact on the open source > community and computing in general. This is something we need to keep > in mind as we move forward, because there are people out there who > depend on good ol' DOS functionality. On the other hand, we can't > stand still because if we do, the project dies. > > Let me present the broad road map that exists at this time. The > current release will continue along with better compatibility, > possibly including running pre Win2K Windows, a new installer, > formalizing a FreeDOS GUI, and of course bug fixes. We will start a > new development branch that will remove the 8086 restriction, expand > processor coverage, file systems, etc., and allow us to move FreeDOS > forward. > > We will be developing this road map over the next couple of weeks. It > is for this reason that I started this thread. I ask that all of you > continue to provide constructive input so that we can start working on > new stuff and have some fun while we're doing it. > > Pat > > > -- > > Amateur Radio Station: WB2GBF > U.S. Army MARS station: AAR2BY/T > > > > ------------------------------ > > Message: 3 > Date: Thu, 14 May 2009 18:38:56 +0200 > From: Eric Auer <e.a...@jpberlin.de> > Subject: Re: [Freedos-kernel] Hello again > To: freedos-kernel@lists.sourceforge.net > Message-ID: <4a0c4920.3020...@jpberlin.de> > Content-Type: text/plain; charset=ISO-8859-1 > > > 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 > > > > > > ------------------------------ > > Message: 4 > Date: Thu, 14 May 2009 15:31:13 -0400 > From: "Kenneth J. Davis" <jere...@fdos.org> > Subject: Re: [Freedos-kernel] Hello again > To: freedos-kernel@lists.sourceforge.net > Message-ID: > <6d5c4c5e0905141231w266f1fbdybef25dc3fd59a...@mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > On Thu, May 14, 2009 at 12:38 PM, Eric Auer <e.a...@jpberlin.de> wrote: >> >> Hi Christian, >> >>>>>> The main bug/feature that I plan to work on is FAT+ support, > ... >> 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 > > There are no longer multiple active branches, there is only trunk. > >> because the latter would be severely incompatible with everything. > > Please move any discussions of FAT+ to a different topic (so its > easier to follow), but let me just clarify I grouped them together > because my main point is to ensure the kernel behaves stable and > predictable when encountering files > 2GB. I never mentioned adding > any destabilizing or incompatible functionality - support means to not > corrupt data nor crash nor otherwise behave odd. I will refrain from > further discussion as I had a large part in the FAT+ specification. > >> > ... >>>>>> 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. >> > > There are good reasons to support multiple compilers, the more > compilers supported the more chance of unnoticed bugs/warnings being > found and more chance others will contribute if they can use the > compiler they are familiar with. > However, supporting more compilers means more chance changes will > break (runtime or compile time) builds with one of the lesser used > compilers so requires more resources to verify changes work across the > board and can limit features used to what is available across all tool > chains. > > Jeremy > > > > ------------------------------ > > Message: 5 > Date: Thu, 14 May 2009 22:26:26 +0200 > From: Eric Auer <e.a...@jpberlin.de> > Subject: Re: [Freedos-kernel] Hello again > To: freedos-kernel@lists.sourceforge.net > Message-ID: <4a0c7e72.3030...@jpberlin.de> > Content-Type: text/plain; charset=ISO-8859-1 > > > Hi Jeremy, > >>> 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 >> >> There are no longer multiple active branches, there is only trunk. > > Trunk is stable, but there also is devel / unstable: > > http://freedos.svn.sourceforge.net/viewvc/freedos/kernel/trunk/ > > http://freedos.svn.sourceforge.net/viewvc/freedos/kernel/branches/UNSTABLE/ > > The problem is that there were almost no changes in UNSTABLE in > the last 3 years, so it will need "undusting" before it can be > useful for new experiments. I suggest to put the main focus on > careful, non-experimental bugfixes for trunk for the moment. > >> Please move any discussions of FAT+ to a different topic > > I agree :-) > >> because my main point is to ensure the kernel behaves stable and >> predictable when encountering files > 2GB. I never mentioned >> adding any destabilizing or incompatible functionality > > Then this FAT+ thing sneaked in... It is indeed unrelated to > the topic of support for files sized between 2 and 4 GB :-) > >>>>>>> intent is to only support OW so I can simplify some... > >> There are good reasons to support multiple compilers... > > Ohhh I smell a misunderstanding :-) I had assumed you or Pat > were planning to make a fresh minimalistic start with a DOS > kernel that can only RUN OW. This is partly because there is > another DOS clone which was actually made to be good enough > to RUN Borland compilers, too :-). > >> the more compilers supported the more chance of unnoticed bugs >> or warnings being found and more chance others will contribute > > Interesting point :-) > >> However, supporting more compilers means more chance changes >> will break (runtime or compile time) builds with one of the lesser > > True... Still worth trying ;-) > > 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 > > > End of Freedos-kernel Digest, Vol 29, Issue 1 > ********************************************* ------------------------------------------------------------------------------ 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
