Hi!
30-Июн-2004 00:54 [EMAIL PROTECTED] (FreeCOM) wrote to
[EMAIL PROTECTED]:
>> 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.
F> Well, please let me clear up the clouds:
F> 1. When FreeCOM.EnvSeg == 0, how does FreeCOM get the environment from
F> the kernel?
Under MS-DOS FreeCOM.ps_environ will be zero only if you load FreeCOM
from INSTALL and there are no SETs. Under FreeDOS FreeCOM.ps_environ never
be zero (unless FreeCOM is runned by some application, which already clears
own.ps_environ and don't pass environment in exec_block).
_If_ under "FeeCOM.EnvSeg" you mean "DOS_PSP.ps_environ" (where DOS_PSP
is a root and parent to your FreeCOM), then this field is unimportant,
because environment passed through exec_block (see (2) above).
F> -- And, it had a very nice side effect that the SHELL=
F> program did recieved its argv[0] in order to find itself.
1. MS-DOS _clears_ child.ps_environ (for INSTALL= or SHELL=) if there are no
SETs in config.sys, so you can't get startup path.
2. FreeDOS always makes environment segment for child, even if main part
(with "variables") is empty or (exe_block.env_seg=0 &&
parent.ps_environ=0). In this case there present only startup path. And
this is changed/commented by you:
______________O\_/_________________________________\_/O______________
/* Every process requires an environment because of argv[0]
-- 1999/04/21 ska
*/
_____________________________________________________________________
O/~\ /~\O
3. I don't change this (I agreed that startup path should be passed even if
there is no main part of environment), but I change INSTALL=, which now
passes SETs to child environment (through exec_block, because
DOS_PSP.ps_environ now zero, as in MS-DOS).
F> 2. Do you suggest that when FreeCOM.ParentPSP == 0, FreeCOM is to assume
F> that it runs from either INSTALL= or SHELL= and shallt assume /P?
Do you mean: "if FreeCOM finds that its _parent_ PSP contains
ps_parent==0 (ie, it have no grandfather), then it should make yourself
permanent (set own ps_parent yo itself)?"? Yes, this behavior may be useful:
some users may forget to add /P into SHELL= line and will be confused after
casual extra line (because, unlike MS-DOS, which automatically tries to
restart command.com, FreeDOS directly asks path to command interpreter).
>> SK> Could we please discover this fist, before making any changes?
>> Of course, I test my changes.
F> Well, I meant: Before your change, FreeCOM was able to
F> a) find itself without problems,
F> b) get the CONFIG.SYS env vars.
F> Now: Neither is possible.
?! How you make this conclusion without trying my edition?! Of course,
FreeCOM's startup path, as eralier, present in environment. Of course,
config.sys SETs, as earlier, passed to shell. Difference for FreeCOM is that
_now_ there will be neither variables duplication, nor empty variables
("A=B\0A=\0"). Also difference is that now DOS_PSP (which is parent for
FreeCOM PSP) contains zero in ps_environ.
F> This "change" for compatibly is too far in my mind and I would like to
F> know the advantage of the current behaviour in comparison to the drop of
F> freatures. Because I see none.
What you mean by this sentence?! Which "change"? Which "drop" and which
"features"?
F> I assume that there is a point to not pass an environment to INSTALL=
F> programs as they might not deallocate them.
Again:
1. FreeDOS makes environment always; in case of empty main part, there will
be only startup path, but environment (with this path) present anyway.
2. If you (now) don't wish to see (extra) SETs in environment of given
INSTALL= program, just define variables _after_ this INSTALL= (unlike
MS-DOS, in my patch SETs processed at same pass, as INSTALL=) or remove
them (now, with my path you may remove variables with "SET V="; now, into
environment will not be added "V=").
>>>>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.
F> You said: "original segment preserved not freed", so the original block
F> of memory remains unused and allocated in memory.
Don't know about "unused" (may be, MS-command.com uses it for own
needs), but yes: original block remains in memory:
______________O\_/_________________________________\_/O______________
-127F 2.25k LASTDRIVE=
127F 80 <system>
1284 48 COMMAND data area
1287 2.59k COMMAND
132D 272 COMMAND environment
133E 563k --free--
_____________________________________________________________________
O/~\ /~\O
F> Or is this the specific behaviour of the permanent or secondary instance?
Behavior if MS-command.com doesn't changed regardless if it runs
through INSTALL= or SHELL=, with or without /P:
______________O\_/_________________________________\_/O______________
-127F 2.25k LASTDRIVE=
-1289 160 INSTALL=
1289 48 COMMAND data area
128C 2.59k COMMAND
1332 272 COMMAND environment
1343 374k --free--
70DE 188k <8EB1>
-------
9FFF 69.1k <system>
_____________________________________________________________________
O/~\ /~\O
______________O\_/_________________________________\_/O______________
-127F 2.25k LASTDRIVE=
-1289 160 INSTALL=
1289 48 COMMAND data area
128C 2.59k COMMAND
1332 272 COMMAND environment
1343 96 COMMAND data area
1349 2.59k COMMAND
13EF 272 COMMAND environment
1400 371k --free--
70DE 188k <8EB1>
-------
9FFF 69.1k <system>
_____________________________________________________________________
O/~\ /~\O
______________O\_/_________________________________\_/O______________
-127F 2.25k LASTDRIVE=
127F 80 <system>
1284 48 COMMAND data area
1287 2.59k COMMAND
132D 272 COMMAND environment
133E 563k --free--
-------
9FFF 69.1k <system>
_____________________________________________________________________
O/~\ /~\O
______________O\_/_________________________________\_/O______________
-127F 2.25k LASTDRIVE=
127F 80 <system>
1284 48 COMMAND data area
1287 2.59k COMMAND
132D 272 COMMAND environment
133E 96 COMMAND data area
1344 2.59k COMMAND
13EA 272 COMMAND environment
13FB 560k --free--
-------
9FFF 69.1k <system>
_____________________________________________________________________
O/~\ /~\O
>>>>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.
F> I thought they don't get any environment?
Why you make such wrong thought? Of course, next INSTALL= and/or SHELL=
gets the same original environment, as previous instance. Where MS-DOS
preserves those original envirionment, I don't know, but FreeDOS stores (up
to 128 bytes) environment at 60:80.
>>>>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
F> Wouldn't that (to join A000 segment into base memory) happen during
F> DEVICE= or INSTALL= time?
Not neccessarily. There exists program, like VIDRAM.EXE from QEMM
package, which joins (and splits back) video area to base memory at any
time.
>> 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> Yes, it is possible. Therefore I asked about how possible it is.
Not very often. If you have small amount of (total) UMBs and/or have
many (big) programs.
F> Anyway, I made the /LOW option of FreeCOM work. So you can relocate the
F> environment block whereever you like from within AUTOEXEC.BAT. As I
How? As I understand, this may and should affect already runned
(primary) FreeCOM only if this options given before its run (for example,
SHELL=command.com /low /p)? And, who says that placing environment into
upper memory is bad? I say, that using LAST_FIT is bad stategy (for UMBs
this makes inoptimal memory usage, in low memory this makes fragmented
memory when VIDRAM is used).
F> said: FreeCOM relys on the FreeCOM.EnvSeg pointer for all its operations
F> and it is guaranteed that all cached data is flushed, when FreeCOM gets
F> re-activated after running an external command.
This is your deal, I don't say anything about FreeCOM own (child) PSP.
F> It is currently not possible to use FIRST_FIT (and therefore BEST_FIT
F> neither) and I do not hassle with the XMS code to move the environment
F> segment around.
Look at memory map above again. And look at FreeCOM map:
______________O\_/_________________________________\_/O______________
-0FA7 2.01k STACKS=
0FA7 64 --free--
0FAB 2.87k COMMAND
1063 574k --free--
9FEF 272 COMMAND environment
-A000-
_____________________________________________________________________
O/~\ /~\O
F> If you want to offer a patch I will happily add it to
F> the contrib section.
I can't, because this requires to start to study FreeCOM sources. :(
-------------------------------------------------------
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
