sarathy@gpu.utcs.utoronto.ca (Rajiv Sarathy) (09/29/90)
Since I posted the original article to both c.l.c and c.o.m.p, I've posted the summary to both also. Henceforth, I'll only use the latter, as should anyone else asking about MS-DOS related things, IMHO. Flames to /dev/null. A couple of weeks ago, I posted an article asking for opinions on using various techniques to reduce the amount of code sitting in memory from a very large application. Some of the options I suggested were: a) Overlays b) using MS C's "spawn" c) using MS C's "exec" d) using MS C's "system" I also gave some obvious pros and cons of each. Several people responded. I've decided that my initial hunch, using overlays, is the best choice despite its drawbacks (time to load/unload, MS Linker's inability to optimize modules automatically, inability to use some functions in more than one module, etc.). Some people suggested using Borland's VROOM (included with C++). As toma@tekgvs.LABS.TEK.COM (Tom Almy) posted, VROOM will not work with MS OBJs. (This according to a friend who sells Borland products but isn't a programmer ;-) Others were under the impression that spawn and exec load an additional copy of COMMAND.COM. I didn't test to see if this is true, but I doubt it. The manual makes no mention of it, and MS Tech Support in Canada didn't think so either. We were both under the assumption that the new process is just loaded into higher memory in the case of spawn (with P_WAIT), and loaded on top of the caller in the case of spawn (with P_OVERLAY), and exec. The system call, however, does execute another command interpretor. Thanks for everyone's help. -- Rajiv Partha Sarathy _ _ /@\ INTERNET sarathy@gpu.utcs.utoronto.ca ................ooooooooOOOO(_)(_)\@/ BITNET sarathy@utorgpu.bitnet University Of Toronto Computing Services UUCP sarathy@utgpu.uucp
kdq@demott.COM (Kevin D. Quitt) (09/30/90)
In article <1990Sep28.234836.17868@gpu.utcs.utoronto.ca> sarathy@gpu.utcs.utoronto.ca (Rajiv Sarathy) writes: > >Others were under the impression that spawn and exec load an additional >copy of COMMAND.COM. I didn't test to see if this is true, but I doubt it. If you doubt it, make your comspec=a:\command.com and see how slowly your program comes up. I've just gone through that exercise. -- _ Kevin D. Quitt demott!kdq kdq@demott.com DeMott Electronics Co. 14707 Keswick St. Van Nuys, CA 91405-1266 VOICE (818) 988-4975 FAX (818) 997-1190 MODEM (818) 997-4496 PEP last 96.37% of all statistics are made up.
rreiner@yunexus.YorkU.CA (Richard Reiner) (09/30/90)
kdq@demott.COM (Kevin D. Quitt) writes: >In article <1990Sep28.234836.17868@gpu.utcs.utoronto.ca> sarathy@gpu.utcs.utoronto.ca (Rajiv Sarathy) writes: >> >>Others were under the impression that spawn and exec load an additional >>copy of COMMAND.COM. I didn't test to see if this is true, but I doubt it. > If you doubt it, make your comspec=a:\command.com and see how slowly >your program comes up. I've just gone through that exercise. I've done one better: I wrote a little program that spawned a memory mapper as its child. The resulting map clearly shows that there is *no* copy of command.com loaded by spawn(). --richard
mlord@bwdls58.bnr.ca (Mark Lord) (10/02/90)
>>>Others were under the impression that spawn and exec load an additional >>>copy of COMMAND.COM. I didn't test to see if this is true, but I doubt it. > >> If you doubt it, make your comspec=a:\command.com and see how slowly >>your program comes up. I've just gone through that exercise. > >I've done one better: I wrote a little program that spawned a memory >mapper as its child. The resulting map clearly shows that there is >*no* copy of command.com loaded by spawn(). Ok.. I believe the difference here is whether or not the complete path is given for the command. If fully qualified, COMMAND.COM is not needed, otherwise it probably is needed to do the PATH search and actual invocation. Ie. "C:\BIN\MAPMEM.COM" -- probably does not need COMMAND.COM "MAPMEM" -- probably DOES need COMMAND.COM I say probably because my Machine is unavailable to verify this theory for now. -- ___Mark S. Lord__________________________________________ | ..uunet!bnrgate!mlord%bmerh724 | Climb Free Or Die (NH) | | MLORD@BNR.CA Ottawa, Ontario | Personal views only. | |________________________________|________________________|
kdq@demott.COM (Kevin D. Quitt) (10/02/90)
In article <15651@yunexus.YorkU.CA> rreiner@yunexus.YorkU.CA (Richard Reiner) writes: >kdq@demott.COM (Kevin D. Quitt) writes: > >>In article <1990Sep28.234836.17868@gpu.utcs.utoronto.ca> sarathy@gpu.utcs.utoronto.ca (Rajiv Sarathy) writes: >>> >>>Others were under the impression that spawn and exec load an additional >>>copy of COMMAND.COM. I didn't test to see if this is true, but I doubt it. > >> If you doubt it, make your comspec=a:\command.com and see how slowly >>your program comes up. I've just gone through that exercise. > >I've done one better: I wrote a little program that spawned a memory >mapper as its child. The resulting map clearly shows that there is >*no* copy of command.com loaded by spawn(). > Sure wish I had your system. When I do that, I see command.com clear as day. -- _ Kevin D. Quitt demott!kdq kdq@demott.com DeMott Electronics Co. 14707 Keswick St. Van Nuys, CA 91405-1266 VOICE (818) 988-4975 FAX (818) 997-1190 MODEM (818) 997-4496 PEP last 96.37% of all statistics are made up.
funkstr@ucscb.UCSC.EDU (Larry Hastings) (10/02/90)
+-In article <4469@bwdls58.UUCP>, | mlord@bwdls58.bnr.ca (Mark Lord) wrote: | | >>>Others were under the impression that spawn and exec load an additional | >>>copy of COMMAND.COM. I didn't test to see if this is true, but I doubt it. | [other followups deleted] | | Ok.. I believe the difference here is whether or not the complete path is | given for the command. If fully qualified, COMMAND.COM is not needed, | otherwise it probably is needed to do the PATH search and actual invocation. | +---------- Let's clear this all up. Here's the dirt on system() and spawn(), including questions that haven't come up... system() loads another copy of "the command processor" (on DOS, COMMAND.COM) and passes as parameters to the command processor the command you pass to it. The return value of system() is the return value of the command processor -- if it ran successfully, this will be a 0 -- and _not_ the return value of the program itself. spawn() loads the program you specify directly without a command processor under all circumstances. The return value of spawn() commands is the actual return value of the program you ran. There's one side effect of spawn() that you may not have expected: Many standard commands are actually part of the command processor itself (for instance, under DOS CD, COPY, MKDIR, and ECHO are all part of COMMAND.COM) and are _not_ separate programs. (There's no COPY.COM or ECHO.COM on DOS.) This means you _can't_ use spawn() to do a MKDIR, unless you load a copy of the command processor -- which is what system() does _anyway_. (In fact, I'm guessing that in many libraries, system() is just a front-end to spawn().) I haven't used spawn() on UNIX, but on Turbo C and MSC there are six varieties of spawn commands, depending on: * Whether you want the path searched for the program (this is handled by code in the run-time library, NOT by COMMAND.COM) * Whether you want to pass a modified environment to the program (by default, the shell variables from the parent are passed unmodified to the child) * Whether you want to pass the command-line for the program as a "vector" (an array of pointers -- like char *argv[]) or as individual char * arguments (steps off soapbox) I used to work in technical support for a compiler company, and I've answered this question more than once... -- larry hastings, the galactic funkster, funkstr@ucscb.ucsc.edu I don't speak for Knowledge Dynamics or UC Santa Cruz, nor do they speak for me The 4th law of Robotics (courtesy of Lore Shoberg): "A robot must encourage proper dental hygiene, except where such encouragement would interfere with the 0th, 1st, 2nd, and 3rd laws."
friedman@apple-gunkies.ai.mit.edu (Noah Friedman) (10/03/90)
In article <4469@bwdls58.UUCP> mlord@bwdls58.bnr.ca (Mark Lord) writes: >Ok.. I believe the difference here is whether or not the complete path is >given for the command. If fully qualified, COMMAND.COM is not needed, >otherwise it probably is needed to do the PATH search and actual invocation. > >Ie. "C:\BIN\MAPMEM.COM" -- probably does not need COMMAND.COM > "MAPMEM" -- probably DOES need COMMAND.COM > >I say probably because my Machine is unavailable to verify this theory for now. Most C libraries have an execvp() function which will search directories in the PATH environment variable if the program name is not a fully-qualified pathname. If you are unsure, you can always use this function or attempt to resolve the full pathname in your program. I suspect, however, that the EXEC call does *not* use COMMAND.COM, but rather, uses the current path when a filename is not fully qualified. This would be consistent with the behavior of other DOS system calls. I cannot at the moment verify this either since my XT is down, but I seem to remember from experience that this is correct. --- Noah Friedman friedman@ai.mit.edu
kdq@demott.COM (Kevin D. Quitt) (10/03/90)
In article <4469@bwdls58.UUCP> mlord@bwdls58.bnr.ca (Mark Lord) writes: > >Ok.. I believe the difference here is whether or not the complete path is >given for the command. If fully qualified, COMMAND.COM is not needed, >otherwise it probably is needed to do the PATH search and actual invocation. > >Ie. "C:\BIN\MAPMEM.COM" -- probably does not need COMMAND.COM > "MAPMEM" -- probably DOES need COMMAND.COM Sounds correct - thanks. This will speed me up a bit where I needed to be sped up. -- _ Kevin D. Quitt demott!kdq kdq@demott.com DeMott Electronics Co. 14707 Keswick St. Van Nuys, CA 91405-1266 VOICE (818) 988-4975 FAX (818) 997-1190 MODEM (818) 997-4496 PEP last 96.37% of all statistics are made up.
2113av@gmuvax2.gmu.edu (John Porter) (10/04/90)
In article <1990Sep28.234836.17868@gpu.utcs.utoronto.ca> sarathy@gpu.utcs.utoronto.ca (Rajiv Sarathy) writes: >Others were under the impression that spawn and exec load an additional >copy of COMMAND.COM. I didn't test to see if this is true, but I doubt it. The MS-DOS programming references are rather explicit on this point. I have written programs to test these hypotheses, and it is quite true (at least for ver.3.30) that spawn and exec do NOT load COMMAND.COM. Both of these system calls are handled by a load/exec routine located in the resident portion of DOS. -- john.porter
stever@Octopus.COM (Steve Resnick ) (10/05/90)
In article <639@demott.COM> kdq@demott.COM (Kevin D. Quitt) writes: >In article <4469@bwdls58.UUCP> mlord@bwdls58.bnr.ca (Mark Lord) writes: >> >>Ok.. I believe the difference here is whether or not the complete path is >>given for the command. If fully qualified, COMMAND.COM is not needed, >>otherwise it probably is needed to do the PATH search and actual invocation. >> >>Ie. "C:\BIN\MAPMEM.COM" -- probably does not need COMMAND.COM >> "MAPMEM" -- probably DOES need COMMAND.COM > I just wrote a program, which has the line in it: spawnlp(P_WAIT,"MAPMEM","MAPMEM",NULL); It DOES NOT load a copy of command.com, but keep in mind, spawn is a library function, and it's behaviour may vary from vendor to vendor. As a side note, the DOS EXEC Function (4BH) DOES NOT use command.com to load programs. (Think about it - INT 21H, AH=4BH is also used to load overlays - do you want COMMAND between your application and your overlay?) BTW - the spawn and exec library function (for Turbo and Microsloth) have variations which search the path for the program you specify. In either family, a spawn or exec function with a p in the name specifies to search the path. Hope this helps (or at least annoys! (-8) Steve -- ---------------------------------------------------------------------------- steve.resnick@f105.n143.z1.FIDONET.ORG - or - apple!camphq!105!steve.resnick Flames, grammar errors, spelling errrors >/dev/nul ----------------------------------------------------------------------------
2113av@gmuvax2.gmu.edu (John Porter) (10/05/90)
In article <626@demott.COM> kdq@demott.COM (Kevin D. Quitt) writes: > Sure wish I had your system. When I do that, I see command.com clear >as day. Not to be picky or skeptical, but: are you saying you saw *another* copy of command.com *between* your parent and your child, the memory mapper? Because, as you know, the original command.com is always around, but it is below any transient user processes. -- john.porter
keck@sea.com (John Keck) (10/06/90)
In article <4469@bwdls58.UUCP> mlord@bwdls58.bnr.ca (Mark Lord) writes: >>>>Others were under the impression that spawn and exec load an additional >>>>copy of COMMAND.COM. I didn't test to see if this is true, but I doubt it. >> >>> If you doubt it, make your comspec=a:\command.com and see how slowly >>>your program comes up. I've just gone through that exercise. >> >>I've done one better: I wrote a little program that spawned a memory >>mapper as its child. The resulting map clearly shows that there is >>*no* copy of command.com loaded by spawn(). > >Ok.. I believe the difference here is whether or not the complete path is >given for the command. If fully qualified, COMMAND.COM is not needed, >otherwise it probably is needed to do the PATH search and actual invocation. > >Ie. "C:\BIN\MAPMEM.COM" -- probably does not need COMMAND.COM > "MAPMEM" -- probably DOES need COMMAND.COM > Seems to me I read somewhere the EXE loader is part of COMMAND.COM. So perhaps the distinction is whether the child is COM or EXE file. -- John Keck INTERNET:keck@sea.com UUCP:...!ucsd!soledad!keck VOICE:619/581-6181 Systems Engineering Associates, 2204 Garnet Ave Suite 203, San Diego CA 92109 ----------------------------------------------------------------------------- "Much speech leads inevitably to silence. Better to hold fast to the void."
kdq@demott.COM (Kevin D. Quitt) (10/06/90)
In article <2530@gmuvax2.gmu.edu> 2113av@gmuvax2.gmu.edu (John Porter) writes: >In article <626@demott.COM> kdq@demott.COM (Kevin D. Quitt) writes: >> Sure wish I had your system. When I do that, I see command.com clear >>as day. > >Not to be picky or skeptical, but: are you saying you saw *another* copy of >command.com *between* your parent and your child, the memory mapper? >Because, as you know, the original command.com is always around, but it >is below any transient user processes. No, I see the non-resident portion of command com taking up space above me, and my BIOS trace reports the reads from the sectors occupied by COMMAND.COM. (Quite right to be picky and skeptical - extraordinary claims and all that). -- _ Kevin D. Quitt demott!kdq kdq@demott.com DeMott Electronics Co. 14707 Keswick St. Van Nuys, CA 91405-1266 VOICE (818) 988-4975 FAX (818) 997-1190 MODEM (818) 997-4496 PEP last 96.37% of all statistics are made up.
2113av@gmuvax2.gmu.edu (John Porter) (10/06/90)
In article <1990Oct5.170852.29736@sea.com> keck@sea.com (John Keck) writes: >Seems to me I read somewhere the EXE loader is part of COMMAND.COM. So >perhaps the distinction is whether the child is COM or EXE file. I don't see how this could possibly be. Other replacement command interpreters are sometimes EXE files themselves. E.g. login.exe, of the MKS toolkit. -- john.port
Ralf.Brown@B.GP.CS.CMU.EDU (10/06/90)
In article <1990Oct5.170852.29736@sea.com>, keck@sea.com (John Keck) wrote: }In article <4469@bwdls58.UUCP> mlord@bwdls58.bnr.ca (Mark Lord) writes: }>Ok.. I believe the difference here is whether or not the complete path is }>given for the command. If fully qualified, COMMAND.COM is not needed, }>otherwise it probably is needed to do the PATH search and actual invocation. }> }>Ie. "C:\BIN\MAPMEM.COM" -- probably does not need COMMAND.COM }> "MAPMEM" -- probably DOES need COMMAND.COM }> } }Seems to me I read somewhere the EXE loader is part of COMMAND.COM. So }perhaps the distinction is whether the child is COM or EXE file. OK, a bit of history here.... Under DOS 1.x (both MS and PC), the program loader (both .COM and .EXE) is in the transient portion of COMMAND.COM. Under PC DOS 2.x, the program loader is in a *second* transient portion of COMMAND.COM. Under MSDOS 2.x, and all versions of DOS since 3.0, the programm loader is in the kernel (IBMBIO.COM or MSDOS.SYS). Whether the program is a .COM or a .EXE makes no difference as to whether it gets loaded by the kernel or COMMAND.COM, as there is only a single program loader. -- UUCP: {ucbvax,harvard}!cs.cmu.edu!ralf -=- 412-268-3053 (school) -=- FAX: ask ARPA: ralf@cs.cmu.edu BIT: ralf%cs.cmu.edu@CMUCCVMA FIDO: 1:129/3.1 Disclaimer? | I was gratified to be able to answer promptly, and I did. What's that? | I said I didn't know. --Mark Twain
ekalenda@cup.portal.com (Edward John Kalenda) (10/07/90)
In article <1990Oct5.170852.29736@sea.com> keck@sea.com (John Keck) writes: >Seems to me I read somewhere the EXE loader is part of COMMAND.COM. So >perhaps the distinction is whether the child is COM or EXE file. COMMAND.COM is actually two pieces. The resident portion has all the tables and code needed by other programs. The transient portion has the command line interpreter and the builtin DOS commands (copy, dir, etc.). DOS itself does the load and executee of both .COM and .EXE files. When COMMAND.COM executes a program, the transient portion relocates itself into high memory, freeing the memory it was in, and executes INT 21h function 0. When the program returns, the transient portion is reloaded by the resident portion, which is why you must have the COMMAND.COM you booted from available when your program exits. Since the program loader is part of DOS, the spawn() and exec() functions in C don't deal with COMMAND.COM at all. In fact, the system() function just uses spawn() with COMMAND.COM as the program to have DOS exec. So, if you know the path to the executable and don't need to redirect stdin or stdout, you can save memory by using spawn(). There are even variants in the library which will search the PATH environmental variable for you. The only reason to ever use system() is if you need redirection (and don't want to hassle it yourself) or you are trying to use a command built into COMMAND.COM or execute a batch file. Ed ekalenda@cup.portal.com
tcs@router.jhuapl.edu (10/10/90)
In article <626@demott.COM>, kdq@demott.COM (Kevin D. Quitt) writes: >In article <15651@yunexus.YorkU.CA> rreiner@yunexus.YorkU.CA (Richard Reiner) writes: >>kdq@demott.COM (Kevin D. Quitt) writes: >> >>>In article <1990Sep28.234836.17868@gpu.utcs.utoronto.ca> sarathy@gpu.utcs.utoronto.ca (Rajiv Sarathy) writes: >>>> >>>>Others were under the impression that spawn and exec load an additional >>>>copy of COMMAND.COM. I didn't test to see if this is true, but I doubt it. >> >>> If you doubt it, make your comspec=a:\command.com and see how slowly >>>your program comes up. I've just gone through that exercise. >> >>I've done one better: I wrote a little program that spawned a memory >>mapper as its child. The resulting map clearly shows that there is >>*no* copy of command.com loaded by spawn(). >> > > Sure wish I had your system. When I do that, I see command.com clear >as day. > > >-- > _ >Kevin D. Quitt demott!kdq kdq@demott.com >DeMott Electronics Co. 14707 Keswick St. Van Nuys, CA 91405-1266 >VOICE (818) 988-4975 FAX (818) 997-1190 MODEM (818) 997-4496 PEP last > > 96.37% of all statistics are made up. Realizing, of course, this may be a little late, I just created a small program that executed "pmap.com" from an execl() and I didn't see any command.com. This was in tc++. Carl Schelin tcs@router.jhuapl.edu