Hi!

30-Июн-2004 08:53 [EMAIL PROTECTED] (Steffen Kaiser) wrote
to "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>:

>>     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> Good, I will file this as enhancement request.

     Let me add: this is _now_ DOS_PSP.ps_parent is equal to zero, 2035
kernel sets .ps_parent to itself (60h), so you may check "if
parent.ps_parent < LOL->first_mcb, then we may make ourself permanent". This
should work also under MS-DOS (6), because its DOS_PSP.ps_parent==0.

>>     Don't know about "unused" (may be, MS-command.com uses it for own
>> needs), but yes: original block remains in memory:
SK> Wild guess:
SK> maybe, this is the persistent environment you were searching for?

     I think about this, but no. If I change contents of this memory (in
debug), say, A=B to A=C, then after exit command.com I get unchanged A=B.

>> 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
SK> So, why would be "FIRST_FIT" or even "BEST_FIT" optimal? It cannot,
SK> neither.

     Why? With UMBs BEST_FIT will place environment into smallest block
(hole); when there are no UMBs, environment may be placed right after
command.com code, so with swapping this may make more fragmentation, but who
prevent you to defragment memory? This also reuses memory from original
environment (do you see 48 free bytes before command.com?).

     BTW, may be this helps: SMARTDRV exec itself when it wish to load
itself high, thus, it don't worry about code relocation. For command.com
this is not the best strategy (because longer startup), but may be used as
Q&D (quick and dirty) hack.

SK> Optimal would be when the user could decide where to place which
SK> part. But this is no option at the current time.

>> 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.
SK> Huh? You said you need to have the environment segment placed somewhere
SK> else.

     I said, me not liked that command.com allocates memory block with
LAST_FIT strategy (notwithstanding that this is environment or not).

SK> I did not mentioned the PSP as well. You can write a program to move
SK> the parent's environment to any location you like.

     Yes, I may. But this (private program) will not help for other user,
which will not get better memory distribution (and, probably, will never
understand that there is possible better).

SK> That is the most optimal placement I can imagine.

>> 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:
>>  -0FA7   2.01k               STACKS=
>> 0FA7       64                --free--
>> 0FAB     2.87k   COMMAND
>> 1063      574k               --free--
>> 9FEF      272    COMMAND     environment
>> -A000-
SK> But what do I see here in conjunction that "It is currently not possible
SK> to use FIRST_FIT (and therefore BEST_FIT neither)" for FreeCOM?

     I don't know "what you see here", but I see that FreeCOM places
environment before video memory (thus preventing it as expansion to base
memory) and ther there remains hole before its code.

PS: I understand, that _currently_ you may wish not to bother with FreeCOM
code relocation (I think, if there are no UMBs, better if it will place its
new environment right before itself, over old environment segment), but
which _other_ contras you have against this?




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

Reply via email to