Hi!
19-Июл-2004 13:59 [EMAIL PROTECTED] (Steffen Kaiser) wrote
to "[EMAIL PROTECTED]"
<[EMAIL PROTECTED]>:
>>>> You mean "Arkady called MS-DOS-style empty environment broken"? Yes, I
>>>> call this. But this is MS-DOS and all its bugs become standard and called
>> SK> So, you've "fixed" the FreeDOS kernel to issue the broken MS-DOS "empty
>> SK> environment" to programs, did I understood it correctly?
>> No. I fix the task.c:ChildEnv(), which was wrongly scans empty
>> environment with non-MS-DOS-style layout (only one empty ASCIIZ string). And
>> yes, currently ChildEnv() for empty environment uses MS-DOS layout.
SK> Huh? So I did understood it correctly!?
No.
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?!)
SK> Does it care at all, well, it shouldn't?
?
>> What you have against?
SK> You've broke the compatibly with existing FreeDOS-near programs. Have you
Please, name "existing FreeDOS-near programs", which works under MS-DOS
and not works under (patched by me) FreeDOS.
SK> What bugs me is: You've intentionally broke the compatibly with existing
SK> implementations for no good reason,
WHICH COMPATABILITY I BROKE?????!
>> SK> Actually, it would be cleaner to never issue an empty environment. You
>> MS-DOS may. Also, "not issue empty environment" anyway mean "don't make
>> availabel startup path" (what makes FreeCOM unhappy).
SK> To pass a non-empty environment to a programs means that it is not able to
SK> get argv[0]??
How you read?! "Not pass empty environment" mean putting zero valie
into PSP[2C] word (as MS-DOS does, BTW). Or you mean, that someone should
ADD into ChildEnv() adding of some garbage into environment to make it
_look_ like non-empty?!
SK> How can that be? How got programs, e.g. FreeCOM, aquire its
SK> start path from argv[0] during the time, the default environment included
SK> the PATH=. variable?
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=.
>> This was based on observation of all available documentation.
>> Unfortunately, documented layout makes smartdrv broken.
SK> FreeDOS is shipped with smartdrv. I never knew that.
FreeDOS NEVER shipped with smartdrv (this is commercial, closed
software).
Issue with smartdrv was reported by Lucho and approved by me: I found,
that smartdrv tries to restart itself with startup path; with one empty
ASCIIZ string in empty environment, it not finds its startup path.
>> Utilities, unhappy). Also, MS-DOS _passes_ empty environment, why we
>> shouldn't?
SK> Because this introduces known incompatibly with existing implementations,
Blame "existing implementations", which doesn't work under MS-DOS (and
why they should work in FreeDOS, if they written for MS-DOS?!).
[BTW, currently I know only one "implementation", which hardly affected
by empty environment - this is FreeCOM. All other programs shouldn't be used
in INSTALL= lines without previous SETs neither in MS-DOS, nor FreeDOS.]
SK> and I expect that such stuff is discussed in advance among all affected
SK> people.
I TRY TO DISCUSS, BUT SILENCE IS ANSWER.
SK> For me this discussion looks like whether or not I have to emit another
SK> pre-compiled FreeCOM for each change of a line of code.
Not for each change, but some changes are important and should be
"emited" immediately.
-------------------------------------------------------
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