Re: Beta vs. Stable

Hi,

>>>BO> - fcbs - this one is stupid in the FreeDOS context; we simply don't need
>>>BO> system FCBs for the FCB functions. It is parsed but ignored.
>>>     So what the problem with this?
>>>
>>That the spec doesn't describe the kernel behaviour.
>>
>
>Then we need to change the specs and be happy that we can do FCB stuff without
>having to allocate any FCB space :-).
>
I am a person who believes that a specs is a tool to help you develop a 
project, but it shouldn't be a constraint that, for the contrary, keeps 
you out of what is really missing/interesting to be implemented.
However, as for a country's constitution, I really believe that, if the 
general feeling is about changing the spec, and if Jim, project 
coordinator, really agrees on this, this should be done VERY 
occasionally, as one can't be changing the spec. continuously. This 
means that, in case we do this, one has to do this VERY carefully, and 
in a very sensible way, so that we can live with the reformed spec for a 
very long time.
So maybe it is interesting that those who feel constrained for some 
specific issue of the speec, and has VERY good reasons to believe that 
it should be changed, could expose his/her reasons here, so that they 
can be debated (and so that we can try to deal with it without touching 
the spec.).

I think Jeremy's idea is a VERY good idea, and that's why I encourage 
all the maintainers to fill in the list.
Parallelly, I have collected a short/unformatted list of the issues that 
have been mentioned today (tonight ;-)) about what is missing in order 
to fulfil the spec for the 1.0.
Also bear in mind Jeremy's point that 1.0 could be a "reasonable amount 
of the FreeDOS spec implemented", but not neccessarily meaning that all 
of the spec has been implemented.

(a) ====TODO'S in KERNEL  (to be included in Jeremy's entry for kernel, 
as long as they are believed to be neccessary for 1.0)
- COUNTRY=
- DRIVPARM
- INSTALL
- Missing interrupt functions
- MENUITEM, MENUDEFAULT,... (as similar to MS-DOS)  
(I have added this one myself)

(b) ==== BUGS/TODO'S in OTHER UTILITIES (to be included in Jeremy's table)
- FREECOM /Ax /Ox
- FORMAT C:  /U

(c) ==== SPEC CONSTRAINTS
- MEM switches (if it is admitted that spec shouldn't change (I am 
personally for it), then to be added to Jeremy's table under MEM entry)
- BUFFERS=[n[,nn]]
- Bring assembler to MASM compatible
(these last two are kernel's, and could disappear with a change of spec)

(d) ==== MISSING UTILITIES
- CHKDSK
- DISPLAY.SYS
(added by myself)

Therefore, more or less open discussions:
(1) Is a change in spec really neccessary (about (c))?
Aitor's opinion: if spec is to be changed, drop MASM compatibility, 
especially if kernel can be compiled with NASM. I don't know how useful 
secondary buffers really are. Anyway, they could be left for future 
FreeDOS releases without changing the spec. As for MEM, please change 
the commandline syntax to achieve MS compatibility

(2) What about (a), (b) and (d) for 1.0?
Aitor's opinion: all of them neccessary except maybe DRIVPARM, 
MENUITEM/MENUDEFAULT/..., and depending on what the missing functions 
are for, I'd leave that for kernel developers.

The items mentioned here are basically about the core components (kernel 
and FreeCOM) with the hope that useful comments/points of view can be 
collected, as for the rest of the utilities, I guess it is the developer 
who knows better the status of the utility.

By the way, what to do with those utilities for which the developer is 
not present?
I don't know if FreeDOS MODE developer is with us, but for example, MODE 
CON * is not admitted by the driver (although I admit that it'd be 
mostly useless without a DISPLAY.SYS).

Aitor