Hi. I just thought that I'd start a topic before I left for two weeks about a FreeDOS 1.0 release. It has been suggested that I release my Beta 9 Enhanced Release distro as a FreeDOS 1.0 pre-release distro. For one, this would mean that it would get tested more frequently, also it would (possibly) encourage people to get the unfinished tools done, or fix any bugs that unfinished tools have.
What does everybody think about this? Is FreeDOS almost ready for a 1.0 release? One must remember that FreeDOS now surpasses MS-DOS in several ways, such as support for LFNs in some tools. One also must remember that there are tools that are incomplete or missing. Another thing to bear in mind is that MS-DOS 1.0 was not NEAR as finished as FreeDOS currently is, and that MS-DOS didn't even reach a complete Operating System until 3.1, and many more tools joined MS-DOS by 6.22. Is FreeCOM stable enough for a 1.0 release? Is ATAPICDD really needed to reach 1.0? How far away is KEYB from being ready? What would it take to finish print? Is MEM nearly complete? Can TDSK be replaced by another ramdisk driver? Would another ramdisk driver need to be MS-DOS compatible? Is the /M switch needed in SHSUCDX for 1.0? Once these questions are answered, one needs to also consider what MS-DOS incompatibilities are considered acceptable, and what things could be postponed to a post-1.0 release. Another thing that warrents attention is the question of what things from the post-1.0 todo list should be in a 1.0 release, and what things from that list are simple enough to make their way into a 1.0 release. I have personally had no feedback at all on whether or not LPTLink (compiled by me) works or not, but if it does, it might not be too hard for me to modify it to imitate INTERLNK/INTERSVR and cause that to be in a 1.0 release. Since I have no laplink cable however, I cannot test this myself, even though I want to. About LFNs: Some think that LFN support should be mandatory in all FreeDOS programs for a 1.0 release. I personally do not feel that way, but how hard would it be to write a wrapper that simply allows for recompilation of programs to achieve LFN support? Would it be hard to make a dblspace/drvspace/stacker clone using large amounts of code from the linux fs driver dmsdosfs (http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/util/system/dmsdos-0.9.2.1.tgz), since it already supports read and write support of the mentioned compressed filesystems? What about FAT32 support for defrag? Will FAT32 users be able to manage without a defragger? What about NLS support? Should the number of programs which use kitten become expanded (which isn't really all that hard)? What about NLS support in programs coded in assembler? Should there be a version of kitten for assembler (as there is for pascal and C)? Is it necessary for HIMEM and EMM386 to have CPU checking? Should LBACache be a device driver and should CDRCache be merged in? Does undelete need FAT32 support and wildcard support (which I would particularly like to see... I have used undelete *.* once :-) )? Would a memmaker clone be difficult to write using the edit TUI or the defrag TUI? Also, which of the tools would be easiest to work on, for a beginning programmer such as myself? Anyways, see everyone in two weeks :-) ------------------------------------------------------- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl _______________________________________________ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
