Questions and discussion about FreeCOM (the FreeDOS command.com)

FreeDOS Version 1.0 reviewed

Hi all,

I have commited some changes to the list (some more to go, read below), 
and I am submitting a message to met you know.
In addition, comments are welcome: if you consider that such or such 
option should be left for post (if any), or which tasks should be there.

NOTES:
- remember the golden rule: not as many wishes so as never to reach 
version 1.0, but not as few as creating a FreeDOS that could let 
potential users down
- to commit: re-check MIRROR status, leave APPEND and HIMEM/HMAMIM= to 
post-1.0, some minor misprints, etc.
- last time we discussed about the meaning of ROM= and RAM= in EMM386, 
still to be evaluated if pre/post? (I'd say that RAM= is trivial to 
implement, and with latest changes perhaps ROM= is not too hard)
- for a change, I'd prefer simple majority. Please break 
one-against-one/even cases by giving opinion :)

One year ago I would never thought that we could be so close as we are .)

Aitor

-------------------------------------------------------
This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek
For a limited time only, get FREE Ground shipping on all orders of $35
or more. Hurry up and shop folks, this offer expires April 30th!
http://www.thinkgeek.com/freeshipping/?cpg=12297

headers

Michael Devore | 24 Apr 21:43

Re: FreeDOS Version 1.0 reviewed

At 09:46 PM 4/24/2004 +0200, you wrote:
>Hi all,
>
>I have commited some changes to the list (some more to go, read below), and I am submitting a message to met
you know.
>In addition, comments are welcome: if you consider that such or such option should be left for post (if
any), or which tasks should be there.
>
>NOTES:
>- remember the golden rule: not as many wishes so as never to reach version 1.0, but not as few as creating a
FreeDOS that could let potential users down
>- to commit: re-check MIRROR status, leave APPEND and HIMEM/HMAMIM= to post-1.0, some minor misprints, etc.
>- last time we discussed about the meaning of ROM= and RAM= in EMM386, still to be evaluated if pre/post?
(I'd say that RAM= is trivial to implement, and with latest changes perhaps ROM= is not too hard)

I'd say RAM is a practically useless option.  Probably could emulate it within EMM386 parsing just by
mapping X= ranges around it, though.  Not too much current practical need for ROM or most of the other
missing Microsoft-analogous HIMEM and EMM386 options, for that matter.  There are other extended
options which are more useful.

Most of what's left can wait for a post-1.0 sweep that tightens up MS-command line option compatibility in
general.  We are putting out the final fires, not putting on lipstick.

-------------------------------------------------------
This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek
For a limited time only, get FREE Ground shipping on all orders of $35
or more. Hurry up and shop folks, this offer expires April 30th!
http://www.thinkgeek.com/freeshipping/?cpg=12297

headers

Aitor Santamaría Merino | 24 Apr 22:34

Re: FreeDOS Version 1.0 reviewed

Hi Michael,

Ok, thanks. Then is noone is against, I'll move those to post-1.0.
I chose to set those there, as in the examples they seemed to be popular 
options.
Particularly, what I missed mostly is VCPI, so thanks for that.
By the way, I have remembered that I should list VDMA there too, pre- or 
post-?

Aitor

Michael Devore escribió:

>At 09:46 PM 4/24/2004 +0200, you wrote:
>  
>
>>Hi all,
>>
>>I have commited some changes to the list (some more to go, read below), and I am submitting a message to met
you know.
>>In addition, comments are welcome: if you consider that such or such option should be left for post (if
any), or which tasks should be there.
>>
>>NOTES:
>>- remember the golden rule: not as many wishes so as never to reach version 1.0, but not as few as creating a
FreeDOS that could let potential users down
>>- to commit: re-check MIRROR status, leave APPEND and HIMEM/HMAMIM= to post-1.0, some minor misprints, etc.
>>- last time we discussed about the meaning of ROM= and RAM= in EMM386, still to be evaluated if pre/post?
(I'd say that RAM= is trivial to implement, and with latest changes perhaps ROM= is not too hard)
>>

(Continue reading)