setting DOS environment size

[Keith]

Currently have win2k with SP4 installed.

I am trying to run an old DOS program and have set up a
pif file to run it however I do not appear to be able to
control the amount of environment space available.

Let me explain. If I try and run the program with my own
autoexec and config files then the program does not work
unless I remove some of the variables, i.e set lib= and
set include=. These both have the effect of allowing extra
space for some extra settings. My config file only adds
ansi.sys to the standard file and autoexec has 5 extra
assignments added.

I have tried to force the amount of environment space in
the pif file without joy and have also changed the config
file to include a shell line to increase the environment
space, again without success.

My tests tend to suggest that it is not possible to change
the size of the environment from either the pif file or
config file.

Has anyone else seen this or can someone please advise as
to how to check this for sure and fix it!

Thanks,
Keith

 

[Matthias Tacke]

Currently have win2k with SP4 installed.

I am trying to run an old DOS program and have set up a
pif file to run it however I do not appear to be able to
control the amount of environment space available.

Let me explain. If I try and run the program with my own
autoexec and config files then the program does not work
unless I remove some of the variables, i.e set lib= and
set include=. These both have the effect of allowing extra
space for some extra settings. My config file only adds
ansi.sys to the standard file and autoexec has 5 extra
assignments added.

I have tried to force the amount of environment space in
the pif file without joy and have also changed the config
file to include a shell line to increase the environment
space, again without success.

My tests tend to suggest that it is not possible to change
the size of the environment from either the pif file or
config file.

Has anyone else seen this or can someone please advise as
to how to check this for sure and fix it!

Hello Keith,
I'm in doubt if a greater possible environment than in a former OS will
cause problems with an app. Interfering with var's may cause problems.
What app to you use, what problems arise?
If you are able to run the app with a different environment, why not
use the pif to start a batch which in turn prepares the environment that
way?
You may also use the command shell with /e:nnnnn instead of the default
cmd.exe.
for details on command or cmd.exe issue in a shell windows:
command /?
cmd /?

hth

 

[Guest]

-----Original Message-----


Hello Keith,
I'm in doubt if a greater possible environment than in a former OS will
cause problems with an app. Interfering with var's may cause problems.
What app to you use, what problems arise?
If you are able to run the app with a different environment, why not
use the pif to start a batch which in turn prepares the environment that
way?
You may also use the command shell with /e:nnnnn instead of the default
cmd.exe.
for details on command or cmd.exe issue in a shell windows:
command /?
cmd /?

hth
--
Greetings
Matthias________________________________________
For help on nt commands enter in a cmd window:
W2K>HH windows.chm::ntcmds.htm XP>HH ntcmds.chm
.

I am trying to use a pif file, this was always the way the
app worked before on a win2k system (was FAT32 and not the
as now NTFS). The environment variables that I am removing
are done in my called autoexec.nt file and remove the
paths for MS Visual C++, which are restored ok when the
compiler is run. The settings in the pif file make no
difference. I have tried the shell=%systemroot%\system32
\command.com /e:4096 line and this does not sort it, I
have also tried many different sizes.
The application is an old PCB package 'Cadstar'. When the
pif is executed then the window will open and then close
without anything else happening. When I make space then it
operates correctly. If I turn echo on and am quick enough
then I can see the fact that when I try and set some of
the variables it reports that windows has run out of
environment space.
The pif did initially work when windows was first loaded
and the package tested (a couple of days ago). After that
the rest of the apps were installed (including MS Visual
C++) and then I found that the pif would no longer run the
package. This was found after a re-install (desktop
problems), at this time the partition was reformated as
NTFS from fat32.
As I originally stated it almost looks as if the
environment size can not be set and just stays at its
initial size (or a fixed number which ever is the larger)
regardless of the settings of the shell command or in the
pif file.
Any ideas?

 

[Phil Robyn]

former OS will


cause problems.


environment, why not


environment that


of the default


