Xref: utzoo comp.os.msdos.programmer:360 comp.sys.ibm.pc.programmer:2488 Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!mit-eddie!snorkelwacker!ai-lab!mbeck From: mbeck@wheaties.ai.mit.edu (Mark Becker) Newsgroups: comp.os.msdos.programmer,comp.sys.ibm.pc.programmer Subject: Need help with Turbo-C 2.0 spawnl() function. Keywords: Turbo-C 2.0 spawnl Message-ID: <9684@rice-chex.ai.mit.edu> Date: 3 Aug 90 01:23:25 GMT Organization: MIT AI Lab, Cambridge, MA Lines: 46 Hello * Need a little help with the care and feeding of Borland's Turbo-C 2.0 spawnl() function. I think I'm doing something incorrect but after Reading The Fine Manual I can't seem to spot it. The following standalone program works fine: #include #include #include void fragment(void) { char *p; if ((p = getenv("COMSPEC")) == NULL) return; if (spawnl(P_WAIT, p, p, NULL) == -1) perror(p); } void main(void) { fragment();} However, when fragment() is integrated into a somewhat larger program (small model) I get Stack Overflow messages, followed by an eventual stack 'roll-over' failure with a message out of the BIOS in this 386-clone. This requires the Small Red Button (reset) to regain control. Not quite believing the situation, I re-compiled using compact model. This time I get a message out of COMMAND.COM about how there isn't enough memory. At least it doesn't crash the machine. The larger program in small model is something like 30K of .EXE with easily 400K of free memory to run in and isn't memory intensive; a fancy device controller with a "Shell" option in the software. This whole thing is running on a 'vanilla' DOS 3.21 system with CHKDSK reporting 606,480 bytes of available memory. COMMAND.COM is 'only' 23,612 bytes. Where is all that memory going? Your help appreciated. Regards, Mark +-----------------------------------------------+-----------------------+ | Mark Becker | .signature under | | Internet: mbeck@ai.mit.edu | construction | +-----------------------------------------------+-----------------------+