Hi!

19-Июл-2004 21:14 [EMAIL PROTECTED] (FreeCOM) wrote to
[EMAIL PROTECTED]:

>> SK> What does the kernel do now, when the "originally correct empty
>> SK> environment layout" arrives there?
>>      "Originally correct" - with one empty ASCIIZ string? Currently prepared
>> MS-DOS-style empty environment. (DO WE SAY ABOUT BRAND NEW OS OR ABOUT
>> MS-DOS CLONE?!)
F> We talk about FreeDOS, usually.

     And what is FreeDOS?

>> SK> Does it care at all, well, it shouldn't?
>>      ?
F> "Task.c:ChildEnv(), which was wrongly scans empty environment with
F> non-MS-DOS-style layout" For me this phrase means "ChildEnv() is
F> analyzing an existing environment passed into the function and will now
F> honor only the MS-DOS format of an empty environment".

     Was: when non-MS-DOS-style empty environment was "arrive" to original
ChildEnv() it was generates garbage instead someting valid, because there
was wrong process for such environment. On the other side, by itself, when
no environment is defined (no variables in exec block or ps_environ contains
zero), original ChildEnv() was create non-MS-DOS-style empty environment
(with only one zero ASCIIZ string).

     My fix: ChildEnv() now accepts both environment styles, but itself for
empty environment produces MS-DOS-style layout.

>>      WHICH COMPATABILITY I BROKE?????!
F> The compatibly between the FreeDOS kernel and the FreeDOS shell.

     Compatability with bug? Isn't better to fix the bug, instead support
buggy code in the kernel (which compatible with non-fixed bug), and which
will not work with other, compatible programs?

F> And, because you've mentioned yourself that the knowledge of the MS-DOS
F> style empty environment is damn brand-new,

     Yes, this almost undocumented and not all peoples know this bug.

F> any other FreeDOS program probably used in INSTALL=.

     ? You can't use program in INSTALL= if (1) it searches for startup, but
(2) expects non-MS-DOS-style empty environment, and (3) before INSTALL= no
menu or SETs. But this is true for both MS-DOS and FreeDOS (as patched by
me). Isn't this is goal of FreeDOS - reproduce MS-DOS behavior as much
close, as possible?

F> And yes, instead of rushing out and "fix" something you claim is a bug
F> (because it is not so as in MS-DOS),

     If something doesn't work in MS-DOS, this _is_ bug, notwithstanding who
claims this. (This statement slightly reduced ad absurdum, but goal of
FreeDOS is a compatability with MS-DOS, including its bugs).

F> have a work-around in place to let existing programs work.

     But this not rejects fact of existing bug (not correctly runs under
MS-DOS), which should be fixed in any case.

F> And, that way, instead of to bend other people
F> to your willing, give them the freedom to decide themselves and,
F> probably, have a remark about the issue.

     You _already_ fix the bug, so you already decide. Question is only:
when fixed version will be available to use?

>>      MS-DOS (neither kernel, nor MS-command.com) NEVER INCLUDES SUCH
>> VARIABLE INTO ENVIRONMENT (empty or not). If in config.sys not present menu
>> or some SETs, then for INSTALL= MS-DOS passes empty environment into program
>> (in its style), for SHELL= it places zero into PSP[2C]. _My_ difference with
>> MS-DOS in this respect is that I always pass (empty) environment (but with
>> startup path), both for INSTALL= and SHELL=.
F> I don't care about MS-DOS, and you as well.

     _I_ care.

F> Why else would you pass non-zero to SHELL=?

     "Non-zero"="empty environment"? Becuase beside CONFIG= and other SETs
it may be useful to pass startup path (as you yourself mention in comments
inside ChildEnv()). For example, this allows user to rename shell executable
(as I do).

F> To gain a feature, to gain FreeDOS rather than another MS DOS.

     ?

>>      Blame "existing implementations", which doesn't work under MS-DOS (and
>> why they should work in FreeDOS, if they written for MS-DOS?!).
F> Hmm, I thought we implement FreeDOS.

     Hmm. I thought we implement MS-DOS compatible OS.

>>      I TRY TO DISCUSS, BUT SILENCE IS ANSWER.
F> You mailed a bugreport, no word about to immediately release a kernel
F> that breaks compatibly with FreeCOM.

     _I_ _report_ bug in FreeCOM. If now FreeDOS is closer to MS-DOS and
FreeCOM now incorrectly works in both under MS-DOS and FreeDOS (with empty
environment), who wrong?

>>      Not for each change, but some changes are important and should be
>> "emited" immediately.
F> Importance is a matter of taste.

     Of course. But requests to fixed version may (and do) indicate
importance.




-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_idG21&alloc_id040&op=click
_______________________________________________
Freedos-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel

Reply via email to