I am trying to use a pif file, this was always the way the
app worked before on a win2k system (was FAT32 and not the
as now NTFS). The environment variables that I am removing
are done in my called autoexec.nt file and remove the
paths for MS Visual C++, which are restored ok when the
compiler is run. The settings in the pif file make no
difference. I have tried the shell=%systemroot%\system32
\command.com /e:4096 line and this does not sort it, I
have also tried many different sizes.
The application is an old PCB package 'Cadstar'. When the
pif is executed then the window will open and then close
without anything else happening. When I make space then it
operates correctly. If I turn echo on and am quick enough
then I can see the fact that when I try and set some of
the variables it reports that windows has run out of
environment space.
The pif did initially work when windows was first loaded
and the package tested (a couple of days ago). After that
the rest of the apps were installed (including MS Visual
C++) and then I found that the pif would no longer run the
package. This was found after a re-install (desktop
problems), at this time the partition was reformated as
NTFS from fat32.
As I originally stated it almost looks as if the
environment size can not be set and just stays at its
initial size (or a fixed number which ever is the larger)
regardless of the settings of the shell command or in the
pif file.
Any ideas?

Give TameDOS a try - http://www.tamedos.com

 

[Mark V]

I am trying to use a pif file, this was always the way the
app worked before on a win2k system (was FAT32 and not the
as now NTFS). The environment variables that I am removing
are done in my called autoexec.nt file and remove the
paths for MS Visual C++, which are restored ok when the
compiler is run. The settings in the pif file make no
difference. I have tried the shell=%systemroot%\system32
\command.com /e:4096 line and this does not sort it, I
have also tried many different sizes.
The application is an old PCB package 'Cadstar'. When the
pif is executed then the window will open and then close
without anything else happening. When I make space then it
operates correctly. If I turn echo on and am quick enough
then I can see the fact that when I try and set some of
the variables it reports that windows has run out of
environment space.
The pif did initially work when windows was first loaded
and the package tested (a couple of days ago). After that
the rest of the apps were installed (including MS Visual
C++) and then I found that the pif would no longer run the
package. This was found after a re-install (desktop
problems), at this time the partition was reformated as
NTFS from fat32.
As I originally stated it almost looks as if the
environment size can not be set and just stays at its
initial size (or a fixed number which ever is the larger)
regardless of the settings of the shell command or in the
pif file.
Any ideas?

Only ideas...
Broke after installing... Did the PATH suddenly become much longer?
Have you started over creating a new PIF from scratch, or only
modified the original?

 

[Guest]

-----Original Message-----


Only ideas...
Broke after installing... Did the PATH suddenly become much longer?
Have you started over creating a new PIF from scratch, or only
modified the original?

.

After running the application succesfully I went out to
dos (inbuilt command of app) and checked the environment.
I found that the path had become shortened. This does ring
bells with me that the max path length is 128 chars?
If this limit is impossed it still does not make much
sense as the original installation also had the same (and
more) apps installed. The path length is predominately
made up of the entries for MS visual C++.

 

[Keith]

Just wanted to say thanks to everyone for their
suggestions, I have now got a working solution.

My findings:
I discovered that MS Visual studio adds its various
environment variables to the users environment, some of
which will take the line length well past the 128 chars
allowed for dos, even allowing for dos filename and path
shortening. MS VS does not need these settings (as far as
I can tell) so I have removed them from the users settings
in the environment section for the local user. I beleive
these variables are only used if the user wants to run the
compiler/linker at dos and then even if you do they
already provide a batch file to add these variables anyway
which ensures the lengths should not exceed 128 chars.

This does however flag up illogical behaviour if you try
and run a dos app and modify its environment through a
autoexec.nt file IF any line lengths exceed the 128 char
line length. This is something that MS should investigate
and at least acknowledge, I would report it but can not
see how to at this stage, can anyone point me in the
correct direction?

Thanks again and I hope the above will be useful to you.
Keith