Hi! Very nice topic :-) > Beta 9 Enhanced Release distro as a FreeDOS 1.0 pre-release distro.
I would rather call it a "FreeDOS 1.0 technology preview 1", because there are some known missing features but MOST aspects ARE 1.0-worthy. > 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. We do really need testers. If people do not trust beta, then we should not keep walking through beta until beta 99 in year 2020. We all know that FreeDOS is very useable even though we call it beta. Bug-fixing is important, but even a decent amount of bug TESTERS would already let us close a well-2-digit-percentage of our Bugzilla items, I assume. We could offer a candy bar for everybody who tests a bug and updates it to correct state (still buggy or fixed) for the most recent version of the FreeDOS component in question... :-). The gained PR would also attract some non-programmers who could help to shorten our HTMLHELP errata page (part of HTMLHELP). Replies per user follow. Blair: Atapicdd is a nice extra but not needed for 1.0 (there are drivers- which-came-with-the-drive, vide-cdd, others). KEYB: Aitor has to comment on this. For many layouts, even MKEYB will do the job. Print(q) is hardly used, so nobody works on it. It was fun to write GRAPHICS but I assume nobody uses it either (even though it supports PS, HPPCL and ESC/P, widespread modern printers). MEM seems to be nearly complete, ask the one who is working on it. Any good ramdisk will do, e.g. the one maintained by Jason, no need to use TDSK. The SHSUCDX /M buffering does not improve things according to Jason, and we have CDRcache, so I would drop that wish from the 1.0 list. Post-1.0: LPTLink sounds good. I would use FileMaven or FTP to a non- DOS server on the other end (of a LAN or PLIP line) I guess... I think LFN support is clearly POST 1.0 - for MS, it took until version 7. LFN makes binaries bigger, so it should be optional / compile time option. DBLSPACE: Might be fun but even my USB stick is 5 times bigger than the harddisk of our old 386 (yet it is a very small USB stick). I myself would suggest to start with a driver loadable from config sys to mount a pre- compressed FAT filesystem readonly very much like you run a ramdisk. Similarily, it would be nice to have a mount-PCMCIA driver loadable... DEFRAG "safely crashes" on FAT32. Should better safely-intentionally-abort. But we have no maintainer :-(. There are also some GUI oddities with it. NLS support: My PERSONAL opinion is that we need testers who tell us about all missing COUNTRY support EXCEPT in number formats. In other words, sort, up/downcase, date/time formats should follow COUNTRY everywhere. But the thing would be: First release the 1.0 preview THEN wait for feedback. NLS support 2: Language support should be on a ON DEMAND basis. For example kittenizing SHARE turned out to be very pointless waste of RAM and disk space (hardly any messages anyway). I would suggest to kittenize tools which are interactive and which are used more than once per boot only as 1.5 goal and only require translations for REALLY used tools in 1.0 (e.g. people ASKED for German xcopy so they get it...). We could Wiki-ize such a list and collect wishes... Checking the BASE list: attrib choice ?chkdsk freecom ?comp debug deltree ?diskcomp diskcopy edit edlin ?exe2bin ?fdapm ?fdshield find format help label mem mode more move print replace ?recover scandisk sort swsubst sys tree undelete unformat vol xcopy, maybe others, would be a rough list of candidates. Tell me what I forgot. Note that several of them are "exe2bin class" (too simple to be worth big kitten overhead" while several others already do use kitten. Question is which of them we should PLAN to kittenize sooner and which later / never. I would use FreeDOS 1.1 or higher version numbers when talking about translation roadmaps, though - we do have FreeCOM translation and some on-demand other, enough for MY 1.0 taste. ASM-Kitten: Of the above, debug would be a candidate, while e.g. lbacache is not often touched by the user after boot. FDAPM is somewhere in-between. Resident tools and drivers are generally "better not kittenize" or "keep kitten out of the resident part". EMM386 HIMEM cpu-checking: The effort / gain ratio speaks for making EMM386 / HIMEM foolproof in terms of CPU checking, yes. LBAcache device: Not needed. My GENERAL opinion is that we have enough MS DOS compatibility if you can use an INSTALLED FreeDOS like MS DOS. Trying to use the same config sys / autoexec bat format in all aspects would be unnecessary nitpicking. CDRcache merged into LBAcache would not be needed for the same reason, but if you only have little XMS free, the merge would help because both caches could share their memory. UNDELETE FAT32: Would be really nice. Not planning to do it myself but still the policy is that I will help whoever wants to add it. Should not be that hard, as FAT32 is similar to FAT16 in many things. UNDELETE Wildcards: Hmmm... current version already has a patch by somebody for in-place undeletion (mine only extracted deleted files to another drive), should be relatively easy to add wildcard checks. MEMMAKER: Not really. With XMS Swap and DOS in HMA you get nice amounts of free DOS RAM without too much tuning. MEMMAKER was a goodie to optimize UMB usage because MS generally has bigger RAM footprint. Jeremy: I think beta 10 is not the right name to get PR. And our PROBLEM is a lack of PR because we are stuck at pre-1.0 state while many developers think their components already DID reach 1.0 state. And yes, some devel features could be and should be moved to stable kernel. Please be CONSERVATIVE about that. Adding NLSFUNC hooks is fine, adding the "drop f-node system entirely" patch (if one exists) would NOT be fine for a stable kernel... FreeCOM has evil coding style but otoh is pretty complete. Tell us which parts of the list you would like to be added before 1.0-final. Probably the int 2e hook, for example? I agree that ATAPICDD is nice but not required as 1.0 BASE component. For KEYB, Aitor's TODO lists memory tuning, PC-XT support, Japanese API (?), beeping (?) and a layout librarian. I think PC-XT support is required for 1.0 (unless you say PC-XT users must use MKEYB) while the rest would be very nice but not 100% required... By the way, about ANSI DISPLAY MODE NLSFUNC: Work good enough for me but do not yet model MS internals closely. And PRINT PRINTQ: Rarely used, but adding device selection and buffer sizing would be quite feasible if we want to shorten the 1.0 wishlist. Generally: We started by wanting to clone MS DOS 3.3x, now we clone 5.0 and include several clones of 6.xx add-ons even. We could push the wish-bar to wanting to clone 7.10 but we could just start to dare to use that 1.0 version number. I updated my Linux from 2.0, 2.2, 2.4 to 2.6 over the years, but that does at least dare to use version number 2 already... ;-). RAMDISK: Any good disk will do. MSCDEX /M: not needed. Etc see above. LFN support should not be in the standard distro, it should be in a separate category (unless included by chance, e.g. removing LFN support from DOSFSCK would be extra work ;-)), something like "BASE-LFN" where we could collect LFN-enabled compiles of BASE tools for people who do have LFNs and do not want a mini embedded DOS. http://www2.inf.fh-rhein-sieg.de/~skaise2a/ska/sources.html io95 by Steffen does indeed seem to be a good starting point for that. Post-1.0 of course. Michael: See above for the CPU check. I agree that exact command-line cloning is quite unnecessary for drivers like EMM386 and HIMEM. I cannot really comment on the VDS issue, but I can tell that EMM386 and HIMEM are far better than we could hope that they would be a while ago. Clearly 1.0 ready. > On the other hand, I have also seen Usenet posts where a person stated that > they would try FreeDOS "once it was out of beta test". So people also > aren't using FreeDOS because it doesn't have the magic 1.0 release number. Exactly. And about "retry with NOVDS": Well it might help to get that stack layout for protected-mode-originating-exceptions (with and without error code) more fool-proof to get error messages instead of reboots if you are experiencing VDS-related reboots. SCSI and S-ATA conceivably could use protected mode in BIOS, who knows ;-). Or manage to page-fault or stuff in any other evil way. Maybe I should just admit to have no VDS fix idea. Florian / Flox: Indeed, LFN can be used through other shells, like 4DOS, BASH, GNU fileutils in their DJGPP DOS compiles... Revamping FreeCOM to use LFN would be 2.0-ish. > My opinion for FreeDOS 1.0: Every publicity is good! And it should point > out the advantages and features. And all of us should make publicity, > maybe tell some (virtual) newspapers about it etc. I would suggest that 1.0-preview style of PR, collect test results, decide what should be fixed even BEFORE we release "Blair's 1.0 preview" distro (I imagine things like "wait for a new KEYB and MEM snapshot", but no ground-shaking updates, as we are busy with waiting all the time). Diego: I think we are indeed aiming at "5.0 plus, where useful, FAT32, plus some of the 6.xx bundled goodies" at the moment. Nobody wants 4.01 I guess and 3.31 is quite old. 5.0 plus something is just right... FreeCOM is not THAT bad but it has no real maintainer and is somewhat unmaintainable. I suggest to debug it but not add many features (not many missing anyway) and write a completely new shell a few years later. The int 2e support is indeed something which is useful but missing. MEM is quite okay from what I last heard, but there should be an upload of the newest version to know more (MEM 1.8?). As you say, translations can mean unnecessary overhead. For example if SHARE can say in 20 languages that it is now loaded, there would be no real gain. But that XCOPY and DIR can be used without having to under- stand English is quite nice for people in other countries. Question is for which tools we should ADD translations and for which not. > I don't know if LBACACHE implements the SMARTDRV 4.x API, it should > implement at least installation check and flush cache ones. That would only be needed if LBACACHE would support delayed writes ;-). See above about the merge-cdrcache question. I hope I still got all points covered even though I did not explicitly comment on the overlap between the various opinions (including mine)... Eric ------------------------------------------------------- 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
