Wyx dictionary

.TOPIC.......: Problem - /V Does Not Work Under Win3X Or Win9X
.DISCUSSION..:

"OUT OF ENVIRONMENT SPACE"

When you shell out to a DOS box under Windows, the size of the DOS environment is normally limited to the amount actually in use by DOS at the time when you first started Windows (rounded up to multiples of 16). This does not give a subprocess any free space that it can use for its own purposes, so when it tries to set an environment variable, you get the "out of environment space" message. This is a problem that may affect any process that runs in a "DOS box" under Windows, and sets an environment variable.

The trick is to tell Windows that when it starts the "DOS box" (COMMAND.COM), it should allocate a certain minimum amount of memory for the environment, regardless of the amount that is currently being used.

How to do it under NT, Windows2000, XP

/V will not work under NT, Windows2000, or XP. see TOPIC Problem - /V Does Not Work Under NT, Windows2000, XP

How to do it under Win95

Select the shortcut icon that you use to start MS-DOS. Rhex ight-click on it. When the pop-up menu appears, click on PROPERTIES. When the properties for the shortcut come up, click on the MEMORY tab. When the tab sheet is displayed, set a value for INTITIAL ENVIRONMENT. I usually set it to 2048 (that is, 2K) bytes. This will ensure that when DOS (COMMAND.COM) is started, 2K bytes are allocated to the environment.

Windows 3.1

The trick to giving yourself a decent amount of environment space in a Windows DOS box, is to edit SYSTEM.INI and put the following line in the [NonWindowsApp] section:

[NonWindowsApp]

CommandEnvSize=1024

This tip is from Brian Livingston's "Windows 3.1 Secrets", p. 225. According to Livingston, "This command allocates 1,024 bytes of conventional memory to the environment space of each DOS session you start. (You can choose any value you want, but it should probably be a multiple of 16 bytes...)"

It's a good idea to be generous here, because the default prompt for a Windows DOS box (the one with the highlighted bar across the top of the screen) consumes a lot more environment space than the simple "$p$g" of the conventional DOS prompt.

DOS or Windows 3.0 and earlier

An alternative technique, if you're running Windows 3.0 or earlier, is always to start Windows from a batch file that contains the following line, executed BEFORE you start Windows:

SET DUMMY=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

This will reserve a chunk of environment space that will be copied into the environment in the Windows DOS box. Then, as one of the first statements in any batch file that you run under Windows, put

SET DUMMY=

This will free up the environment space used by all those "X"s.

For a good treatment of running DOS apps under Windows, including a discussion of the environment, I recommend Brian Livingston's WINDOWS 3.1 SECRETS, chapter 7.

Using 4Dos, NDOS, And UMB

Aran Spence has reported circumstances in which Fdate /V will not set a variable in the master environment. This report leads me to believe that Fdate /V may also fail to work with MS-DOS if you put the command processor or the environment in Upper Memory.

There are options with 4DOS and NDOS to load the environment and part of the command processor into upper memory blocks. When one of these options is used, Fdate /V can't find the environment and produces the message:

   ERROR
   @echo ERROR: Master environment not found
   @pause

If you have a 4DOS.INI file, it has to contain these lines for Fdate /V to work:

   UMBEnvironment = No
   UMBLoad = No

If you have NDOS, the SHELL statement in CONFIG.SYS cannot contain any reference to UMB loading via /U (which puts NDOS.COM in UMB), nor can it contain a statement of the form:

                /E:xxxU

(which puts xxx bytes of the environment in UMB via the "U" parameter).

Also, NSTART.BTM or 4START.BTM cannot contain

         SET NDSHELL=/e+xxxU /U

in which both U's represent UMB loading of the command processor and the environment during secondary shells.