Arkady V.Belousov wrote:
Hello,
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?!)
We talk about FreeDOS, usually.
SK> Does it care at all, well, it shouldn't?
?
"Task.c:ChildEnv(), which was wrongly scans empty environment with non-MS-DOS-style layout" For me this phrase means "ChildEnv() is analyzing an existing environment passed into the function and will now honor only the MS-DOS format of an empty environment". So I wondered why ChildEnv() cares about the second '\0' of the MS-DOS-style empty env at all.
When the function needs to prepare such environment, there is a diffenerence, of course.
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?????!
The compatibly between the FreeDOS kernel and the FreeDOS shell.
And, because you've mentioned yourself that the knowledge of the MS-DOS style empty environment is damn brand-new, any other FreeDOS program probably used in INSTALL=.
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?!
For me an empty environment is an existing environment with no variable defined; and "no environment" when PSP[2C] contains zero.
And yes, instead of rushing out and "fix" something you claim is a bug (because it is not so as in MS-DOS), have a work-around in place to let existing programs work. And, that way, instead of to bend other people to your willing, give them the freedom to decide themselves and, probably, have a remark about the issue.
In this particular case: It would be as easy as to pass at least one env variable to the program.
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=.
I don't care about MS-DOS, and you as well. Why else would you pass non-zero to SHELL=?
To gain a feature, to gain FreeDOS rather than another MS DOS.
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?!).
Hmm, I thought we implement 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.
You mailed a bugreport, no word about to immediately release a kernel that breaks compatibly with FreeCOM.
Here it is:
"FreeCOM incorrectly handles empty environment, _as this understanded by
MS-DOS_. Trouble is that for empty environment MS-DOS places before
16-bit counter not _one_, but _two_ zero bytes. This is easy to see: make empty config.sys with line INSTALL=FREECOM.COM and FreeCOM will not
detect presence of path after environment."
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.
Importance is a matter of taste.
Bye,
-- Steffen Kaiser
The current maintainer of [EMAIL PROTECTED] http://freedos.sourceforge.net/freecom/FreeCOM.html
------------------------------------------------------- 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
