Aitor Santamaría Merino wrote:
Hi there,
Given the interest back of the FreeDOS 1.0 issue, and in the
understanding of the several calls for a near FreeDOS 1.0 release,
opposing the more conservative opinions of Jeremy or myself respect to
this, I have been thinking and perhaps Alain's idea of a nearer
FreeDOS 1.0 distribution followed by a FreeDOS 1.1 which would fulfill
pending wishes, plus the huge amount of bugs/problems that would arise
from such a FreeDOS 1.0 distribution, would be an excellent compromise
solution.
So the idea would be that FreeDOS 1.0 does not get stalled with some
remaining features (like, say, PRINT /D) that are unlikely to be
written in a near future (or ever).
I'd like to launch a proposal, with this points:
(a) That the features that are not being demanded AND not being
developed, AND not found interesting by developers be put away till
FreeDOS 1.1 (but not later)
(b) That the features that are not changing functionality or
interface, but are optimisations or re-works be left for FreeDOS 1.1
(not later)
(c) That the rest of official distributions would be called Beta9 SRx
till the remaining features/bugs are fulfilled, then we would make a
pre-resease of FreeDOS 1.0 and have it under quarantine
Am I being too simplistic? conservative?
Nobody's going to work on things nobody's working on until somebody gets
the itch.
To start with, I'd like to divide the remaining work in three parts:
(1) FreeCOM
(2) The rest
(3) Bugs,
starting with FreeCOM in this mail, left the rest for later.
About FreeCOM, I ignore if Steffen is out there still developing or
with interest in his wonderful project. I do not dare change his
roadmap, cleanly stated in:
http://freedos.sourceforge.net/freecom/FreeCOM.html#-status
But I am starting to reconsider wether all of them are needed for a
FreeDOS launch, and I would suggest, of course guided by Jeremy or
other people, such as Tom or Bart, that know well about the internals,
that the features are changed in order, so that those features
required for FreeDOS 1.0 are put first.
For example, to my mind the following two would be essential:
- INT-2E backdoor
- Wildcards for REN, same filename pattern matching code for REN, COPY
and DIR
Whereas there seem to me like optimisations that may be left for later
(FD 1.1), whichever the FreeCOM version is (1.0 or not):
- Input/output functions to replace <stdio.h> by <io.h> (aka replace
FILE*-based I/O by handle-based one)
Personally, I don't know if this is a good optimization because
<stdio.h> is Standard C, while <io.h> is an extension. It should be
possible to mimic the functions in <io.h> with the functions in
<stdio.h> just by turning off the buffering on the FILE* (the standard
function setbuf() and setvbuf() set the file's buffering). The whole
point of buffering is to minimize calls to the operating system to do
reads and writes.
If you think stdio is bad, wait until you get to C++; iostreams are worse.
- Strict error recognition, probably _doserrno based
- Code sharing of modules
I ignore what is meant by DOS=HIGH, does it mean that FreeCOM would
request DOS for swapping a piece of HMA, if possible?
Finally there are these two related to swapping. I currently ignore
the status of these two, if someone can explain/advocate for these two
I'd be happy, thanks.
- Swapping without any supporting secondary programs (KSSF.COM and
VSPAWN.COM)
- Redirection in conjunction with Swapping
I remember that in older versions of FreeCOM you had to use external
programs (was it KSSF?) to swap it out, but I ignore the current
status of swapping.
[Constructive] opinions?
Aitor
-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
