Path: utzoo!attcan!uunet!zaphod.mps.ohio-state.edu!sdd.hp.com!ucsd!ucbvax!agate!linus!linus!mwunix.mitre.org!jcmorris From: jcmorris@mwunix.mitre.org (Joe Morris) Newsgroups: comp.windows.ms Subject: Re: Environment space for DOS appl. under Windows Message-ID: <124411@linus.mitre.org> Date: 25 Oct 90 13:19:29 GMT References: <433.2721eb3c@ae.chalmers.se> Sender: usenet@linus.mitre.org Reply-To: jcmorris@mwunix.mitre.org (Joe Morris) Organization: The Mitre Corporation Lines: 93 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