ljz@fxgrp.UUCP (Lloyd Zusman) (05/20/88)
I know about the /E:XXXX parameter to COMMAND.COM which, in later
versions of DOS, will allow you to set the size of your enviroment.
So, by typing ...
COMMAND /E:4096
... I will be in a DOS subshell with 4K of enviroment space.
But many programs, as part of their normal operations, will allow you
to get into a DOS subshell. Presumably, these programs either run
COMMAND.COM directly, or they look at COMSPEC and use whatever it is
set to. In either case, very few (if any) of these programs bother to
pass /E:XXXX to the command processor when they start it up. This
results in the subshell allocating just enough space to hold the
parent's environment, NOT COUNTING THE UNUSED ENVIRONMENT SPACE. In
other words, if the parent was invoked with /E:4096 and the child was
invoked without any /E parameter, and if the parent had, say, 256
bytes of its enviromnent in use, the child would only end up with just
a few bytes more than 256 bytes of enviroment space, making it damn
near impossible to set any new environment entries.
[ note that there is a minimum size for an environment ... I'm
talking about cases where more than the minimum size is in use ].
I can think of two ways around this, neither of them totally
acceptable:
1) Patch COMMAND.COM so that the default enviroment size is
large enough. This is a bad practice, in general, but I
guess I could do it if nothing else is possible.
2) Every time I enter a subshell generated by a program, I should
type ...
COMMAND /E:XXXX
... where XXXX is big enough. This would put me in a sub-sub-shell
with enough environment space. But this is an annoyance, and it
takes up more memory (but is it true that DOS subshells only use
up a small amount of extra memory?).
Can any of you think of any other way around this problem? Is there some
magic memory location in which I can put the default size of a subshell's
environment (i.e., a memory location that is fixed and not relative to
the load point of some subshell or another)? Any other ideas?
By the way, I am running vanilla PCDOS 3.30.
Thanks in advance for any help you can give me.
--
Lloyd Zusman UUCP: ...!ames!fxgrp!ljz
Master Byte Software Internet: ljz%fx.com@ames.arc.nasa.gov
Los Gatos, California or try: fxgrp!ljz@ames.arc.nasa.gov
"We take things well in hand."coulter@hpclisp.HP.COM (Michael Coulter) (05/22/88)
A technique that is sometimes useful is to define several large strings in
the parent's environment. If you find yourself in a subshell running out
of space you can wipe out the junk strings and get some space.
This is a lousy work-around but sometimes better than nothing. Could the
system be patched somewhere to force the allocation of more space by
default?
-- Michael Coulter ...{ucbvax|hplabs}!hpda!coultertneff@dasys1.UUCP (Tom Neff) (05/24/88)
In article <629@fxgrp.UUCP> ljz%fx.com@ames.arc.nasa.gov (Lloyd Zusman) points out that most programs don't allocate any extra environment space when shelling down to COMMAND.COM, regardless of whether you have done so yourself at the top level with a /E:XXXX switch in CONFIG.SYS. Instead, the shelled process gets an environment segment just large enough to contain the SETs used by the parent process, leaving little or no room for expansion at the child level. He mentions two possible workarounds -- patching COMMAND.COM for a larger default environment size, and including another /E:XXXX switch in each COMMAND.COM line used for shelling. Both have obvious limitations, and he asks: >Can any of you think of any other way around this problem? Yes. Before you shell, issue a dummy SET XX=XXXXXXX.... of sufficient length to (a) cover your child process's anticipated needs, or (b) fill the environment segment, whichever. Then when your child process receives control from the shell operation, the first thing it does is clear the dummy SET leaving lots of free space to work with. This is guaranteed to work with all flavors of DOS and requires no special version specific knowledge, so I recommend it instead of patches etc. -- Tom Neff UUCP: ...!cmcl2!phri!dasys1!tneff "None of your toys CIS: 76556,2536 MCI: TNEFF will function..." GEnie: TOMNEFF BIX: are you kidding?
bob@acornrc.UUCP (Bob Weissman) (05/31/88)
This is a patch to increase the default environment size for the
version of COMMAND.COM which comes with MSDOS 3.30.
Load a copy of COMMAND.COM into DEBUG, and say "U0EA3". You'll see
several lines of code. The interesting one is at location 0EB4 -- it's
MOV WORD PTR[1650],000A
The 000A is the number of paragraphs COMMAND.COM allocates for the
environment by default. You may increase the environment size from 160
bytes to, say, 384 bytes, by typing "A0EB4" and then entering
MOV WORD PTR[1650],0018
and then saying "W" to write the file back out. Do take the usual
precaution of running DEBUG on a copy, or at least backing up
COMMAND.COM before running DEBUG.
Disclaimer: I assume no responsibility for trashed command
interpreters; I found this patch by searching with DEBUG, not by any
inside knowledge. MSDOS 3.30 is the only version of DOS I have
available; this instruction, or its equivalent, is doubtless in a
different place in other versions.
--
Bob Weissman
Internet: bob@acornrc.uucp
UUCP: ...!{ ames | decwrl | oliveb | pyramid }!acornrc!bob
Arpanet: bob%acornrc.uucp@ames.arc.nasa.govjvc@mirror.TMC.COM (Jim Champeaux) (06/01/88)
In article <835@acornrc.UUCP> bob@acornrc.UUCP (Bob Weissman) writes: >This is a patch to increase the default environment size for the >version of COMMAND.COM which comes with MSDOS 3.30. > > [deleted instructions on how to patch] I must be missing something. Why patch command.com when you can use the config.sys file to specify an environment size larger than the default (versions 3.xx and up, maybe not 3.0)? I would understand it if secondary shells always used the default size, but they don't. The environment of the secondary shell is always at least as large as the shell it was started from. The environment of the secondary shell can even be made larger than its parent's environment (by using the /e switch). Puzzled, jvc@mirror.tmc.com
bob@acornrc.UUCP (Bob Weissman) (06/02/88)
In article <14488@mirror.TMC.COM>, jvc@mirror.TMC.COM (Jim Champeaux) writes: > I must be missing something. Why patch command.com when you can use > the config.sys file to specify an environment size larger than the > default (versions 3.xx and up, maybe not 3.0)? I would understand it > if secondary shells always used the default size, but they don't. > The environment of the secondary shell is always at least as large as > the shell it was started from. The environment of the secondary shell > can even be made larger than its parent's environment (by using the > /e switch). Because, as mentioned in an earlier article today, specifying shell=command.com /e:nnnn in config.sys prevents execution of autoexec.bat. I too tried various combinations of /e, /c, and /p but could not get the default behavior to occur. Also because I enjoy hacking on this machine :-) and feel that MicroSoft's default of only 160 bytes is too low and a one-word patch takes care of the problem once and for all. I.e., why *not* patch command.com? -- Bob Weissman Internet: bob@acornrc.uucp UUCP: ...!{ ames | decwrl | oliveb | pyramid }!acornrc!bob Arpanet: bob%acornrc.uucp@ames.arc.nasa.gov
johnl@ima.ISC.COM (John R. Levine) (06/02/88)
In article <849@acornrc.UUCP> bob@acornrc.UUCP (Bob Weissman) writes: > >Because, as mentioned in an earlier article today, specifying > shell=command.com /e:nnnn >in config.sys prevents execution of autoexec.bat. ... You need the /P flag. I use the following under PCDOS 3.3: shell = \sys\command.com /E:350 /P (My system files are all in a directory called \sys.) It runs autoexec just fine. Incidentally, page 4-43 of the PC DOS 3.3 manual, which documents the SHELL command, has a paragraph at the end specifically explaining this. -- John R. Levine, IECC, PO Box 349, Cambridge MA 02238-0349, +1 617 492 3869 { ihnp4 | decvax | cbosgd | harvard | yale }!ima!johnl, Levine@YALE.something Rome fell, Babylon fell, Scarsdale will have its turn. -G. B. Shaw
zdb1526@dsachg1.UUCP (06/02/88)
In article <849@acornrc.UUCP>, bob@acornrc.UUCP (Bob Weissman) writes: > In article <14488@mirror.TMC.COM>, jvc@mirror.TMC.COM (Jim Champeaux) writes: > > I must be missing something. Why patch command.com when you can use > > the config.sys file to specify an environment size larger than the > > default (versions 3.xx and up, maybe not 3.0)? I .... > > Because, as mentioned in an earlier article today, specifying > shell=command.com /e:nnnn > in config.sys prevents execution of autoexec.bat. I too tried > various combinations of /e, /c, and /p but could not get the default > behavior to occur. I have SHELL=C:\COMMAND.COM C:\ /E:62\P in my config.sys file on my Z248 running under MSDOS 3.0. This takes care of my environment space problem and my AUTOEXEC.BAT file runs just fine. > Also because I enjoy hacking on this machine :-) and feel that > MicroSoft's default of only 160 bytes is too low and a one-word patch > takes care of the problem once and for all. I.e., why *not* patch > command.com? > Some people DON'T enjoy hacking on their machines :-). . . . . .(I hate this fill, fill, fill!) .
jvc@mirror.TMC.COM (Jim Champeaux) (06/02/88)
In article <849@acornrc.UUCP> bob@acornrc.UUCP (Bob Weissman) writes: >In article <14488@mirror.TMC.COM>, jvc@mirror.TMC.COM (Jim Champeaux) writes: >> I must be missing something. Why patch command.com when you can use >> the config.sys file to specify an environment size larger than the >> ... > >Because, as mentioned in an earlier article today, specifying > shell=command.com /e:nnnn >in config.sys prevents execution of autoexec.bat. I too tried >various combinations of /e, /c, and /p but could not get the default >behavior to occur. You must use the /p switch. This tells command.com that it is the permanent copy (can't exit from it with EXIT) and that it should do all initial processing like executing autoexec.bat. I use the following in my config.sys since the default environment is much too small: (MS-DOS 3.2 -- in 3.1 the argument for /e: is not number of bytes but number of pages): shell = c:\dos\command.com c:\dos\ /p /e:1024 ( note the c:\dos\ parameter -- tells it where to find itself if transient portion is overwritten ) If you now want to run a secondary command.com with a larger environment type the following command: command /e:2048
ericr@hpvcla.HP.COM (Eric Ross) (06/03/88)
I am running MSDOS 3.2 and have had trouble with auto executing autoexec.bat. Shell = C:\COMMAND.COM /E:2048 /P will not execute autoexec.bat but, Shell = C:\COMMAND.COM /E:1024 /P does. Eric Ross Hewlett Packard, Vancouver Division ihnp4!hplabs!hpvclx!ericr
guardian@otishq.UUCP (Harry Skelton) (06/03/88)
In article <3057@crash.cts.com>, rgale@pnet01.cts.com (Ryan Gale) writes: > > Because, as mentioned in an earlier article today, specifying > > shell=command.com /e:nnnn > > in config.sys prevents execution of autoexec.bat. > > Oh? My CONFIG.SYS includes the line > SHELL=C:\COMMAND.COM /E:1024 /P > and AUTOEXEC.BAT runs just fine. [This is PC-DOS 3.3.] > If you have dos version 3.1, you will have to specify a maximum size of 2k only. beyond that you will crash your system. (specs below). 3.2 has the limit removed but still has problems with some programs and utilities trying to read the environment (command.com will crash with a +2k environment. 3.3 is fine but some programs don't understand the environment size. summary: 3.0: Have to fix an offset in command.com MKS's init.exe with a login of dos can fix this but I have not tested it with many programs. 3.1: environment set in blocks of 16bytes. Max is 2k w/possible 1k on generic versions of MS-DOS 3.1 (tandy and wyse is bad for this). 3.2: environment size fixed (most versions of MS-Dos - depends on bios). Buff size is 16bytes (i.e. /E:10 = 160 bytes). Sometimes command.com gets confused beyond 25 if a tsr is loaded prior to command.com. 3.3 environment size correct. Buff size is in BYTES! /E:2048 = 2k environment. I think this is correct and has worked for my machine. I run IBM-DOS versions and have had no problems with the above. _ _ ___ | | |_| _ ___________ _____ _____ __/ / | |__ _ ____ | |__ / _____/ // _ // _ // / | || || . || | /__ // / // __// ___// / / |__|_||_||__ ||__|_|/_____// __//____//____//____/ ..!daitc!otishq!highspeed |_____| /_/ "Hello Computer!" <hi Tavo **chuckle**>
bobmon@iuvax.cs.indiana.edu (RAMontante) (06/06/88)
guardian@otishq.UUCP (Harry Skelton) writes: > >3.1: environment set in blocks of 16bytes. Max is 2k w/possible 1k on ^^^^^^ called "paragraphs" >3.2: environment size fixed (most versions of MS-Dos - depends on bios). >Buff size is 16bytes (i.e. /E:10 = 160 bytes). Sometimes command.com >gets confused beyond 25 if a tsr is loaded prior to command.com. For (Zenith's release of) v3.21, the environment size is specified in bytes, not paragraphs. Documentation describes this (it didn't in v3.10). -- -bob,mon "In this position, the skier is flying in a complete stall..."
phil@dhw68k.cts.com (Phil Suematsu) (06/09/88)
In article <14488@mirror.TMC.COM> jvc@prism.TMC.COM (Jim Champeaux) writes: >In article <835@acornrc.UUCP> bob@acornrc.UUCP (Bob Weissman) writes: >>This is a patch to increase the default environment size for the >>version of COMMAND.COM which comes with MSDOS 3.30. >> >> [deleted instructions on how to patch] > >I must be missing something. Why patch command.com when you can use >the config.sys file to specify an environment size larger than the >default (versions 3.xx and up, maybe not 3.0)? >[...] >Puzzled, >jvc@mirror.tmc.com I have to patch COMMAND.COM for a larger environment because when DESQview creates a DOS window, it fools COMMAND.COM into thinking that there were no previous environments. In other words, DESQview does not allow the DOS window to inherit any enviroment variables from your previous DOS environment; nor does it create an environment with the same size as your previous environment -- it creates an empty environment with the insufficient default size hardcoded in COMMAND.COM. The solution is to patch COMMAND.COM for a larger default size and for the 'Program...:' parameter in the DOS window 'Change a Program' screen, specify a batch file that SETs up your environment variables. Without this patch, I would not be able to run programs, that require many environment variables, within a DOS window, such as, Brief and uupc. Oh, I guess I could create *another* command shell within the DOS window using the '/E' parameter, but this consumes 6k of precious RAM (RAM is precious when you begin to partition it within DESQview). By the way, can anyone, who has bought a 'Charge Card' memory board for use with DESQview, tell us if it works as advertised? Phil -- ---------------+------------------------------------------------------ Phil Suematsu | InterNet: phil@dhw68k.cts.com or phil@turnkey.tcc.com (714) 633-0876 | or uucp: ...{trwrb,hplabs}!felix!dhw68k!phil ---------------+------------------------------------------------------