Hi!
28-Июн-2004 08:49 [EMAIL PROTECTED] (Steffen Kaiser) wrote
to "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>,
"[EMAIL PROTECTED]" <[EMAIL PROTECTED]>:
SK> actually many of your posts makes me to wonder puzzled what you really
SK> _mean_. This thread is one of them.
>> 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.
SK> This option I had never imagined to be the real meaning behind the
SK> question:
SK> "I mean, how this options affects environment? Is it _limits_ size of
SK> internal buffer, which later used to make environment of new applications?"
But is this ("command.com changes size of application env") possible
(in theory)? Possible. Anyway, question is closed: as you say, /E sets size
of command.com own env and not affect applications.
>> 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,
SK> Please don't gallop so fast, how about to make some thinking first.
SK> So, when the environment segment of the primary shell is zero, how are the
SK> environment variables passed to it?
1. parent_PSP is a DOS PSP, which parent for command.com PSP (and other
INSTALL programs).
2. env_seg from parent is interested only when _exec block_ (for INT21/4B)
contains zero for consequent (first) field.
3. If exec_block.env_seg == paren_PSP.env_seg == 0, then MS-DOS makes no
environment and sets child_PSP.env_seg=0; FreeDOS (as you comment this in
task.c:ChildEnv()) always makes environment (which contains program
path), even if main part is empty.
4. _Now_ in FreeDOS exec_block.env_seg for INSTALL and SHELL never zero, but
points to internal area with current SETs (and CONFIG=); earlier this was
only for SHELL.
SK> Could we please discover this fist, before making any changes?
Of course, I test my 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.
SK> MS COMMAND is allocating more memory than necessary, when /E is present,
SK> then?
"Than necessary"? You mean, more, than currently defined variables?
Yes. But only for itself.
>> 6. I don't know where MS-DOS preserves original environment from config.sys:
>> I not found it in memory.
SK> I guess there is no need to preserve the original environment, is it?
When INSTALL or SHELL program exits, kernel should run next INSTALL
and/or SHELL, and should pass there (original) environment from config.sys.
>> I think, (5) should be changed (LAST_FIT to BEST_FIT).
SK> Why?
For example, current FreeCOM makes fragmented memory when video memory
joined to base memory (and there is no UMBs, and FreeCOM places its env
right before A000). Also, usually last UMB is the biggest block, thus there
is possible that placing your env into (end of) biggest block prevents to
loading some (big) executable into this block (and it runs low).
>> F> BTW: Please refer to Undoc DOS's section about to find the master shell
>> How refer it?
SK> By reading it.
I don't have this book.
>> F> + INT-2E,
>> F> + environment behind PSP,
SK> The only process, which environment is located after its PSP.
? For any process environment may be placed after its PSP (for example,
in UMB, when program itslef in low memory). Or you mean, that DOS PSP
contains environment right after its PSP? In MS-DOS this is not so: INSTALL
and SHELL runs by initialization part (before A000), which makes own (root)
PSP in own memory, and there parent==env_seg=0.
>> F> + first PSP.
SK> The first PSP in the memory chain.
And?
>> I mean not primarity, but too verbose startup screen with long help.
SK> Is the following re-wording correct:
SK> You wish that no FreeCOM is to issue so many stuff on startup?
I wish less verbosity on startup screen.
>> 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.
SK> Huh? Actually I think you contradict yourself, when the environment is
SK> placed far last there is _no_ fragmentation, no holes, and an optimal
SK> memory distribution most of the time.
I explain above why this is not the best strategy. Placing env seg into
end of MCB chain good in only one case: when there will no UMBs and/or you
will not join video memory to base memory.
SK> Of course, _if_ a block is available that has the exact size of the
SK> environment, this would be the best; but how probable is this situation?
This is probable, especially when there is some UMBs, which almost
filled. _I_ know this, some time I was forced to play with shuffling
programs in UMBs to better reuse upper memory.
>> - PSPinit(): DOS_PSP.ps_environ and ps_parent now zero.
SK> Has this something to do with the process 0?
What _you_ mean by process 0? Shell (as this meaned by comments in
kernel sources)? If yes, then this not relates to shell.PSP, only to root
PSP, which is parent for INSTALL and SHELL programs.
SK> What impact does this change have for the first process?
Same, as in MS-DOS. :) If program/shell doesn't touches parent PSP,
then it will not even know what these fields contain.
>> - kernel(): "PATH=." now not placed into empty environment (because bug with
>> copying empty env in task.c:ChildEnv() is fixed).
SK> Actually: The path had been set there because of an old bug of FreeCOM
SK> that choked on a non-existant PATH.
I test with command.com from 2035 archive and it runs fine with empty
environment (for example, when F5 pressed at startup).
-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
digital self defense, top technical experts, no vendor pitches,
unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
Freedos-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-devel
