Arkady V.Belousov wrote: Hello,
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.
Well, please let me clear up the clouds:
1. When FreeCOM.EnvSeg == 0, how does FreeCOM get the environment from the kernel? -- And, it had a very nice side effect that the SHELL= program did recieved its argv[0] in order to find itself.
2. Do you suggest that when FreeCOM.ParentPSP == 0, FreeCOM is to assume that it runs from either INSTALL= or SHELL= and shallt assume /P?
SK> Could we please discover this fist, before making any changes?
Of course, I test my changes.
Well, I meant: Before your change, FreeCOM was able to
a) find itself without problems, b) get the CONFIG.SYS env vars.
Now: Neither is possible.
This "change" for compatibly is too far in my mind and I would like to know the advantage of the current behaviour in comparison to the drop of freatures. Because I see none.
I assume that there is a point to not pass an environment to INSTALL= programs as they might not deallocate them.
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.
You said: "original segment preserved not freed", so the original block of memory remains unused and allocated in memory.
Or is this the specific behaviour of the permanent or secondary instance?
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 thought they don't get any environment?
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
Wouldn't that (to join A000 segment into base memory) happen during DEVICE= or INSTALL= 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).
Yes, it is possible. Therefore I asked about how possible it is.
Anyway, I made the /LOW option of FreeCOM work. So you can relocate the environment block whereever you like from within AUTOEXEC.BAT. As I said: FreeCOM relys on the FreeCOM.EnvSeg pointer for all its operations and it is guaranteed that all cached data is flushed, when FreeCOM gets re-activated after running an external command.
It is currently not possible to use FIRST_FIT (and therefore BEST_FIT neither) and I do not hassle with the XMS code to move the environment segment around. If you want to offer a patch I will happily add it to the contrib section.
Bye, -- Steffen Kaiser
The current maintainer of [EMAIL PROTECTED] http://freedos.sourceforge.net/freecom/FreeCOM.html
-------------------------------------------------------
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
