agollum@engr.uky.edu (David Herron aka Admiral Gollum) (01/05/88)
Maybe I'm being dense, but how does one determine the size of the environmment space (ie, how much room there is for environment variables) from within a program? I can read the environment just fine, I just don't know how much free space there is. (Assuming I ever get this answered, is anyone interested in a Turbo Pascal unit to handle the environment space?) Kenneth Herron
emb978@leah.Albany.Edu ( Eric M. Boehm) (01/07/88)
In article <1900@ukecc.engr.uky.edu>, agollum@engr.uky.edu (David Herron aka Admiral Gollum) writes: > Maybe I'm being dense, but how does one determine the size of the > environmment space (ie, how much room there is for environment > variables) from within a program? I can read the environment just > fine, I just don't know how much free space there is. > Assuming you are running MS-DOS 3.2, the default environment space is (I believe) 256 bytes. You can change this by inserting the following line into your config.sys file: shell=c:\dos\command.com c:\dos /e:nnnn /p where C:\dos\command.com tells DOS where to load command.com from the *FIRST* time it is loaded, c:\dos tells dos the pathname to load subsequent copies of command.com (in case that area of memory is overwritten by your application program), /e:nnnn tells DOS how many bytes to reserve for environment space (in 3.1 this number is in paragraphs [16 bytes] so just divide by 16), and /p tells DOS that this is the primary processor for the exit command (usually to get out of child processes). I don't believe this works below 3.x (I have had conflicting reports) but it does work in 3.1 and 3.2 (at least for me). You can change the path to your copy of command.com as suits your needs. One last note, you will still need a copy of command.com in the root in order to format disks properly (no, I don't know why). Also note that no environment variable can occupy more than 127 (128?) bytes each! Eric M. Boehm EMB978@ALBNY1VX.BITNET EMB978@LEAH.ALBANY.EDU
sweet@scubed.UUCP (Kevin Sweet) (01/08/88)
In article <554@leah.Albany.Edu> emb978@leah.Albany.Edu (Eric M. Boehm) writes: ->In article <1900@ukecc.engr.uky.edu>, agollum@engr.uky.edu (David Herron) writes: ->-> Maybe I'm being dense, but how does one determine the size of the ->-> environmment space (ie, how much room there is for environment ->-> variables) from within a program? I can read the environment just ->-> fine, I just don't know how much free space there is. ->-> -> ->Assuming you are running MS-DOS 3.2, the default environment space is (I ->believe) 256 bytes. -> ->You can change this by inserting the following line into your config.sys ->file: -> ->shell=c:\dos\command.com c:\dos /e:nnnn /p -> ->where C:\dos\command.com tells DOS where to load command.com from the ->*FIRST* time it is loaded, c:\dos tells dos the pathname to load subsequent ->copies of command.com (in case that area of memory is overwritten by your ->application program), /e:nnnn tells DOS how many bytes to reserve for ->environment space (in 3.1 this number is in paragraphs [16 bytes] so just ->divide by 16), and /p tells DOS that this is the primary processor for the ^ but it is limited to 62 paragraphs in DOS 3.10 (still alot). Any number greater than 62 is ignored and you get the default of 10 paragraphs. ->exit command (usually to get out of child processes). -> ->I don't believe this works below 3.x (I have had conflicting reports) but it ->does work in 3.1 and 3.2 (at least for me). -> ->You can change the path to your copy of command.com as suits your needs. One ->last note, you will still need a copy of command.com in the root in order to ->format disks properly (no, I don't know why). -> ->Also note that no environment variable can occupy more than 127 (128?) bytes ->each! -> ->Eric M. Boehm ->EMB978@ALBNY1VX.BITNET ->EMB978@LEAH.ALBANY.EDU I know this isn't really an answer to the original poster's question but I found the information very useful. I have a copy of some patches to DOS 3.10 that I received from a recent poster (harvard!lhasa!Jerry.Lotto) that cover many different areas (like a patch to command.com that makes 'echo off' the default for batch files) and will send them to anyone who sends me an e-mail request. Stupid, Stupid, DOS. ( no smiley on that last statement |^) Kevin -- ---- kevin sweet -------------------------------- email: sweet@scubed.ARPA ---- work: 3398 carmel mountain, san diego, ca 92121-1095, 619-587-8499 home: 12205 carmel vista 242, san diego, ca 92130-2237, 619-259-9338 ------------- "any misspellings are, of course, made on purpose" --------------
khill@home.csc.ti.com (Ken Hill - Patents) (01/08/88)
In article <554@leah.Albany.Edu> emb978@leah.Albany.Edu ( Eric M. Boehm) writes:
.
.Also note that no environment variable can occupy more than 127 (128?) bytes
.each!
.
This limit has just bitten me for the PATH variable. Is there any way
to have a PATH which is longer than this? Some of the alternate
methods posted here recently are fine, but some software wants to
hunt the PATH looking for various things, and I don't want to store
everything close to the root directory. (Reaching 3 subdirectories each
3 levels down burns up that 128 bytes real fast)
I am using MS-DOS 3.3. Does anyone have any patches which will allow
a larger PATH variable, or other fixes (short of restructuring my disk)
which will allow searching on the PATH variable? (I don't have source
to some of this software, so fixing it at that level is not an option.)
Thanx.
There are no typos. If you think you saw one, see an opthamolo... optaha...
ophthamal... eye doctor.
Ken Hill
{convex!smu, texsun,im4u,seismo!ut-sally!im4u}!ti-csl!khillrod@cpocd2.UUCP (Rod Rebello) (01/08/88)
In article <554@leah.Albany.Edu> emb978@leah.Albany.Edu ( Eric M. Boehm) writes: >... >Also note that no environment variable can occupy more than 127 (128?) bytes ^^^^^^^^^^ Does anyone know of a way to increase the environment variable size? Or is this just not doable?
Usenet_area_"Cs.I.Pc"@watmath.waterloo.edu (01/09/88)
From Usenet: pollux!ti-csl!home!khill From: khill@home.csc.ti.com (Ken Hill - Patents) Newsgroups: comp.sys.ibm.pc Subject: Re: Environment space size? Keywords: environment variables size Message-ID: <39592@ti-csl.CSNET> Date: 8 Jan 88 19:42:32 GMT References: <1900@ukecc.engr.uky.edu> <554@leah.Albany.Edu> Sender: news@ti-csl.CSNET Reply-To: khill@home.UUCP (Ken Hill - Patents) Distribution: na Organization: TI Computer Science Center, Dallas Lines: 22 Posted: Fri Jan 8 13:42:32 1988 In article <554@leah.Albany.Edu> emb978@leah.Albany.Edu ( Eric M. Boehm) writes: . .Also note that no environment variable can occupy more than 127 (128?) bytes .each! . This limit has just bitten me for the PATH variable. Is there any way to have a PATH which is longer than this? Some of the alternate methods posted here recently are fine, but some software wants to hunt the PATH looking for various things, and I don't want to store everything close to the root directory. (Reaching 3 subdirectories each 3 levels down burns up that 128 bytes real fast) I am using MS-DOS 3.3. Does anyone have any patches which will allow a larger PATH variable, or other fixes (short of restructuring my disk) which will allow searching on the PATH variable? (I don't have source to some of this software, so fixing it at that level is not an option.) Thanx. There are no typos. If you think you saw one, see an opthamolo... optaha... ophthamal... eye doctor. Ken Hill {convex!smu, texsun,im4u,seismo!ut-sally!im4u}!ti-csl!khill --- via UGate v1.6 * Origin: watmath (221/163)
leonard@bucket.UUCP (Leonard Erickson) (01/09/88)
While we're "on the subject", can anyone tell me why an EXEC from Turbo Pascal
4.0 or a SHELL from a compiled BASIC program always results in a *smaller*
environment?
Specifically, when I do either of the following:
BASIC: SHELL("LOTUS.BAT")
Pascal: exec('command.com','/c lotus.bat');
Where LOTUS.BAT is the following:
c:
cd\lotus2
prompt Type "EXIT" and press RETURN to return to Lotus 1-2-3$_$p$g
lotus
prompt $p$g
c:
cd\
I get an "Out of environment space" msg when the bat file runs. Using the
/S option in Lotus (2.01) gets a prompt that ends at the 't' in 'return'.
But if I run the same bat file from DOS it works....
And no matter *how* much environment space I setup it still happens if I
run it as a child process. I get the impression that DOS only passes along
the environment variables and a paragraph or so of 'extra' environment space?!
--
Leonard Erickson ...!tektronix!reed!percival!bucket!leonard
CIS: [70465,203]
"I used to be a hacker. Now I'm a 'microcomputer specialist'.
You know... I'd rather be a hacker."tsl@netsys.UUCP (Tom Livingston) (01/10/88)
In article <1055@cpocd2.UUCP> rod@cpocd2.UUCP (Rod Rebello) writes: >In article <554@leah.Albany.Edu> emb978@leah.Albany.Edu ( Eric M. Boehm) writes: >>... >>Also note that no environment variable can occupy more than 127 (128?) bytes > ^^^^^^^^^^ >Does anyone know of a way to increase the environment variable size? >Or is this just not doable? Enviroment variables are kept in the env. space by seperating them with a null. In theory, you could expand the variable and but the null farther along, but it's possible that many programs have 128 byte variables set aside for them, and they would only get the first 128 bytes. ( just an idea, I honestly don't know, so this could be all wrong) _____________ / --/ __ _______ (_/ (_) / / / <_ Livingston { decuac,ihnp4 }!netsys!tsl
jru@etn-rad.UUCP (John Unekis) (01/12/88)
In article <39592@ti-csl.CSNET> khill@home.UUCP (Ken Hill - Patents) writes: >In article<554@leah.Albany.Edu>emb978@leah.Albany.Edu ( Eric M. Boehm) writes: >. >.Also note that no environment variable can occupy more than 127 (128?) bytes >.each! >. >This limit has just bitten me for the PATH variable. Is there any way >to have a PATH which is longer than this? Some of the alternate >methods posted here recently are fine, but some software wants to >hunt the PATH looking for various things, and I don't want to store >everything close to the root directory. (Reaching 3 subdirectories each >3 levels down burns up that 128 bytes real fast) >... My usual solution to the inadequate path string size is to utilize the SUBST command in my autoexec.bat file . For instance- PATH=c:\;c:\dos\;c:\dos\subdir1\;c:\dos\subdir1\subdir2\ ...becomes... SUBST G: c:\dos SUBST H: c:\dos\subdir1 SUBST I: c:\dos\subdir1\subdir2 PATH=c:\;g:\;h:\;i:\ The SUBST command does not use any environment space(so far as I can tell). NOTE: you will need to add a line to file config.sys that says- LASTDRIVE=Z (so that DOS will let you use the whole alphabet as substitute drive letters)
emb978@leah.Albany.Edu ( Eric M. Boehm) (01/12/88)
I had this problem (which is why I started delving into the environment). Best solution is to SUBST drives for paths, and put the drives in the path variable. For example, SUBST G: C:\WORDSTAR\MARY\DATA SUBST H: C:\BIN\UTILITIES\NORTON PATH=H:;G: You will probably need to add "LASTDRIVE=Z" to config.sys As you can see, this will save a lot of space. For those who wanted references, according to Van Wolverton in Supercharging MS-DOS, the limit to increase 3.1 environment is /e:62 (992 bytes) and 3.2 is 32767. My own tests with 3.2, 3.1 and 2.21 gives a limit of 123 characters (bytes) in an environment variable. This is because the input line buffer is 127 bytes less 4 characters for "set " (set and space). You can try batch files to increase this but at least Zenith MS-DOS will barf if you go beyond 123 (variable length includes variable name and equal sign). Also according to Van Wolverton, environment will expand if you add from the command line but if you try a batch file it will say "Out of Environment". I used to know the reason for this but can't find it now. Something about batch files using part of memory that environment also tries to use.
steven@uicsgva.UUCP (01/12/88)
In dos > 3.2 (maybe earlier) you can use the /e:xx switch on the 'shell' command in config.sys. Look up 'shell' in your dos manual. The problem with making PATH larger than 127 bytes isn't an environment limitation, its a limitation of the 128 byte command line length of dos. You could write a program to go directly into memory, find the dos environment and change it. Its a little difficult to make sure you don't mess up dos's memory, and it would likely not be very portable, put it is possible.
jrv@siemens.UUCP (James R Vallino) (01/12/88)
In article <558@leah.Albany.Edu> emb978@leah.Albany.Edu ( Eric M. Boehm) writes: >Also according to Van Wolverton, environment will expand if you add from the >command line but if you try a batch file it will say "Out of Environment". I >used to know the reason for this but can't find it now. Something about >batch files using part of memory that environment also tries to use. Information for running the batch file is loaded in the lowest free memory available. This will be right next to the memory block allocated for the master copy of the environment thus blocking any growth. The SET command is an internal command which does not require anything to be loaded in memory. The same situation occurs if you have loaded any TSR programs. They will prevent MS-DOS from being able to expand the environment beyond its initial allocation even from the command line. Jim Vallino Siemens Research and Technology Lab.,Princeton, NJ CSNET: jrv@siemens.siemens-rtl.com UUCP: {ihnp4,philabs,seismo}!princeton!siemens!jrv -- Jim Vallino Siemens Research and Technology Lab.,Princeton, NJ CSNET: jrv@siemens.siemens-rtl.com UUCP: {ihnp4,philabs,seismo}!princeton!siemens!jrv
russ@hpldola.UUCP (01/13/88)
>. >.Also note that no environment variable can occupy more than 127 (128?) bytes >.each! >. >This limit has just bitten me for the PATH variable. Is there any way >to have a PATH which is longer than this? >I am using MS-DOS 3.3. Does anyone have any patches which will allow >a larger PATH variable, or other fixes (short of restructuring my disk) >which will allow searching on the PATH variable? You can use the SUBST command to set up logical drives that equate to a subdirectory, then use the drive name in the path. SUBST D: C:\level1\level2\level3 SUBST E: C:\layer1\layer2\layer3\layer4 PATH=D:\level4A;D:\level4B;E:\layer5 Remember to put a LASTDRIVE=d: in your CONFIG.SYS if you need a drive after E:
bobmon@iuvax.UUCP (Bobmon) (01/15/88)
Somebody sent me some code a year or so ago that allows you to create sequential env. variables, then concatenate them into a single, large PATH variable. It worked for me under limited testing; the author made no promises about robustness or niceness. Anyway, I'll send it to comp.binaries.ibm.pc tonight. (p.s. Thanks, whoever sent it to me; I've forgotten your name, I'm afraid.)
jpd@usl-pc.UUCP (DugalJP) (01/19/88)
In article <39592@ti-csl.CSNET> khill@home.UUCP (Ken Hill - Patents) writes: >... Is there any way >to have a PATH which is longer than this [128 bytes]? Some of the alternate >methods posted here recently are fine, but some software wants to >hunt the PATH looking for various things, and I don't want to store >everything close to the root directory. (Reaching 3 subdirectories each >3 levels down burns up that 128 bytes real fast) Ken, look at the SUBST command. It will let you replace a pathname with a drive name, shortening things a bit! You may have to adjust the LASTDRIVE parm in the config.sys file, though. PS: The inverse of SUBST is JOIN. -- James Dugal, N5KNX USENET: ...!{ut-sally,killer}!usl!jpd Associate Director Internet: jpd@usl.edu Computing Center US Mail: PO Box 42770 Lafayette, LA 70504 University of Southwestern LA. Tel. 318-231-6417 U.S.A.