Re: [Freedos-kernel] Hello again
Hello, 2009/6/14 Eric Auer e.a...@jpberlin.de: Hi Aitor, I support this idea, but that means that odd numbers (2039) would go unstable. Actually Bart already ported country sys support from unstable, combining it with built-in country support. He is also working on f-node free operations in stable. This means that version 2039 will be the next version of stable. Ok, I got that (I still have some more mails to read). I think it also means that we will gradually port more things from unstable into the stable branch, but have no new unstable versions (-numbers) to be released in the next few months. It would be good to update the wiki page about unstable here... http://sourceforge.net/apps/mediawiki/freedos/index.php?title=Unstable_Kernel_Branch ...to have a better view on which features are port-worthy. Good idea, feel free to commit yourself for it... I agree that the freedos distro should by default include the stable branch of the kernel :-). Note that the discussion in mid-may was about experimental filesystems. I still think it would be better to play with those only in the unstable branch. That branch can serve as testing ground for experimental things and as a pool for carefully (!) porting features into stable. Of course it would be useful to port some updates from stable to unstable first, to make the unstable branch more useable. Good. But then my question is: how is unstable versioning going to be handled? Aitor -- 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
Re: [Freedos-kernel] Hello again
Hi Aitor, I support this idea, but that means that odd numbers (2039) would go unstable. Actually Bart already ported country sys support from unstable, combining it with built-in country support. He is also working on f-node free operations in stable. This means that version 2039 will be the next version of stable. I think it also means that we will gradually port more things from unstable into the stable branch, but have no new unstable versions (-numbers) to be released in the next few months. It would be good to update the wiki page about unstable here... http://sourceforge.net/apps/mediawiki/freedos/index.php?title=Unstable_Kernel_Branch ...to have a better view on which features are port-worthy. I agree that the freedos distro should by default include the stable branch of the kernel :-). Note that the discussion in mid-may was about experimental filesystems. I still think it would be better to play with those only in the unstable branch. That branch can serve as testing ground for experimental things and as a pool for carefully (!) porting features into stable. Of course it would be useful to port some updates from stable to unstable first, to make the unstable branch more useable. Eric -- 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
Re: [Freedos-kernel] Hello again
I support this idea, but that means that odd numbers (2039) would go unstable. I guess that on view on this FD 1.1 should have 2038 ( or 2040 if there's such thing by the release time). Aitor 2009/5/18 Bernd Blaauw bbla...@home.nl: Eric Auer schreef: Still no reason to add experimental things to stable now :-) The solution is easy: Add it to the UNSTABLE fork and, while doing so, show that there are people who are interested in new experiments with DOS! This will also draw more attention to this branch and make it more likely that safe goodies can be found in there and ported to stable and that on the other hand UNSTABLE will finally get updated with some of the fixes that stable received in the last few years... :-) Leave 2037 as a relic, go fork 2038 to add your experimental issues and make them appear in 2039 or 2040 :) Additionally, take things from 2037 as you like I guess. Seems rather strange to have a decent 2038 now, and then to have to resort to changing 2037 if you want to add experimental features. -- 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 -- 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
Re: [Freedos-kernel] Hello again
Still no reason to add experimental things to stable now :-) The solution is easy: Add it to the UNSTABLE fork No. Because first, I don't develope DOS-C, and second, forking is bad and makes merging changes back in harder. Since your opinion seems to be that filesystem extensions can never be added to the stable or official release, this is of course what you want to happen to them: Implement it into unstable and it will never find it's way to stable. The problem here isn't just that you don't want to release new features in official builds, it's that you support forking another single build (which, by now, is already years behind in improvements of stable - see below why) instead of adding the feature to (unofficial) builds directly derived from the latest stable. Of course that's just my opinion and I'm not even a FreeDOS developer, so feel free to ignore it. At least I didn't yet see anything changed in stable which was derived from unstable Actually not much apart from COUNTRY SYS support in unstable has very favorable risk/complexity versus gain in features ratio at the moment, unfortunately... So why write a risky feature at first, if there's apparently no chance it will be merged to stable? Additionally, this raises the problem that people that want to write new features into unstable first will have to cope with a kernel already full of other unstable features. So I won't recommend re-using the outdated unstable anymore. , and improvements of stable aren't added to unstable either. This is because more or less the only developers were Jeremy, Lucho and Arkady - the latter is kind of missing and Jeremy just returned a few weeks ago from being so busy with the real world real life that he simply had no time to continue working on the unstable branch. Lucho now has other big things as 4DOS. I'm of course not blaming these people. However, as I mentioned previously, if all developers of stable had merged their changes (as applicable) to unstable as well, this would make life easier for people that want to test new features for stable on unstable. (And please don't argue that the developers of stable would have to know unstable then, too, because they of course should do if it's more than a fork.) If they were IFDEFed then you would have no chance understanding either ;-). I doubt I would have a problem with it if the source was divided that way. What do you mean by either? The stable / unstable diff is maybe 1000s of lines. Could it be smaller if the changes in stable were added to unstable? [...] because I prefer to write such programs in Assembler. In a way, I want to change everything compared to DOS-C (The FreeDOS Kernel) which is written in a high-level language, and that's the reason I choose not to develop it. Tastes differ. One of the original goals with DOS-C was using more C :-) I know. and that's the reason I choose not to develop it. If you repeat answering that DOS-C tries to use C as much as possible I can repeat to write my answer again ;-) Still you are welcome to point out tech details of bugs if you find them, as we often have only vague it somehow does not work type bug reports and no time or hardware/software to reproduce/debug them. Of course ;-) 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
Re: [Freedos-kernel] Hello again
Indeed JAM only works on non-FAT32 kernels because of different data structures... Any other different structures besides the SFT? JAM apparently needs the start cluster of the compressed disk file so it can use lowlevel (int 25/26...?) calls to access that file without causing reentrancy while the kernel accesses files on the compressed disk :-). Ignoring the fact that it apparently broke SHARE.EXE, too Our version of share? Does it work less well on FAT32 aware kernels? Nope, here I talked about the MS-DOS SHARE.EXE only problems of MS-DOS 7.10+ only. That'll make jmount incompatible with MSDOS4, DRDOS 56, but compatible with newer versions, because the word at 35h is the last accessed cluster, and after reading one sector (as Eric showed) that will still be the starting cluster. patching JMOUNT [...] is not elegant, but that is a typical problem with closed source software :-p Anyone tried to contact the JAM developers before patching the binaries? Does JAM read anything from the archive file (I presume it wants the first cluster of that file) before looking into the SFT? It does the following: Drive reset, network flush buffers, check if drive is remote, check for DJ mechanism state, for dblspace, for JAM drive properties, truename, more JAM drive properties. Then it checks the DPB of the drive with the JAM compressed disk file on it, OPENs that. Then dosdebug/dosemu logged that a first disk sector read happens, not sure why. Next JMOUNT seeks to: current +0, end +0, start +0. Now JMOUNT reads the first sector of the compressed disk file. Then it checks the JFT and SFT to, indeed, get the start cluster of the compressed disk file :-). Does it parse the JFT and SFT chain directly or does it use DOS services such as 2F.1220 and 2F.1216 ? I am not sure whether DOS would already read the next cluster when you read the first (size of cluster) bytes of a file, I would guess it will not... It *could* read the value of the next cluster from the FAT (value inside the FAT entry of just-read cluster) but that could also result in an EOF marker so I guess you're right. FreeDOS already does exactly that - as soon as any int 21 call is done, the SFT is updated with information from the fnodes where necessary. Only if an outside software would WRITE to the SFT you could cause problems because this might get the SFT out of sync with the fnodes: FreeDOS might have information stored in the fnodes which the outside software which manipulated the SFT will fail to update if it does not know about fnodes. But is the fnode re-used for the next DOS call, or is it populated from all values found in the SFT again? Because, if the former is true, then the cluster reference would be lost as soon as another call used the fnode for another file. And if the fnode was repopulated from the SFT on each DOS call, then if whatever program changed the cluster references in the SFT would also change the fnode indirectly (if it accessed the SFT when the InDOS and CritErr word was zero). Maybe extremely lowlevel software such as task swappers or such unimaginable things as online defragmenting software ;-) could cause problems here, but JMOUNT should be safe :-). Ack. 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
Re: [Freedos-kernel] Hello again
Actually MSDOS 7.10 already uses the SFT in a different way, but undocumented by RBIL, for both FAT16 and FAT32: 0BhWORDcontains the high word of the relative cluster number at offset 19h 2BhDWORD contains the starting cluster number 35hDWORD contains the current cluster number Interesting. How this interacts with SHARE.EXE: I have no idea Probably the main reason it doesn't work with MS-DOS 7.10. This was just obtained by writing a program that dumps the SFT after opening a large file and reading 7*4k into it on a FAT32 partition with 4k clusters. Good work! I verified RBIL's statement that the word at 0Bh was not used by checking it for files located on a FAT12 and FAT32 drives. It contained a seemingly random value which lead me to the wrong assumption MS-DOS just didn't properly initialize it. However I don't think I'll copy this strange behaviour (at least not by default). As reported by Eric, it breaks programs like JAM (the point is, even on FAT12 and FAT16 disks) which look into the SFT to get the first cluster of a (FAT12 or FAT16) file. 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
Re: [Freedos-kernel] Hello again
Hi Christian, I think that you are not being polite. You are new here and you start by wanting to change everything. Why don't you start by fixing a few bugs? Alain Christian Masloch escreveu: 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. each and every general file handling program like: COPY, XCOPY, Norton/Volkow Commander, ... ZIP, RAR, ... CHKDSK (and don't tell me CHKDSK isn't important), all Norton stuff xxBACKUP while they probably won't crash, some wont to what they are expected to do. Are you prepared to check the entire ecosystem of DOS utilities if they can handle 4GB+ size files ? it's probably MUCH a better idea to teach this hypotetical blueray player to handle multiple files. that's the reason I think that 4GB+ is a real stupid idea. (Presuming you don't even have that large files, or that the app doesn't access these files.) I don't think copy or archive utilities would care if they won't access the large files. Excluding low-level disk utilities such as defragmenting or disk checking programs of course, because EVERY new or extended filesystem breaks them. I would describe CHKDSK as defragmenting or disk checking program. I mean, did you even READ my mail? It's not like you have to, but please do if you're going to answer it. DOS-C's FAT+ support could be set by default I don't care what you do to DOS-C. but the FreeDOS kernel shouldn't support FAT+ Yo, as mentioned in the previous mails, I refer to the FreeDOS kernel as DOS-C. And maybe you're right, and the FreeDOS kernel needs forking for every feature. Since DOS-C doesn't (yet) support FAT16 file systems larger than 4 GiB yes another stupid idea. , FAT16+ is no option anyway. right. Sometimes I think your mails aren't worth an answer. -- 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 -- 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
Re: [Freedos-kernel] Hello again
2009/5/18 Christian Masloch c...@bttr-software.de: Good work! I verified RBIL's statement that the word at 0Bh was not used by checking it for files located on a FAT12 and FAT32 drives. It contained a seemingly random value which lead me to the wrong assumption MS-DOS just didn't properly initialize it. However I don't think I'll copy this strange behaviour (at least not by default). As reported by Eric, it breaks programs like JAM (the point is, even on FAT12 and FAT16 disks) which look into the SFT to get the first cluster of a (FAT12 or FAT16) file. Whether you call it strange depends... I just call it a change in layout, just like one was made from DOS 3.3x to DOS 4. It's hard to be compatible to everyone... In any case JAM can be made compatible to MSDOS 7.10 on FAT16 by DEBUG (in addition to the changes discussed before): debug jmount.com edf3 35 w That'll make jmount incompatible with MSDOS4, DRDOS 56, but compatible with newer versions, because the word at 35h is the last accessed cluster, and after reading one sector (as Eric showed) that will still be the starting cluster. It won't help FreeDOS of course because it still uses fnodes for these things instead of SFTs. Bart -- 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
Re: [Freedos-kernel] Hello again
Eric Auer wrote: Once 2038 is released I plan to continue reviewing any outstanding patches and apply as appropriate. My top priority is bug fixes - repeatable bugs will probably be fixed first :-) In no particular True. One bug: MSCLIENT, but only in BASIC (without REDIR loaded) produces 1-1-1980 timestamps on the server only with FreeDOS as client. It does not happen with FULL config of MSCLIENT though. Another basic redirector bug: http://www.bttr-software.de/forum/board_entry.php?id=446#p1134 (It shows up in MS-DOS 6.22.) Robert Riebisch -- BTTR Software http://www.bttr-software.de/ -- 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
Re: [Freedos-kernel] Hello again
It won't help FreeDOS of course because it still uses fnodes for these things instead of SFTs. Those are ancient relics that should be done away with. There is no need for them anymore. I'd like to put that high on the priority list for kernel development. in theory you are right. in praxis fnodes are everywhere throughout the file system (as you probably know), and there's a reason we left them in the kernel the last few years. it's probably fairly easy to convert a stable kernel into unstable by trying to convert this. not that I wouldn't like to get rid of the fnodes (it would be a very good thing), but it's probably a non-trivial amount of work (and risk) involved with that. dont start it if you are not prepared to finish it. Tom -- 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
Re: [Freedos-kernel] Hello again
Hi Eric, Pat: It won't help FreeDOS of course because it still uses fnodes for these things instead of SFTs. Those are ancient relics that should be done away with. There is no need for them anymore. I'd like to put that high on the priority list for kernel development. Just to remind you that your conclusion about Fnodes turns out to be wrong ;-) Eric (german): Andererseits hatte FreeDOS vermutlich Gründe, F-Nodes statt erweiterte-SFT zu implementieren. Und zwar nicht nur, weil DOS-C F-Nodes hatte, bevor es SFTs hatte ;-) (translation): OTOH FreeDOS probably had reasons to implement F-Nodes instead of extended-SFT. And not just because DOS-C used F-Nodes before it used SFTs ;-) 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
Re: [Freedos-kernel] Hello again
2009/5/18 Tom Ehlert t...@drivesnapshot.de: It won't help FreeDOS of course because it still uses fnodes for these things instead of SFTs. Those are ancient relics that should be done away with. There is no need for them anymore. I'd like to put that high on the priority list for kernel development. in theory you are right. in praxis fnodes are everywhere throughout the file system (as you probably know), and there's a reason we left them in the kernel the last few years. it's probably fairly easy to convert a stable kernel into unstable by trying to convert this. not that I wouldn't like to get rid of the fnodes (it would be a very good thing), but it's probably a non-trivial amount of work (and risk) involved with that. dont start it if you are not prepared to finish it. Well, now we have two kinds of f_nodes, the near ones and the far ones. The far ones are copied to and from near ones using 4 fmemcpy's in fatfs.c Replacing the fmemcpy's by a convert fnode to/from SFT function should be able to eliminate the far fnodes. I'll give that a go. Once that's done at least some of the fatfs.c functions can be converted to use SFTs directly. Though this is not as easy as it looks because fnodes are also used as internal structures for directories. Bart -- 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
Re: [Freedos-kernel] Hello again
Hi Bart, [fnodes] are ancient relics that should be done away with. There is no need for them anymore. I'd like to put that high on the priority list for kernel development. in theory you are right. in praxis fnodes are everywhere throughout the file system (as you probably know), and there's a reason we left them in the kernel the last few years. it's probably fairly easy to convert a stable kernel into unstable by trying to convert this. There are fewer and fewer fields for which the difference SFT versus fnode still matters, so I would suggest to slowly phase out the old uses of fnodes, field by field and very carefully... Well, now we have two kinds of f_nodes, the near ones and the far ones. The far ones are copied to and from near ones using 4 fmemcpy's in fatfs.c Replacing the fmemcpy's by a convert fnode to/from SFT function should be able to eliminate the far fnodes. I'll give that a go. Once that's done at least some of the fatfs.c functions can be converted to use SFTs directly. Though this is not as easy as it looks because fnodes are also used as internal structures for directories. See above - I also think that converting frequently on the fly is not very pleasant performance and complexity wise. No need to hurry in getting rid of the fnodes, so I somehow prefer phase out style. Eric -- 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
Re: [Freedos-kernel] Hello again
On Mon, May 18, 2009 at 3:49 PM, Tom Ehlert t...@drivesnapshot.de wrote: It won't help FreeDOS of course because it still uses fnodes for these things instead of SFTs. Those are ancient relics that should be done away with. There is no need for them anymore. I'd like to put that high on the priority list for kernel development. in theory you are right. in praxis fnodes are everywhere throughout the file system (as you probably know), and there's a reason we left them in the kernel the last few years. it's probably fairly easy to convert a stable kernel into unstable by trying to convert this. not that I wouldn't like to get rid of the fnodes (it would be a very good thing), but it's probably a non-trivial amount of work (and risk) involved with that. dont start it if you are not prepared to finish it. Tom It is not too difficult - I have a kernel without them lying around suffering from bit-rot, but it did not seem to bring anything useful to warrant the changes given the likely hood of bugs it also caused; I actually prefer the fnodes. Jeremy -- 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
Re: [Freedos-kernel] Hello again
2009/5/18 Christian Masloch c...@bttr-software.de: However I don't think I'll copy this strange behaviour (at least not by default). As reported by Eric, it breaks programs like JAM (the point is, even on FAT12 and FAT16 disks) which look into the SFT to get the first cluster of a (FAT12 or FAT16) file. Whether you call it strange depends... I just call it a change in layout, just like one was made from DOS 3.3x to DOS 4. It was however not documented (well, like most things about MS-DOS 7+) and unexpected, especially because the usage of these fields (or their lower word parts) is now incompatible to previous versions even on FAT12/16 filesystems. (Ignoring the fact that it apparently broke SHARE.EXE, too.) It's all undocumented, of course :) You're distinguishing undocumented undocumented from documented undocumented... It just happens that nobody has updated RBIL. I'm not sure about unexpected because the 3.3x-4.0 change is similar, i.e. they could have left the 16bit sector counter for disks 32MB. About SHARE: http://support.microsoft.com/kb/161619 nevertheless FreeDOS has its own share which doesn't use these SFT fields. Does JAM read anything from the archive file (I presume it wants the first cluster of that file) before looking into the SFT? Also, what if it read exactly one sector (or more) but the cluster size was only one sector, either? Then it would read the second cluster instead of the first one from the SFT. I wouldn't patch the program like that if I didn't know for sure such things wouldn't happen. Of course it needs further testing, but I tested that reading a whole cluster only sets the last accessed cluster to that cluster, not the one following it. You must actually read one byte more to get that field updated. It won't help FreeDOS of course because it still uses fnodes for these things instead of SFTs. Doesn't it update the SFT relative and absolute current cluster values, too? As far as I've understood it, fnodes should be invalidated when leaving DOS, so if these cluster references were saved in the fnode only, it wouldn't help a lot. It should update those but doesn't at the moment. Bart -- 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
Re: [Freedos-kernel] Hello again
It's all undocumented, of course :) You're distinguishing undocumented undocumented from documented undocumented... Nah, here I rather distinguished undocumented changes from MS-DOS 6 to 7 and the documented ones, which were like the config.txt user documentation describing some of the changes and giving away hints as to what changed technically ;-) (So, yes, you're probably right.) It just happens that nobody has updated RBIL. I'm not sure about unexpected because the 3.3x-4.0 change is similar, i.e. they could have left the 16bit sector counter for disks 32MB. About SHARE: http://support.microsoft.com/kb/161619 Microsoft here says: In order to support the FAT32 file system, Share.exe support has been disabled in the real-mode MS-DOS kernel regardless of whether or not you have any drives using the FAT32 file system. But what it actually means: We had to re-use some fields of an internal structure for FAT32 whose size we couldn't change, and breaking real-mode file sharing seemed like something we could get away with. It doesn't even work if you aren't using any FAT32 drive! nevertheless FreeDOS has its own share which doesn't use these SFT fields. Yes. Of course it needs further testing, but I tested that reading a whole cluster only sets the last accessed cluster to that cluster, not the one following it. You must actually read one byte more to get that field updated. Thanks. This is interesting information. Doesn't it update the SFT relative and absolute current cluster values, too? As far as I've understood it, fnodes should be invalidated when leaving DOS, so if these cluster references were saved in the fnode only, it wouldn't help a lot. It should update those but doesn't at the moment. If the fnode really goes away soon, the code could be easily changed to use the fields in the SFT instead I guess. (Or not required, see other mail from Eric!) 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
Re: [Freedos-kernel] Hello again
Hi Christian, I don't want to change everything. The only extension I asked for was to support FAT+, of course in the stable (or trunk) kernel branch because unstable isn't developed by anyone currently and developing it would proceed the forking of these branches. Still no reason to add experimental things to stable now :-) The solution is easy: Add it to the UNSTABLE fork and, while doing so, show that there are people who are interested in new experiments with DOS! This will also draw more attention to this branch and make it more likely that safe goodies can be found in there and ported to stable and that on the other hand UNSTABLE will finally get updated with some of the fixes that stable received in the last few years... :-) As Udo (Kuhnt, from EDR-DOS) put it, the unstable branch was and is seen only as testing area for features that won't be added to the stable I disagree on this. There is way too little review on UNSTABLE but if you read the changelog and tech changelog, you see that also normal useful but complex features such as COUNTRY SYS support found a testing ground in the unstable branch :-). The next challenge is to review / proofread the better few of those features and add them to stable as well after that. Carefully. At least I didn't yet see anything changed in stable which was derived from unstable Actually not much apart from COUNTRY SYS support in unstable has very favorable risk/complexity versus gain in features ratio at the moment, unfortunately... , and improvements of stable aren't added to unstable either. This is because more or less the only developers were Jeremy, Lucho and Arkady - the latter is kind of missing and Jeremy just returned a few weeks ago from being so busy with the real world real life that he simply had no time to continue working on the unstable branch. Lucho now has other big things as 4DOS. Effectively unstable is forked off. Recent efforts to add some features of unstable back to stable (such as COUNTRY.SYS loading) support this: If the branches were maintained together, or even created from the same source with IFDEFs, it won't need much effort to add features from the testing branch to the official one. If they were IFDEFed then you would have no chance understanding either ;-). The stable / unstable diff is maybe 1000s of lines. Notice that I started working on a different DOS kernel (RxDOS) because I prefer to write such programs in Assembler. In a way, I want to change everything compared to DOS-C (The FreeDOS Kernel) which is written in a high-level language, and that's the reason I choose not to develop it. Tastes differ. One of the original goals with DOS-C was using more C :-) Although I'm not exactly interested in developing most of the FreeDOS programs, I did already point out a few bugs. I'm of course not fixing them myself (well, at most providing small patches) because I'm in no position to take over development of these programs. Still you are welcome to point out tech details of bugs if you find them, as we often have only vague it somehow does not work type bug reports and no time or hardware/software to reproduce/debug them. Eric -- 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
Re: [Freedos-kernel] Hello again
Eric Auer schreef: Still no reason to add experimental things to stable now :-) The solution is easy: Add it to the UNSTABLE fork and, while doing so, show that there are people who are interested in new experiments with DOS! This will also draw more attention to this branch and make it more likely that safe goodies can be found in there and ported to stable and that on the other hand UNSTABLE will finally get updated with some of the fixes that stable received in the last few years... :-) Leave 2037 as a relic, go fork 2038 to add your experimental issues and make them appear in 2039 or 2040 :) Additionally, take things from 2037 as you like I guess. Seems rather strange to have a decent 2038 now, and then to have to resort to changing 2037 if you want to add experimental features. -- 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
Re: [Freedos-kernel] Hello again
If half as much effort went into the code that has gone into this thread, we'd have rewritten the kernel several times over. Since I'm wrong about the kernel(?), let me put it to you this way. I want to put out a new release, FreeDOS v1.1 and get a plan in place. In 50 words or less, who is going to tell me which kernel is going with 1.1? Pat -- Amateur Radio Station: WB2GBF U.S. Army MARS station: AAR2BY/T -- 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
Re: [Freedos-kernel] Hello again
On Mon, May 18, 2009 at 6:32 PM, Pat Villani p...@monmouth.com wrote: If half as much effort went into the code that has gone into this thread, we'd have rewritten the kernel several times over. Since I'm wrong about the kernel(?), let me put it to you this way. I wrong? want to put out a new release, FreeDOS v1.1 and get a plan in place. In 50 words or less, who is going to tell me which kernel is going with 1.1? Pat 2039 unless a later one is available - svn trunk tagged Jeremy -- 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
Re: [Freedos-kernel] Hello again
2009/5/17 Bart Oldeman bartolde...@users.sourceforge.net: 0Bh WORD contains the high word of the relative cluster number at offset 19h 2Bh DWORD contains the current cluster number 35h DWORD contains the starting cluster number sorry, the last two are the other way around: 2BhDWORD contains the starting cluster number 35hDWORD contains the current cluster number Bart -- 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
Re: [Freedos-kernel] Hello again
2009/5/17 Christian Masloch c...@bttr-software.de: 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. Actually MSDOS 7.10 already uses the SFT in a different way, but undocumented by RBIL, for both FAT16 and FAT32: 0BhWORDcontains the high word of the relative cluster number at offset 19h 2BhDWORD contains the current cluster number 35hDWORD contains the starting cluster number How this interacts with SHARE.EXE: I have no idea This was just obtained by writing a program that dumps the SFT after opening a large file and reading 7*4k into it on a FAT32 partition with 4k clusters. 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. I think FAT+ as is (and implemented by EDR-DOS) then is still much too dangerous, because other OSes can still see it, so: * a new partition type number for the MBR should be defined (much in the same way as 32 MB FAT16, LBA etc) to avoid other (D)OSes from seeing it automatically. * normal DOS programs should not be able to open too large files. This can be accomplished by extending int21/ah=6c, another bit in BH (FreeDOS doesn't properly implement its bit 4 for files = 2Gb, 4Gb even: it opens without complaint). The difference with VFAT, and the NT lcase bit is that those were much more backwards compatible, i.e. no harmful data corruption when using such partititions with earlier DOS versions. Bart -- 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
Re: [Freedos-kernel] Hello again
Eric Auer schreef: Maybe we should have DVD playing software and a DVD- compatible version of DOSCDROAST first... :-p. And I repeat my earlier argument: Just split the bluray image into a few files, very easy :-). What's DOSCDROAST exactly? So far I'm quite happy with Blair's port of CDRKIT, with only drawback that we have to rely on drivers that we cannot supply and distribute (due to licensing matters), but that users have to provide themselves. For the IDE/EIDE/SATA/PATA/ATA/ATAPI ASPI shim, this is ASPI.SYS by Oaktech. Any opensource shim or addition to UIDE.SYS is not known to me, and at least mr Jack R Ellis isn't too much a fan of ASPI due to personal reasons so he's not inclined to add that to his driver. For other technologies, you'd usually need to load a driver for the mass storage controller (be it USB, FireWire, SCSI, whatever) which implements SCSIMGR$ blockdevice. This seems to be 3rdparty in all cases. Additionally you'd need a cd-rom driver also that chains to the SCSIMGR$. No opensource version of this is known to me, think there were plans for ATAPICDD in the past to have this. As for GENISOIMAGE (mkisofs basicly, creates ISO out of directory tree) I've finally found the -split-output option, which should result in FDBASECD.0[01..99], consisting of 1GB files each, I think, rather than FDBASECD.ISO The, through ASPI/SCSI, recording software WODIM should happily accept this .001 file and appends all further parts automatically on the same session (according to documentation, not tried yet). Jason Hood's OMI program is able to store entire DVD/Blueray on harddisk as a collection of 1GB files if the file system has issues with larger files. However it seems to be a custom format, and further usable only by shsudvdhd disk mounting utility. I wonder if Jason's programs (OMI, SHSUCDHD) could be made compatible with GENISOMAGE output or WODIM's expected input when considering split files. Would MPXPLAY support DVD somehow maybe? I know of no DOS players other than that 1minute-or-so trial program at http://www.freeweb.hu/doscdroast/dvd4dos.htm Have some developers vanished completely btw? Not seen any activity by Arkady for ages :) Bernd -- 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
Re: [Freedos-kernel] Hello again
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
Re: [Freedos-kernel] Hello again
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 -- 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
Re: [Freedos-kernel] Hello again
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
Re: [Freedos-kernel] Hello again
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
Re: [Freedos-kernel] Hello again
Nope, I'm not doing anything other than trying to gather enough information with respect to project status to try to come up with a road map and possibly plan release 1.1. I have made *NO* decisions. Pat On Thu, May 14, 2009 at 4:26 PM, Eric Auer e.a...@jpberlin.de wrote: Hi Jeremy, *** SNIP *** 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 :-). *** SNIP *** Eric -- Amateur Radio Station: WB2GBF U.S. Army MARS station: AAR2BY/T -- 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
Re: [Freedos-kernel] Hello again
Hi Tom, Jeremy, 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... 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 :-). 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. Or, even easier, load DOS in a MEMDISK via anything that can load Linux (grub4dos, grub, lilo, syslinux...) and put filesystem drivers there. The need for using extremely big files in DOS is minimal but having compatibility to any other OS is extremely useful :-p. Actually the only large file app that I can think about would be one that juggles with DVD diskimages... That one app could split the diskimages over 3 files, each smaller than 4 GB :-). 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. Another example are EDR-specific extensions of the FAT32 BPB that make it necessary to modify DEVLOAD to work with EDR DOS etc ;-). 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
