west@turing.toronto.edu (Tom West) (09/08/90)
Does anyone know what the behaviour of the EXEC MS-DOS function is when there is not enough memory to load COMMAND.COM. Specifically, I have a line that is: retcode = spawnve(P_WAIT, "C:\COMMAND.COM", path, environ); where path is defined char *path[2], path[0] is a pointer to C:\COMMAND.COM and path[1] is a null pointer. The problem that I encounter is when there is very little free memory available, the call locks up. Using Codeview, I determined that in fact, it's the MS-DOS EXEC function that is locking up the system with an illegal instruction. I thought that MS-DOS EXEC was supposed to return a not enough memory return code in this case. Anybody know what DOS really does? MS tech support could only tell me that if I had run it on a bunch of different machines and gotten the same result (I had), it was definitely behaviour of MS-DOS. The tech did not know if it was documented anywhere. Tom West west@turing.utoronto.ca
mju@mudos.ann-arbor.mi.us (Marc Unangst) (09/09/90)
west@turing.toronto.edu (Tom West) writes: > Does anyone know what the behaviour of the EXEC MS-DOS function is when > there is not enough memory to load COMMAND.COM. > > Specifically, I have a line that is: > > retcode = spawnve(P_WAIT, "C:\COMMAND.COM", path, environ); [computer locks up when there isn't enough mem to load COMMAND.COM] This isn't going to help you much, but I've encountered this in Zenith's MS-DOS v3.21 also. Your best bet might be to check to see if there's at least 50K left, and refuse to spawn the command processor if there isn't. Also, PLEASE don't hardcode "C:\COMMAND.COM" into your program. Not only does it prevent people who don't have a hard disk from using your program (if you think they're rare, what about people with diskless workstations or computers with a floppy only, who run stuff off the network?), but it prevents people from using an alternate command processor, such as 4DOS, with your program. I'd suggest that you grab COMSPEC from the environment and try to load that, and only try to explicitly spawn COMMAND.COM if COMSPEC doesn't exist. -- Marc Unangst | mju@mudos.ann-arbor.mi.us | Angular momentum makes the world go 'round. ...!umich!leebai!mudos!mju |
ts@uwasa.fi (Timo Salmi LASK) (09/09/90)
In article <eJB8o4w163w@mudos.ann-arbor.mi.us> mju@mudos.ann-arbor.mi.us (Marc Unangst) writes: >west@turing.toronto.edu (Tom West) writes: >> Does anyone know what the behaviour of the EXEC MS-DOS function is when >> there is not enough memory to load COMMAND.COM. >> >> Specifically, I have a line that is: >> >> retcode = spawnve(P_WAIT, "C:\COMMAND.COM", path, environ); >[computer locks up when there isn't enough mem to load COMMAND.COM] > >This isn't going to help you much, but I've encountered this in >Zenith's MS-DOS v3.21 also. Your best bet might be to check to see if >there's at least 50K left, and refuse to spawn the command processor >if there isn't. This is somewhat of a sideline since I use Turbo Pascak instead of C. If you try to execute a shell of a single command in TP, you can test for the result of the operation and take appropriate action. The example demonstrates executing a single command. SwapVectors; Exec (GetEnv(comspec), '/c ' + 'your command'); SwapVectors; If DosError <>0 then whatever; ................................................................... Prof. Timo Salmi (Moderating at anon. ftp site 128.214.12.3) School of Business Studies, University of Vaasa, SF-65101, Finland Internet: ts@chyde.uwasa.fi Funet: gado::salmi Bitnet: salmi@finfun
ho@hoss.unl.edu (Tiny Bubbles...) (09/10/90)
In <eJB8o4w163w@mudos.ann-arbor.mi.us> mju@mudos.ann-arbor.mi.us (Marc Unangst) writes: >west@turing.toronto.edu (Tom West) writes: >> Specifically, I have a line that is: >> >> retcode = spawnve(P_WAIT, "C:\COMMAND.COM", path, environ); >[computer locks up when there isn't enough mem to load COMMAND.COM] >This isn't going to help you much, but I've encountered this in >Zenith's MS-DOS v3.21 also. Just so nobody feels alone, it's happened to me, too. I was trying to spawn a program from under a BBS program which had "shelled to DOS." I issued the spawn() call, and instead of locking up or dying, it immediately returned -- with no error code or anything. This is under MS-DOS 3.3, running under a V20 (which may explain why it barrels through rather than locking up... I'm no expert on this low- level stuff, but it seems plausible). -- ... Michael Ho, University of Nebraska Internet: ho@hoss.unl.edu
prk@planet.bt.co.uk (Peter Knight) (09/12/90)
west@turing.toronto.edu (Tom West) writes: > Does anyone know what the behaviour of the EXEC MS-DOS function is when >there is not enough memory to load COMMAND.COM. >Specifically, I have a line that is: > retcode = spawnve(P_WAIT, "C:\COMMAND.COM", path, environ); For my two-pennies worth, if your line reads as you have typed it here, you are bound to run into trouble. \ is the C string escape char, so the line to the program looks like "C:COMMON.COM", ie the directory information is lost. (\C goes to C). If the current directory for C: does not contain a COMMAND.COM, then you should get some failure. Better to get the directory information from the environment variable, COMSPEC. Peter Knight BT Research #include <std.disclaimer>
andy@mks.com (Andy Toy) (09/13/90)
In article <1990Sep9.063941.27673@uwasa.fi> ts@uwasa.fi (Timo Salmi LASK) writes: [in Turbo Pascal] >SwapVectors; >Exec (GetEnv(comspec), '/c ' + 'your command'); >SwapVectors; >If DosError <>0 then whatever; Is there an equivalent way to do this in Turbo C/C++? In other words, how do you get the return code of 'your command' instead of the return code of `comspec' (command.com) which is usually zero since command.com doesn't return the return code of the command run with `/c' option. Does SwapVector do some magic to get the return code of `your command' instead of that of command.com? -- Andy Toy, Mortice Kern Systems Inc., Internet: andy@mks.com 35 King Street North, Waterloo, UUCP: uunet!watmath!mks!andy Ontario, CANADA N2J 2W9 Phone: 519-884-2251 FAX: 519-884-8861
garym@cognos.uucp@uunet.uu.net (Gary Murphy) (09/14/90)
On 8 Sep 90 23:41:13 GMT, mju@mudos.ann-arbor.mi.us (Marc Unangst) said: > west@turing.toronto.edu (Tom West) writes: > Does anyone know what the behaviour of the EXEC MS-DOS function is when > there is not enough memory to load COMMAND.COM. > > Specifically, I have a line that is: > > retcode = spawnve(P_WAIT, "C:\COMMAND.COM", path, environ); > [computer locks up when there isn't enough mem to load COMMAND.COM] Marc> This isn't going to help you much, but I've encountered this in Marc> Zenith's MS-DOS v3.21 also. Your best bet might be to check to see if Marc> there's at least 50K left, and refuse to spawn the command processor Marc> if there isn't. There are other alternatives: SIMTEL has several packages which provide a 'swapping' version of spawn to write the spawned-from application to disk and free all but a few K before the spawned-to application runs. -- Gary Murphy uunet!mitel!sce!cognos!garym (garym%cognos.uucp@uunet.uu.net) (613) 738-1338 x5537 Cognos Inc. P.O. Box 9707 Ottawa K1G 3N3 "There are many things which do not concern the process" - Joan of Arc
cjdb@ellis.uchicago.edu (Charles Blair) (09/21/90)
In article <eJB8o4w163w@mudos.ann-arbor.mi.us> mju@mudos.ann-arbor.mi.us (Marc Unangst) writes: >[...] >Also, PLEASE don't hardcode "C:\COMMAND.COM" into your program. Not >only does it prevent people who don't have a hard disk from using your >program (if you think they're rare, what about people with diskless >workstations or computers with a floppy only, who run stuff off the >network?), but it prevents people from using an alternate command >processor, such as 4DOS, with your program. I'd suggest that you grab >COMSPEC from the environment and try to load that, and only try to >explicitly spawn COMMAND.COM if COMSPEC doesn't exist. Maybe try grabbing SHELL next? I run the MKS toolkit, and frankly I'd prefer it if programs grabbed shell first, since COMSPEC is set to c:/command.com, and SHELL is set to c:/bin/sh.exe. But this is just peculiar to my setup. When I get command.com, I just run sh.exe on top of it, but it wastes some memory. -- Bitnet: pmrcjdb@uchimvs1 Internet: cjdb@midway.uchicago.edu
kankkune@cs.Helsinki.FI (Risto Kankkunen) (10/01/90)
In article <1990Sep13.162828.5480@mks.com> andy@mks.com (Andy Toy) writes: >In article <1990Sep9.063941.27673@uwasa.fi> ts@uwasa.fi (Timo Salmi LASK) writes: >[in Turbo Pascal] >>SwapVectors; >>Exec (GetEnv(comspec), '/c ' + 'your command'); >>SwapVectors; >>If DosError <>0 then whatever; > >Is there an equivalent way to do this in Turbo C/C++? In other words, >how do you get the return code of 'your command' instead of the return >code of `comspec' (command.com) which is usually zero since command.com >doesn't return the return code of the command run with `/c' option. Unfortunately, the code Timo Salmi showed above doesn't do what you want in TP either. DosError variable simply tells if the exec call succeeded, i.e. whether TP could start the program. In C you get this info from the return value of the execXX call, I think. There is a function in TP, DosExitCode, that returns the exit code of a child program. But as you say, command.com doesn't pass the exit code of programs run by it. So DosExitCode would return always 0. If "your command" is a EXE or COM program, you could invoke it directly without command.com, and then DosExitCode works. DosExitCode corresponds to the DOS call INT 21H/AH=4DH (WAIT), so if TC doesn't have a library function for this, you could use the DOS call directly. >Does SwapVector do some magic to get the return code of `your command' >instead of that of command.com? SwapVectors only restores the original interrupt vectors for the duration of the child program. It doesn't have anything to do with the return codes. -- Risto Kankkunen kankkune@cs.Helsinki.FI (Internet) Department of Computer Science rkankkunen@finuh (Bitnet) University of Helsinki, Finland ..!mcvax!uhecs!kankkune (UUCP)