markz@microsoft.UUCP (Mark Zbikowski) (07/02/85)
Due to the underwhelming response to my last inquiry, I am rephrasing the question (Microsoft employees, are you listening?). MS-DOS provides basic memory management capability via DOS function 48H et al. I have found that COMMAND.COM when loading an .EXE program does NOT use this capability to tell DOS to leave the stack (segment) alone as it does for the code and data areas. Au contraire. DOS relies on what the EXE file has in it. It does NO other interpretation. If the EXE file says "put the stack here" DOS will do exactly that. If someone diddles with the EXE header, DOS will believe him(her). The linker produces correct output; is there something in your build script that adjusts things in the header? If so, you should make sure that they produce a consistent header. Since the stack size AND location is available to the command processor from the .EXE program header, unlike the situation loading .COM files, I would expect that COMMAND.COM would deal with this a little better. I believe that you are confusing things. COMMAND.COM does no loading of EXE files; the EXEC system call performs that job. Under 2.*, due to space crunch, the EXEC system call was placed in the transient part of COMMAND so that it could be discarded when applications needed that space. Under 3.*, the code was correctly placed into the kernel.