Hi,
Blair Campbell escribió:
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
I'm sorry, but my own opinion is NO. First of all, there are features
about MEM, AtapiCDD and why not, DISPLAY that should be finished before
1.0 (doing my best on my part, I promise).
But worst of all, the large number of bugs already existing. I doubt
that naming it 1.0 would encourage users to patch the 42 existing kernel
bugs.
In my opinion, a good step towards it would be to start monitoring
existing bugs to see which of them are considered for 1.0 or for post
1.0. This was tried sometime ago, but I guess it lacked
interest/coordination.
Also we should be very careful about a FreeDOS 1.0 with bugs that may
discourage potential users (or better) developers.
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.
MS-DOS 6.22 had a decent disk scanning tool, we lack ScanDisk, for example.
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?
ATAPI: I think it'd be a very good point ahead MS-DOS to have own CD
driver, otherwise we would have a FreeDOS that, as MS-DOS, requires of
manufacturer's CD-ROM driver to work properly with modern hardware.
KEYB: very close, a couple more of versions, same for DISPLAY.
PRINT: no-one is working on that
MEM: who was working on that? progress?
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.
Sorry Blair, you joined late. We already *HAD* this discussion VERY VERY
often, and last time it was agreed what there is actually in the FreeDOS
1.0 TODO list.
So this would be to re-open the same discussion once and once again.
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
If there are things already implemented, and more or less follow the
general rules (NLS settings support, compatibility with exitcodes, etc)
could be added, but I'd discourage to re-open the discussion of what
post-1.0 things should be moved back to 1.0 things.
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
For all compilers, for assembler, etc?
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
Please, do NOT mix NLS things with string translation. NLS support
(date/time, numeric, etc) is marked as mandatory, string translation isn't.
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?
Of course, the post-1.0 list (that I agree with Eric, needs to be sorted
out) admits merging everyone's personal TODO list.
To sum-up, I don't think it's a good idea to make developers again be
tired of the same 1.0 stuff (Blair, could you please read back the
mailing list archives?), but I hope this can serve to open the question
of which remaining bugs are for 1.0 or for post 1.0.
Aitor
-------------------------------------------------------
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
