🚀 go-pugleaf

In a recent article hogstedt@ae.chalmers.se (PER HOGSTEDT) writes:
 
> When running DOS applications from Windows I get too little environment
>space for my application. Windows allocates 224 bytes in standard mode (I
>think).
>How can I tell Windows to allocate more environment for my DOS application?

Other responses to this have suggested a variety of ideas:

> Edit CONFIG.SYS to include a larger environment space (/e:nnn)

Won't help.  Windows calls up a fresh copy of COMMAND.COM to start a
DOS window and does not bother to propagate the /e:nnn used at boot 
time.  You get the default allocation of environment space only, or
the space required to hold the current environment, whichever is larger.

> Create a placeholder in the environment before entering Windows (e.g.,
> SET DUMMY1=1111111111...

Works, but it's a hassle.

> Make the default .PIF file specify a larger environment

Works for the DOS window, but you have to play this game for each non-
Windows app you use.

====

FWIW, I finessed the problem some time ago (pre-WIN3) by patching COMMAND.COM
to change the default environment space.  In addition to fixing the Windows
problem it simultaneously fixes the shortage of environment space in other
(non-WIN3) situations where a program permits you to shell back to the DOS
prompt.

(An aside to Microsoft: Why do I have to play this game, and why can't 
COMMAND.COM be set up to use the CONFIG.SYS value every time it's loaded?
Any chance this might appear in DOS5?)

As usual, your milage may vary, and if you use this patch you're on your own.
It works for me with no problems, but for some reason some people use PC's
with imperfect (meaning not identical to my) configuration.

Here's the patch for PC-DOS 3.3:

=-=-=-=-=-=-=-=-=-=  begin included file  =-=-=-=-=-=-=-=-=-=

This patch changes the default environment size in COMMAND.COM for DOS 3.3
from its IBM-provided value of 160 bytes.

The COMMAND command (both in the SHELL statement in CONFIG.SYS and in
the command which establishes a secondary command processor) accepts
the /E:xxxx parameter, but when a secondary processor is started it
does not honor the size specification of its parent.  This can cause
significant problems if a user invokes functions which require more
environment space than is available while in a secondary command processor
environment.

The patch will work for PC-DOS 3.3 only.  The concept is probably applicable
for other DOS variants and other releases, but the verify code (and possibly
the patch data) will differ.

The value to be changed represents a (two-byte) word containing the size of
the default environment space in paragraphs (16-byte blocks).  Since the
80*86 architecture inverts the sequence, the low-order byte appears first.
The default value is 160 bytes (hex 00A0), so the original data is hex 0A 00;
to patch the file to default to 512 bytes (hex 0200) the data should be
changed to hex 20 00.

Note that the low-order zero is not present.  To summarize:

   For this much space...insert this value...inverted

160 bytes (10 paragraphs)      000A           0A 00
256 bytes (16 paragraphs)      0010           10 00
512 bytes (32 paragraphs)      0020           20 00

The installation script to set a 512-byte default if typed from the console.
Executing this from a file would not show exactly the same material.

C:\> debug command.com
- d eb4 eb9                     (show the data where we will patch)
xxxx:0EB0              C7 06 60 16 - 0A 00                       ......

- e eb8 20                      (make the actual patch)

- w                             (write the file back to disk)
Writing 62DB bytes
- q                             (exit DEBUG)
C:\>

=-=-=-=-=-=-=-=-=-=  end included file =-=-=-=-=-=-=-=-=-=

Joe Morris