Re: Beta vs. Stable

Multiple replies...

Bart Oldeman wrote:

>Maybe we should just aggressively close bug reports where the
>reporter hasn't replied to questions or where the bugs are
>unreproduceable.
>
There's an intermediate solution that we used to "get rid" of the wishes 
;-))
Just create a new message slot, called "unreproducable" (to be used in 
the meantime until bugzilla is up). By the way, maybe bugzilla is 
another todo for FreeDOS 1.0 :)

>If they still exist then somebody will report back later anyway.
>
I am not used with bugzilla, but maybe it offers the possibility to 
"merge" two bugs (?).

Eric Auer wrote:

>No idea what "Jeremys lists" are, but
>(a) COUNTRY is important. I understand the kernel is ready but NLSFUNC
>is missing? DRIVPARM and INSTALL are probably less urgent, but at least
>DRIVPARM should not be too complicated to do (???). I actually like the
>current MENU system, please keep it (at least as a compile time option)
>as it is. You could, however, provide a syntax mogrifying tool to turn
>MS config.sys into fdconfig.sys... Or try to recognize both syntax versions
>at the same time?
>
See message from Jeremy posted today (Jeremy usually has mail signature 
as Kenneth J. Davis (J for Jeremy).

>(b) FREECOM DIR /Ax and /Ox is, among other reasons, not implemented
>because Steffen did not dare to predict how much memory it would need
>to allocate (speaking of /O - /A should be easy!). I think you could
>solve this by having an external dir.exe which gets run whenever FREECOM
>detects not internally supported arguments, like /O...
>
You could use FreeCOM's external commands installable API, but I don't 
like the idea either...

>What was again the use of the /U flag in FORMAT? Save unformatting info?
>
No, unconditional format (surface scan).

>(d) CHKDSK and DISPLAY.SYS are indeed missing. But what exactly does DISPLAY
>do? 
>
DISPLAY.SYS is a CON driver that handles some "Generic IOCTL requests" 
on it, namely those that are up to PREPARE and SELECT codepages. When 
you issue a
MODE CON CODEPAGE PREPARE
MODE CON CODEPAGE SELECT
yo are making IOCTL calls to DISPLAY, by sending (in the first case) a 
CPI-formatted file, in order to fill internal space with codepage 
information. With SELECT, you simply select the active codepage.
My Windows says:

DEVICE=C:\WINDOWS\COMMAND\DISPLAY.SYS CON=(EGA,,1)
EGA: type of display
<missing>=437:  hardware installed codepage
1:  make room for one more codepage set

Ok, I admit I am myself thinking of working on DISPLAY.SYS, but I'll 
need a lot of time since I have something useful and working.
I might be saying something wrong, or something may be missing. Please 
read this:
http://www.freedos.org/freedos/news/technote/141.txt

>>>INT 21h/6602h "SET CODEPAGE"
>>>
>>This one is implemented. There's just no NLSFUNC at the receiving end of
>>int2f/ax=1401.
>>
>
>Well, any ongoing NLSFUNC projects? What are the technical specs of NLSFUNC?
>(Please do not mail me > 10k zip files or whatever with them :-)).
>
Matthias Paul may know more on this specific issue (if the newsitem 
above is not clear enough) ;-)

Arkady V.Belousov wrote:

>ASM> I entirely disagree here, sorry. I admit I just forgot about it, now
>ASM> that Bart mentioned it.
>ASM> I am strongly for parameter compatibility in MEM, otherwise I (one)
>ASM> have/has to be learning the new syntax all the time.
>
>     You remember MS MEM command line syntax?!!!
>
Oh yes, I am too used to it ;-))

Aitor