lmg@sfmin.UUCP (L.M.Geary) (07/24/87)
We've all seen the patches for increasing the DOS environment size, and we've read about the /E:xx switch for CONFIG.SYS. However, neither of these techniques work when COMMAND.COM is invoked as a secondary command processor. At least, this is what I find with DOS 3.1. For secondary COMMAND.COMs, the environment is rounded up to the nearest 16 byte boundary after the last environment string, or to 160 bytes, whichever is greater. For example, suppose I have COMMAND.COM patched to give a default environment size of 912 bytes. I happen to have 230 bytes of strings in the environment when I invoke a second COMMAND.COM. The secondary COMMAND.COM will have an environment size of 240 bytes, giving me all of 10 bytes before I get the "Out of environment space" message. Almost any BAT file that tries to set an environment variable will fail. All this becomes important if one tries to use the MKS shell, or their "login" program, because any invocation of COMMAND.COM will be as a secondary command processor. The result is that AUTOEXEC.BAT fails when run from "login", and most of my BAT files fail when run from "sh". I suppose it's possible to trick the system by filling the primary environment with dummy strings and deleting them as the first task in any BAT file, but that's an awfully cruddy way to operate. So my question (at last!): Is there a way to give a secondary COMMAND.COM a healthy environment size, either via a patch or option switch? Larry Geary ihnp4!attunix!lmg