> 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. > I think the next release should be 1.0 beta some core elements aren't ready yet, but all depends on the DOS version we want to emulate, 3.31, 4.0x or 5.0x Seems that the target is 5.0x I'll assume this in the following.
> 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? > I think that kernel won't be ready for a 1.0 release until the features in the dev kernel are merged. COUNTRY support must be the priority. FreeCOM is probably is very important, and it's also probably the most unmature of the core utils. Of course it isn't ready for a 1.0 release, and even seems to be unmantained. Of course we have 4DOS, but isn't GPL and I don't know if there are issues with FreeDOS Will be possible to include it in the FreeDOS distro ??. On the other side it intends to have much more functionallity than DOS 5.0x COMMAND.COM, probably the most inportant feature missing is INT 2E support. > Is ATAPICDD really needed to reach 1.0? How far away is KEYB from I think that ATAPICDD isn't necessary, in fact I should remove it. > What would it take to finish print? I don't know which are the issues, I'll take a look. > Is MEM nearly complete? MEM has more or less the funcionallity of DOS 5.0x MEM, but there are some bugs. > Can TDSK be replaced by another ramdisk driver? Would > another ramdisk driver need > to be MS-DOS compatible? I think that TDSK should be replaced by another GPL RAM disk, there are a couple of them available now (I saw the anuncements in freedos.org). > Is the /M switch needed in SHSUCDX for 1.0? > We have cdrcache so we don't need buffer support in SHSUCDX. > one needs to also consider what > MS-DOS incompatibilities are considered acceptable, and what things > could be postponed to a post-1.0 release. > I'm a fan of DR DOS and it isn't an absolute clone of M$-DOS, M$-DOS has many flaws (also good things) and if we can improve it Why not ?? > 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? I think that should LFN an FAT32 support should be a compile time option in all programs that support it so we can build two distros: one LFN+FAT32 enabled and one FAT16 only for old machines. > Would it be hard to make a > dblspace/drvspace/stacker clone using large amounts of code from the > linux fs driver dmsdosfs >ttp://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? > I don't think that compression is important for a 1.0 release, I don't know but FreeDOS should be compatible with SuperStor & Stacker or the shareware JAM:ftp://mirrors.blue.aol.com/pub/simtelnet/msdos/arcers/jam125sw.zip Could it be included in the distro ?? Preloading of the compression driver isn't present in DOS 5.0x and I think it isn't necessary at all. > What about FAT32 support for defrag? Will > FAT32 users be able to manage without a defragger? Again, there should be two distros, one with LFN+FAT32 support and one FAT16 only. > 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)? > I'm not a native English speaker but I prefer to use non-NLS utils, because of small disk footprint and inconsistencies in the translations, so this isn't a requiement for 1.0 (or even for any future version). > Is it necessary for HIMEM and EMM386 to have CPU checking? I think this is an obvious missing feature. > Should LBACache be a device > driver and should CDRCache be merged in? I don't know if LBACACHE implements the SMARTDRV 4.x API, it should implement at least installation check and flush cache ones. I don't think that CDRCACHE should be merged, not everybody has a CD-ROM or want to cache it and if you load the driver with DEVLOAD you can also load CDRCACHE if needed. > Does undelete need FAT32 > support and wildcard support (which I would particularly like to > see... I have used undelete *.* once :-) )? No for the FAT16 distro. See above. > Would a memmaker clone > be difficult to write using the edit TUI or the defrag TUI? > I don't think that worths to waste the time with this. > Also, which of the tools would be easiest to work on, for a beginning > programmer such as myself? > I don't know. Hope this helps. ______________________________________________ Renovamos el Correo Yahoo! Nuevos servicios, más seguridad http://correo.yahoo.es ------------------------------------------------------- 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
