Hallo Arkady,
actually many of your posts makes me to wonder puzzled what you really _mean_. This thread is one of them.
On Sun, 27 Jun 2004, Arkady V.Belousov wrote:
26-éÀÎ-2004 20:35 [EMAIL PROTECTED] (FreeCOM) wrote to [EMAIL PROTECTED]:
Yes, but who know, may be command.com not starts, but loads executable, corrects its environment, then starts it. So, I ask to be sure, because earlier was never think about this.
This option I had never imagined to be the real meaning behind the question:
"I mean, how this options affects environment? Is it _limits_ size of internal buffer, which later used to make environment of new applications?"
Of course, but, for example, NDOS does itself permanent even without /p. BTW, I see no ways to differ INSTALL= and SHELL=.F> Then please tell me, how 4dos is to detect that no other shell is active F> currently, or, to put it into other words, that FreeCOM had been started F> by the kernel's process-0 loader.
Well, I made some tests.
1. MS-command.com never assumes itself primary without /P.
2. without SHELL=, MS-DOS starts command.com with /P option.
3. when SHELL= line wrong or shell exits, MS-DOS tries to automatically run (searched in root, \msdos and \dos directories) command.com with /p and says "Bad or missing Command Interpreter" only when it not finds it.
The kernel also validates the found file that it matches the COMMAND.COM corresponding to the kernel running. (At least before MS DOS 7.)
4. when program runs through INSTALL= and SHELL= in MS-DOS, then parent PSP in env_seg (2C) and parent_PSP (16) contains both zero.
So, with (1) FreeCOM currently is consistent and, probably, may not be changed. Other relate to FreeDOS kernel: (2) is same, (4) I plan to change,
Please don't gallop so fast, how about to make some thinking first.
So, when the environment segment of the primary shell is zero, how are the environment variables passed to it? Could we please discover this fist, before making any changes?
5. MS-command.com places its (resized) segment with environment right after itself (original segment preserved not freed), FreeCOM places environment into UMB, but, as I understand, with LAST_FIT.
MS COMMAND is allocating more memory than necessary, when /E is present, then?
6. I don't know where MS-DOS preserves original environment from config.sys: I not found it in memory.
I guess there is no need to preserve the original environment, is it?
I think, (5) should be changed (LAST_FIT to BEST_FIT).
Why?
F> BTW: Please refer to Undoc DOS's section about to find the master shell F> environment, so we need not discuss stuff like:
How refer it?
By reading it.
F> + INT-2E, F> + environment behind PSP,
The only process, which environment is located after its PSP.
F> + first PSP.
The first PSP in the memory chain.
What there sayed about "first PSP" and what mean "env behind PSP"?
I think, this should be implemented in any case.F> When FreeCOM can determine, if it is or is not the primary shell, it F> will be done.
I mean not primarity, but too verbose startup screen with long help.
Is the following re-wording correct:
You wish that no FreeCOM is to issue so many stuff on startup?
On Sun, 27 Jun 2004, Arkady V.Belousov wrote:
27-éÀÎ-2004 17:56 _te drivesnapshot.de (tom ehlert) wrote to "ArkadyV.Belousov"
<[EMAIL PROTECTED]>:
In this case memory will be allocated in the _best_ segment (shortest, which may fit) or after command.com (as with MS-DOS), if there is no fragmentation.te> one more hint: command.com swaps itself into XMS
And? command.com remain in memory stub, this stub my defragment its memory (when env segment is adjacent with command.com block). Or, in case of adjacent blocks, command.com may swap them (ie. place env segment before itself).
Yes, this requires slightly more work in command.com, but this gives better memory distribution and less holes.
Huh? Actually I think you contradict yourself, when the environment is placed far last there is _no_ fragmentation, no holes, and an optimal memory distribution most of the time. Of course, _if_ a block is available that has the exact size of the environment, this would be the best; but how probable is this situation?
On Sun, 27 Jun 2004, Arkady V.Belousov wrote:
- PSPinit(): DOS_PSP.ps_environ and ps_parent now zero.
Has this something to do with the process 0? What impact does this change have for the first process?
- kernel(): "PATH=." now not placed into empty environment (because bug with copying empty env in task.c:ChildEnv() is fixed).
Actually: The path had been set there because of an old bug of FreeCOM that choked on a non-existant PATH.
Bye,
--
Steffen Kaiser
