Re: [Freedos-kernel] kernel 2038
Hi Jeremy, Kernel 2038 tagged and available at http://www.fdos.org/kernel/latest/ Someone with access, please upload to ibiblio and release on SF. Please update history.txt - it represents the state of 13 months ago... While you are at it, could you update my email to mceric at users.sourceforge net in contrib.txt and other places? Thanks! Please test and report any new issues to the mailing list. Depending on any reported issues, 2039 scheduled to be released in about a month. Comments about new or existing bugs to focus on for next release welcome. Interesting :-) 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
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
[Freedos-kernel] ASUS problem
Hi all, I use regularly FreeDOS in users instalations with brand new, superfast motherboards. The aplication is heavy Database usage and FreeDOS is prerforming better then MS-DOS... There is a systematic problem only with ASUS motherboards (in the last 3 years aprox.) System crashes, files get corrupted, etc :( :( Does anyone have any information or Idea about this problem? Would any of Jack's driver help? Thanks for any info, Alain -- 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] ASUS problem
Alain M. schreef: I use regularly FreeDOS in users instalations with brand new, superfast motherboards. The aplication is heavy Database usage and FreeDOS is prerforming better then MS-DOS... Great. Is switching kernel the only thing that's relevant or did you switch any other components as well? There is a systematic problem only with ASUS motherboards (in the last 3 years aprox.) System crashes, files get corrupted, etc :( :( Recent motherboards can be very picky about system memory. My Striker Extreme board won't accept any memory modules into its 4th slot. (or doesn't like dualchannel perhaps). Does anyone have any information or Idea about this problem? Would any of Jack's driver help? I don't know your usage cases of DOS + database. Provide more details if possible. Also try starting troubleshooting your system. Memtest+ could do miracles to test memory. Start with 1 memory module, test each module, then extend to 2 modules installed at same time, etc. Another option is to exclude harddisk access by using a RAMDISK, so there's no harddisk involved, nor cache, IDE controller, PCI bus, etc (install your DB on ramdisk, then use it as if it was on harddisk - just for testing. Not permanent ofcourse as changes get lost upon system reboot if you don't perform a manual backup). I'm not sure how to detect corruption of a filesystem explicitly. 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
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
[Freedos-kernel] Kernel 2038 and plans
Hello all, 1. I have checked out the latest build (kernel 2038-32). It works fine with GEM/XM. (So did the 2nd RC.) 2. Congratulations on a great kernel/OS 3. PLEASE stop the flame wars--the last few digests have looked rather (?!) 4. I would rather see more of the features from 2037 in stable than get more oddball features in unstable (ExFAT, FAT+). Once we get COUNTRY.SYS WfW support in stable, these might be handy. And SHSUCDX with UDF support does seem higher priority. Thanks for developing FreeDOS! -- 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
[Freedos-kernel] Which kernel
Hi Pat, I would say 2038 as default, 2037 (including winkrnl) as option--unless 2039 shows up first (doesn't look likely). If 2039 gets something worthwhile, 1.11 is an option. Thank you, ibidem -- 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] Which kernel
This sounds liuke a good strategy. Pat On Mon, May 18, 2009 at 8:07 PM, ibid...@lavabit.com wrote: Hi Pat, I would say 2038 as default, 2037 (including winkrnl) as option--unless 2039 shows up first (doesn't look likely). If 2039 gets something worthwhile, 1.11 is an option. Thank you, ibidem -- 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 -- 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
