[comp.windows.ms.programmer] Environment Space

fjb@druwa.ATT.COM (Jeff Bogart) (05/01/91)

When I run a non-windows application from windows, I seem to create a "default"
environment that is too small to add new environment variables or to extend my
PATH.  Is there some way of telling windows what size to reserve for
environment variables?

I can't seem to find anything mentioned about this topic in the Windows
documentation.

                               ~               *******    
    Jeff Bogart         ~                    ***********    
    (303) 538-4268     __      _   _!__     *************   
    att!druwa!fjb _   /  \_  _/ \  |::| ___ *************     ~
    Room 30L-69 _/ \_/^    \/   ^\/|::|\|:|  **********/^\_
    FAX 4692 /\/  ^ /  ^    / ^ ___|::|_|:|_/\_******/  ^  \
            /  \  _/ ^ ^   /    |::|--|:|---|  \__/  ^     ^\___
          _/_^  \/ AT&T, Denver |::|  |:|  :|    /              \_
         /   \^ /    /\ /       |::|--|:|:--|  /           ^      \
------------------------------------------------------------------------------
--
                               ~               *******    
    Jeff Bogart         ~                    ***********    
    (303) 538-4268     __      _   _!__     *************   
    att!druwa!fjb _   /  \_  _/ \  |::| ___ *************     ~

rich@wiley.uucp (Rich Messenger) (05/03/91)

In article <8361@drutx.ATT.COM> fjb@druwa.ATT.COM (Jeff Bogart) writes:
>When I run a non-windows application from windows, I seem to create a "default"
>environment that is too small to add new environment variables or to extend my
>PATH.  Is there some way of telling windows what size to reserve for
>environment variables?
>
>I can't seem to find anything mentioned about this topic in the Windows
>documentation.

How about a simple hack: before you invoke windows, set a scratch
environment variable (making sure your command.com has a big enough
environment space):

	SET scratch=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Then, instead of invoking the non-windows application directly, call a
batch file which first unsets the environment variable.  This will
free up that space in the environment.

	SET scratch=
	...rest of batch can now add to path, etc...

I know: UGLY.  But it probably works.
     _ __
    ' )  )      /                      ... Rich Messenger
     /--' o _. /_                          rich@wilbur.coyote.trw.com
    /  \_(_(__/ /_                         {uunet,cit-vax,trwrb}!wiley!rich

hd7x@vax5.cit.cornell.edu (Sanjay Aiyagari) (05/06/91)

In article <28210533.D0@wilbur.coyote.trw.com>,
rich@wiley.uucp (Rich Messenger) writes: 
> In article <8361@drutx.ATT.COM> fjb@druwa.ATT.COM (Jeff Bogart) writes:
>>When I run a non-windows application from windows, I seem to create a 
>>"default" environment that is too small to add new environment variables or 
>>to extend my PATH.  Is there some way of telling windows what size to 
>>reserve for environment variables?
> 
> How about a simple hack: before you invoke windows, set a scratch
> environment variable (making sure your command.com has a big enough
> environment space):
> 
> 	SET scratch=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> 
> Then, instead of invoking the non-windows application directly, call a
> batch file which first unsets the environment variable.  This will
> free up that space in the environment.
> 
> 	SET scratch=

Another way of doing this is, when you create the .PIF file for the
application, specify the program name as "command.com" (with the appropriate
path).  Then, in the parameters section, put "/e:xxx /c app.bat" where app.bat
is the batch file that sets the path and runs the application, and xxx is the
amount of environment space you need.

Setting the /e parameter in the shell= statement in CONFIG.SYS won't work
because Windows takes away unused environment space.

Sanjay Aiyagari (hd7x@vax5.cit.cornell.edu)