dewa@ur-tut.UUCP (Rajiv Dewan) (11/12/85)
*** REPLACE THIS LINE WITH YOUR MESSAGE ***
I want to use a fancy string for PROMPT, but I keep running into
OUT OF ENVIRONMENT SPACE
problem. A while back, I had seen a message regarding increasing
the environment space. Someone, please help me increase the
environment space!! I have looked throught the DOS Reference and
DOS Technical Ref. Manuals but have not found an easy way to do it.
Any help appreciated.
Rajiv Dewan
ur-tut!dewabroehl@watdcsu.UUCP (Bernie Roehl) (11/13/85)
In article <215@ur-tut.UUCP> dewa@ur-tut.UUCP (Rajiv Dewan) writes: >*** REPLACE THIS LINE WITH YOUR MESSAGE *** >Someone, please help me increase the >environment space!! I have looked throught the DOS Reference and >DOS Technical Ref. Manuals but have not found an easy way to do it. >Any help appreciated. If you look in the DOS 3.00 manual under the SET command, it says "If you have *not* loaded a program that remains resident... DOS expands the environment string area to hold additional strings." Otherwise it only has the default 127 bytes. There are two approaches: either do a SET in your autoexec *before* any resident utilities (SideKick, keyboard typeahead expanders, ramdisks, etc) are loaded. This SET (or series of SETs) should increase the space to some high limit. You can always get rid of these placeholders variables after you've loaded other stuff above them. The other approach is to patch COMMAND.COM; there was a patch posted to the net a while back (sorry, I don't have it around any more) to do is, but it tends to be highly version-dependent.
2212msr@whuts.UUCP (ROBIN) (11/14/85)
This patch increases the environment size from 128 bytes to (H)0080 (128
decimal) paragraphs of 16 bytes each.
debug a:\command.com
-u cs:0f2b ;DOS VERSION LOCATION
;2.X CS:ECE
;2.11(ATT&T PC6300) CS:DF2
;3.0 CS:0F2B
;contents should be MOV BX,000A
-a0f2b ;address to asemble new code into
XXXX:0f2b mov bx,0080 ;system prompts you with XXX:0f2b
- ;enter carriage return
-w ;write change
YYYY ; message telling how many bytes were written
-q ;quit
For DOS 3.1, an undocumented feature of the SHELL command is used
in the CONFIG.SYS file:
shell=drive/pathname_of_command_processor drive/path_to_command_process
/p/e:number_of_16_byte_paragraphs
where: 10<paragraphs<63
Example, giving 480 byte environment space:
shell=c:\command.com c:\/p/e:30
I'd like the address to patch in DOS 3.1, since the SHELL feature is undoc-
umented, and hence unsupported.
Max S. Robin
AT&T Bell Laboratories
Rm. 3E-318A
Whippany, NJ 07981
201-386-6865
email:whuxg!2212msr2212msr@whuts.UUCP (ROBIN) (11/14/85)
> In article <215@ur-tut.UUCP> dewa@ur-tut.UUCP (Rajiv Dewan) writes: > If you look in the DOS 3.00 manual under the SET command, it says > "If you have *not* loaded a program that remains resident... DOS expands > the environment string area to hold additional strings." Otherwise it > only has the default 127 bytes. > > There are two approaches: either do a SET in your autoexec *before* any > resident utilities (SideKick, keyboard typeahead expanders, ramdisks, etc) > are loaded. This SET (or series of SETs) should increase the space to some > high limit. You can always get rid of these placeholders variables after > you've loaded other stuff above them. > > The other approach is to patch COMMAND.COM; there was a patch posted to > the net a while back (sorry, I don't have it around any more) to do is, > but it tends to be highly version-dependent. > I've tried to use the SET command in DOS 3.0, from my autoexec file and it does not appear to increase environment space. Could you post an example of your SET command that does work in DOS 3.0 please. This is part of the reason I've been using the memory patch in command.com (see sep. posting). Max S. Robin email:whuxg!2212msr AT&T Bell Laboratories 201-386-6865 *** REPLACE THIS LINE WITH YOUR MESSAGE ***
2212msr@whuts.UUCP (ROBIN) (11/15/85)
For those of you who have pointed out that the undocumented SHELL /e option is easier, etc. to use than patching command.com, let me point out that command.com allows 2K of environment space, where the /e option appears to limit you to 62 paragraphs of 16 bytes, or 992 bytes. Max S. Robin email:whuxg!2212msr AT&T Bell Laboratories 201-386-6865
ericf@uwvax.UUCP (Eric Feigenson) (11/15/85)
> If you look in the DOS 3.00 manual under the SET command, it says > "If you have *not* loaded a program that remains resident... DOS expands > the environment string area to hold additional strings." Otherwise it > only has the default 127 bytes. > > There are two approaches: either do a SET in your autoexec *before* any > resident utilities (SideKick, keyboard typeahead expanders, ramdisks, etc) > are loaded. This SET (or series of SETs) should increase the space to some > high limit. You can always get rid of these placeholders variables after > you've loaded other stuff above them. > > The other approach is to patch COMMAND.COM; there was a patch posted to > the net a while back (sorry, I don't have it around any more) to do is, > but it tends to be highly version-dependent. > > I beg to differ. I have had similar problems with DOS 2.1, 3.0 and 3.1. In my autoexec.bat file I set ALL my environment variables, path and prompt, *before* I do anything else. To make things simpler, I even eliminated my CONFIG.SYS file, so things like buffers got their default value. I, too, suffered from the "Out of environment space" message. The wierd thing is that once I got my prompt I was able to set environment variables until the cows came home, with *no* errors reported. My theory is that the code that deals with environment *thinks* something is resident (other than command.com), but isn't. Of course this happens only when executing the autoexec.bat, not interactively. Oh, and did I mention that if the last "set" in my autoexec doesn't end with a CRLF, it gets put in the environment OK, and when it *does* end in a CRLF I get the error message (Out of environment space), and it gets truncated? Sigh... Does *anyone* know what's going on? -- -Eric Feigenson Usenet: {seismo, allegra, ihnp4}!uwvax!ericf Arpanet: ericf@wisc-rsch.arpa
jabusch@uiucdcsb.CS.UIUC.EDU (11/16/85)
Is it possible that loading device drivers (ansi.sys, vdisk.sys, etc.)
in your config.sys file could be keeping your environment space from
being expanded, even though you aren't using any programs which stay
resident? I would think that this could be a real problem, were it true,
if the exit-and-stay-resident definition included drivers which can
only be loaded at boot time.
John W. Jabusch
U.S. Mail:
Department of Computer Science
University of Illinois at Urbana-Champaign
Room 230 Digital Computer Laboratory
1304 West Springfield Avenue
Urbana, IL 61801
CSNET: jabusch%uiuc@csnet-relay.ARPA
UUCP: {ihnp4,convex,pur-ee}!uiucdcs!jabusch
USENET: ...!{pur-ee,ihnp4}!uiucdcs!jabusch
ARPA: jabusch@uiuc.arpabroehl@watdcsu.UUCP (Bernie Roehl) (11/18/85)
>> There are two approaches: either do a SET in your autoexec *before* any >> resident utilities (SideKick, keyboard typeahead expanders, ramdisks, etc) >> are loaded. This SET (or series of SETs) should increase the space to some >> high limit. You can always get rid of these placeholders variables after >> you've loaded other stuff above them. >> >I beg to differ. I have had similar problems with DOS 2.1, 3.0 and 3.1. >In my autoexec.bat file I set ALL my environment variables, path and prompt, >*before* I do anything else... I, too, suffered from the "Out of environment >space" message... >once I got my prompt I was able to set environment variables until the >cows came home, with *no* errors reported. My theory is that the code that >deals with environment *thinks* something is resident (other than command.com), >but isn't. Of course this happens only when executing the autoexec.bat, not >interactively.. >Sigh... Does *anyone* know what's going on? I *think* I do. It seems that DOS will increase the environment space beyond 128 bytes *only* when there is nothing loaded above the resident portion of command.com; when a batch file is executing, the batch file gets loaded right after the end of command.com, so the increase doesn't happen. Thus, to increase the environment space, you have to actually type the SET commands at the keyboard (yuck!). Maybe the patch is the way to go after all...
rsellens@watdcsu.UUCP (Rick Sellens - Mech. Eng.) (11/19/85)
In article <399@uwvax.UUCP> ericf@uwvax.UUCP (Eric Feigenson) writes: > ......... I, too, >suffered from the "Out of environment space" message. The wierd thing is >that once I got my prompt I was able to set environment variables until the >cows came home, with *no* errors reported. My theory is that the code that >deals with environment *thinks* something is resident (other than command.com), > > -Eric Feigenson I read somewhere that the memory map has the environment immediately above DOS, with anything running under DOS immediately above that. It was pointed out that this even includes batch files. Because of this DOS cannot grow the environment while running a batch file. Ugly! Rick Sellens UUCP: watmath!watdcsu!rsellens CSNET: rsellens%watdcsu@waterloo.csnet ARPA: rsellens%watdcsu%waterloo.csnet@csnet-relay.arpa Physical: 372A Churchill Court, Waterloo, Ontario, Canada N2L 6B4
jpn@teddy.UUCP (11/19/85)
>Is it possible that loading device drivers (ansi.sys, vdisk.sys, etc.) >in your config.sys file could be keeping your environment space from >being expanded, even though you aren't using any programs which stay >resident Actually, these are loaded BEFORE command.com, and so, are BELOW command.com in memory. The only reason command.com cannot expand the memory space, is because there is something loaded into memory directly above it. (The PC can't re-shuffle tasks in memory). The REAL problem, is that the environment cannot be expanded when executing a batch script INCLUDING config.sys. This is a real lose. Presumably this is because the script file is loaded into memory above command.com, but you would think that microsoft would have implemented batch files so that the batch file could be moved around in memory when command.com decides it needs more environment space. Of course it seems that batch files were an afterthought. Fairly crude.
jpn@teddy.UUCP (11/19/85)
In article <1685@teddy.UUCP> jpn@teddy.UUCP (John P. Nelson) writes: >The REAL problem, is that the environment cannot be expanded when executing >a batch script INCLUDING config.sys. Of course, I meant autoexec.bat, not config.sys
jph@whuxlm.UUCP (Holtman Jim) (11/20/85)
> In article <399@uwvax.UUCP> ericf@uwvax.UUCP (Eric Feigenson) writes: > > ......... I, too, > >suffered from the "Out of environment space" message. The wierd thing is > >that once I got my prompt I was able to set environment variables until the > >cows came home, with *no* errors reported. My theory is that the code that > >deals with environment *thinks* something is resident (other than command.com), > > > > -Eric Feigenson > > I read somewhere that the memory map has the environment immediately above > DOS, with anything running under DOS immediately above that. It was pointed > out that this even includes batch files. Because of this DOS cannot grow > the environment while running a batch file. Ugly! > > > Rick Sellens > UUCP: watmath!watdcsu!rsellens > CSNET: rsellens%watdcsu@waterloo.csnet > ARPA: rsellens%watdcsu%waterloo.csnet@csnet-relay.arpa > Physical: 372A Churchill Court, Waterloo, Ontario, Canada N2L 6B4 The way to increase the environment space is to patch COMMAND.COM to allocate more space. In the DOS 2.0 that I have on my COMPAQ, the following code sequence is at F66; MOV BX,0A MOV AH,48 INT 21 This allocates 10 paragraphs (160 bytes) to the environment space, which is too small for most of the stuff I do. WHat I did was change the instruction to: MOV BX,40 which gives me 64x16 (1024 bytes) of envrionment. For other versions of COMMAND.COM, search for a similar code sequence and patch a 'backup' copy of COMMAND.COM and try it.
jabusch@uiucdcsb.CS.UIUC.EDU (11/21/85)
There is a way to specify for a program to load as high as
possible in memory using the DOS linker at link time. Perhaps there
is a way to write a program that will add things to the environment
from a data file, by having it load itself into high memory, leaving
room below it for the environment space to be expanded.
On the other hand, maybe this is a stupid idea. I'll have to
play with it a little.
John W. Jabusch
U.S. Mail:
Department of Computer Science
University of Illinois at Urbana-Champaign
Room 230 Digital Computer Laboratory
1304 West Springfield Avenue
Urbana, IL 61801
CSNET: jabusch%uiuc@csnet-relay.ARPA
UUCP: {ihnp4,convex,pur-ee}!uiucdcs!jabusch
USENET: ...!{pur-ee,ihnp4}!uiucdcs!jabusch
ARPA: jabusch@uiuc.arpa