The FreeDOS Project

Arkady V.Belousov wrote:

>      2Steffen Kaiser: Steffen, how FreeCOM handles /E option? I mean, how
> this options affects environment? Is it _limits_ size of internal buffer,

It resizes the block of memory the environment of FreeCOM resides in.

> which later used to make environment of new applications?

FreeCOM does not use no internal buffer for the environment, but 
performs all operations on the environment segment.

> PS: When I run FreeCOM through SHELL= or INSTALL= without /P option, it
> doesn't makes itself primary.

When FreeCOM is started with the /P option, it makes itself permanent.

> PPS: When start (as secondary), FreeCOM shows list of internal commands. I

That's true and will change when the settings inheritance becomes 
implemented.

Tschuess,

-- 
Steffen Kaiser

The current maintainer of FreeCOM@...
http://freedos.sourceforge.net/freecom/FreeCOM.html

Hi!

26-=E9=C0=CE-2004 16:49 _freecom@... (FreeCOM) wrote to
freedos-freecom@...:

F> FreeCOM does not use no internal buffer for the environment, but
F> performs all operations on the environment segment.

     Ie. applications always get reduced (to size of contents) envrionmen=
t
memory block (notwithstanding /E, which affect only command.com' memory)?

>> PS: When I run FreeCOM through SHELL=3D or INSTALL=3D without /P optio=
n, it
>> doesn't makes itself primary.
F> When FreeCOM is started with the /P option, it makes itself permanent.

     Of course, but, for example, NDOS does itself permanent even without
/p. BTW, I see no ways to differ INSTALL=3D and SHELL=3D.

>> PPS: When start (as secondary),

     I mean, without /p option.

>> FreeCOM shows list of internal commands. I
F> That's true and will change when the settings inheritance becomes
F> implemented.

     I think, this should be implemented in any case.

Arkady V.Belousov wrote:

>      Ie. applications always get reduced (to size of contents) envrionment
> memory block (notwithstanding /E, which affect only command.com' memory)?

Hmm, Arkady, you fixed yourself a bug (or at least complained about a 
bug) in the kernel's environment handling when invoking a child, hence, 
you know very well that the kernel creates the environment passed to a 
child, not FreeCOM.
This is also the behaviour of MS COMMAND/MS Kernel as far as I know.

>      Of course, but, for example, NDOS does itself permanent even without
> /p. BTW, I see no ways to differ INSTALL= and SHELL=.

Then please tell me, how 4dos is to detect that no other shell is active 
currently, or, to put it into other words, that FreeCOM had been started 
by the kernel's process-0 loader.
BTW: Please refer to Undoc DOS's section about to find the master shell 
environment, so we need not discuss stuff like:

+ INT-2E,
+ environment behind PSP,
+ first PSP.

>      I think, this should be implemented in any case.

When FreeCOM can determine, if it is or is not the primary shell, it 
will be done.

Bye,

-- 
Steffen Kaiser

The current maintainer of FreeCOM@...
http://freedos.sourceforge.net/freecom/FreeCOM.html

Hi!

26-=E9=C0=CE-2004 20:35 _freecom@... (FreeCOM) wrote to
freedos-devel@...:

>>      Ie. applications always get reduced (to size of contents) envrion=
ment
>> memory block (notwithstanding /E, which affect only command.com' memor=
y)?
F> Hmm, Arkady, you fixed yourself a bug (or at least complained about a
F> bug) in the kernel's environment handling when invoking a child, hence=
,

     Yes, task.c:ChidlEnv() contains bug when handling empty environment.

F> you know very well that the kernel creates the environment passed to a
F> child, not FreeCOM.
F> This is also the behaviour of MS COMMAND/MS Kernel as far as I know.

     Yes, but who know, may be command.com not starts, but loads executab=
le,
corrects its environment, then starts it. So, I ask to be sure, because
earlier was never think about this.

>>      Of course, but, for example, NDOS does itself permanent even with=
out
>> /p. BTW, I see no ways to differ INSTALL=3D and SHELL=3D.
F> Then please tell me, how 4dos is to detect that no other shell is acti=
ve
F> currently, or, to put it into other words, that FreeCOM had been start=
ed
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=3D, MS-DOS starts command.com with /P option.

3. when SHELL=3D line wrong or shell exits, MS-DOS tries to automatically=
 run
   (searched in root, \msdos and \dos directories) command.com with /p an=
d
   says "Bad or missing Command Interpreter" only when it not finds it.

4. when program runs through INSTALL=3D and SHELL=3D in MS-DOS, then pare=
nt 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 chang=
e,
(3) isn't necessary, at my teste.

     More tests:

5. MS-command.com places its (resized) segment with environment right aft=
er
   itself (original segment preserved not freed), FreeCOM places environm=
ent
   into UMB, but, as I understand, with LAST_FIT.

6. I don't know where MS-DOS preserves original environment from config.s=
ys:
   I not found it in memory.

I think, (5) should be changed (LAST_FIT to BEST_FIT).

F> BTW: Please refer to Undoc DOS's section about to find the master shel=
l
F> environment, so we need not discuss stuff like:

     How refer it?

F> + INT-2E,
F> + environment behind PSP,
F> + first PSP.

     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.

Hello Arkady,

> 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.

> I think, (5) should be changed (LAST_FIT to BEST_FIT).

I think (5) should be NOT changed

(hint: what happens if you don't have UMB's)

tom

Hi!

27-=E9=C0=CE-2004 15:52 _te@... (tom ehlert) wrote to "Arkad=
y V.Belousov"
<freedos-devel@...>:

>> 5. MS-command.com places its (resized) segment with environment right =
after
>>    itself (original segment preserved not freed), FreeCOM places envir=
onment
>>    into UMB, but, as I understand, with LAST_FIT.
>> I think, (5) should be changed (LAST_FIT to BEST_FIT).
te> I think (5) should be NOT changed
te> (hint: what happens if you don't have UMB's)

     In this case memory will be allocated in the _best_ segment (shortes=
t,
which may fit) or after command.com (as with MS-DOS), if there is no
fragmentation.

Hello Arkady,

>>> 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.
>>> I think, (5) should be changed (LAST_FIT to BEST_FIT).
te>> I think (5) should be NOT changed
te>> (hint: what happens if you don't have UMB's)

>      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.

one more hint: command.com swaps itself into XMS

Hi!

27-=E9=C0=CE-2004 17:56 _te@... (tom ehlert) wrote to "Arkad=
y V.Belousov"
<freedos-devel@...>:

>>      In this case memory will be allocated in the _best_ segment (shor=
test,
>> 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.