---------- Original Message ------------- Subject: [Freedos-devel] FreeDOS 1.0 Date: Sat, 15 Oct 2005 22:21:15 -0700 From: Blair Campbell <[EMAIL PROTECTED]> To: FreeDOS Devel <[email protected]>
>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 Beta 10 (or Beta A), not 1.0 see below for details, but basically a few core elements aren't ready yet > >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 I think Bart, Tom, Lucho, and all the previous kernel maintainers have done an excellent job and the current stable kernel is ready for a 1.0 release once some of the features in the dev kernel are merged in (which will just require time). no, FreeCOM is not yet ready for a 1.0 release. see its todo list, add to that the maintainer dropped out of site, and for some reason only a few people seem to be able to compile it. I personally am still trying to figure out how the translation scheme works; I thought I did, but adding/changing translations effects the size of the base binary which is supposed to be language neutral (pulling strings from the strings.dat external file or internal strings resource section). >needed to reach 1.0? How far away is KEYB from being ready? What a 1.0 release should not wait for ATAPICDD to be ready, but it would be nice to have. I'll let Aitor answer the keyb questions. On a somewhat related note, I have heard almost no feedback (either good or bad) about the country support within the dev kernel; so while I would like to have it merged into stable (and plan to do so) it would be nice to hear how well it does (or does not) function from people who actually use it first. >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? I almost never print, I used to years ago for references or school work, but nowadays I use a multitasking env for most of my development work so I can keep a document open and write/compile. I haven't followed too closely mem issues. Since I don't see the source for the latest TDSK being released any time soon, switching the primary ramdisk to a more advanced open source one should be fine; and I don't see any need for MS cmdline compatibility with it. What does /M do? I think SHSUCDX is quite sufficient for FD 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 one of these days I'll give it a try (I have the needed cables and computers). I still think RIFs is an ok replacement for INTERLNK/INTERSVR, not as easy to setup (you have to edit a config file to match your port configuration), but gives serial or parallel port based mapping to a remote drive, and as the protocol is documented, a server program could be written to share out drives from NT or *nix systems. It is one of the better (in documentation terms at least) filesystem (redir) driver implementations for DOS, so is the basis for my DOS LEAN (see FD-32) and NTFS IFS support. >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 For a 1.0 release I think the only LFN requirement would be that they do not interfere with each other. eg DIR/TREE/etc should not show junk values because of LFN entries (which I believe is already true for all utilities) and the program should not trash LFN entries, ie a degrag/chkdsk/etc shouldn't destroy them or unlink LFN entries from the corresponding SFN entry. >it be to write a wrapper that simply allows for recompilation of >programs to achieve LFN support? Would it be hard to make a For Borland compiled GPL'd programs, Steffen's IO95 library could be used to add support pretty easily. Each program will need to be examined for buffer overflow issues (LFNs support extends both the size of a filename and max path length), and other issues dealing with file naming issues (double dot(.) problems, wildcard matching, etc). http://www2.inf.fh-rhein-sieg.de/~skaise2a/ska/sources.html LFN support is great for semi to modern computers (386+), but for old or embedded type where filesize is still an issue, this support may bloat the binary unnecessary (no LFN API TSR ever used) and/or cause unneeded memory usage (leading to out of memory errors). Thus LFN support should not be mandatory, in fact we may want to offer support for it as a second binary (eg tree v3.x is intended for older systems or spaced limited ones, whereas pdtree (tree v4.x) supports LFNs (and additional items on NT systems such as indicating SPARSE files or displaying alternate streams). >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 dblspace/... support won't even be considered until FD 2.0 if you own a released version (not the boundled with DOS one) and it has problems, then file a bug as our kernel should support them. A clone driver could either be like the released versions, and that would not be overly hard, but someone who has the skill/knowledge, time, and desire would have to it. The use of which will most likely be limited to older/embedded systems, thus of limited value. Note that even USB thumb drive things are now exceeding 1GB in size, and try to find a hard drive under 40GB. There is also the issue of should it be compatible with existing compressed drives or unique, including the research into patents not yet expired. Support for bundled compression drivers requires modification to the kernel to preload them prior to config.sys processing, and I just don't see the need. Of course others are welcome to implement such support. >compressed filesystems? What about FAT32 support for defrag? Will >FAT32 users be able to manage without a defragger? What about NLS A defragger (or lack thereof) shouldn't delay 1.0, but if one is included it must be safe; no known issues with data corruption, even if a fat12/16 only defragger is ran on a fat32 system (where it should exit with a nice error message). >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 NLS support would be nice, but I leave the decision to add it to the various utility maintainers. The hard part is getting the actual translated content, and NLS support with no translations seems pointless. >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 no opinion >see... I have used undelete *.* once :-) )? Would a memmaker clone be >difficult to write using the edit TUI or the defrag TUI? I've never used memmaker, so without looking up the command (which I'm too lazy to do at this moment), I can't say how hard or easy it would be to do. The trickiest part I think will be the correct processing of config.sys: properly using config.sys or fdconfig.sys, supporting no menus, fd style menus, ms/pc style menus, and (would be nice so it could also be used with Enhanced DR-DOS) dr style processing. > >Also, which of the tools would be easiest to work on, for a beginning >programmer such as myself? > >Anyways, see everyone in two weeks :-) > Personally I'd like FreeDOS 1.0 to be as polished as possible but also an actual release to occur while people still use DOS. :-) Several of the programs I work on I do not see as being ready yet, and perhaps a few other programs aren't quite there either. I think the main items to concentrate on for a 1.0 release is to minimize bugs and maximize compatibility with our existing set of utilities. Any missing functionality can always be added later, but a buggy release will make users not want to try again and a set of ms/pc/dr DOS incompatible options may make future changes more difficult if we try to maintain compatiblity with FD 1. Jeremy ------------------------------------------------------- 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
