mdf@osu-eddie.UUCP (05/26/87)
We have a program called memfree.exe that just prints out the available memory. Memfree always agrees with chkdsk. We wrote a program that does nothing but spawns memfree and returns. Running memfree from dos shows 70K more available than running memfree from our spawn test program (that is, of course, running under dos). Why does spawn eat up 70K? Is there a way around this? -- < < < < < < < < < < < < < < < < < < < <> > > > > > > > > > > > > > > > > > > > Mark D. Freeman mdf@osu-eddie.uucp StrongPoint Systems, Inc. mdf@Ohio-State.arpa 2440 Medary Avenue ...!cbosgd!osu-eddie!mdf Columbus, OH 43202 Guest account at The Ohio State University (614) 262-3703 < < < < < < < < < < < < < < < < < < < <> > > > > > > > > > > > > > > > > > > >
mac@idacrd.UUCP (Bob McGwier) (05/27/87)
in article <3605@osu-eddie.UUCP>, mdf@osu-eddie.UUCP (Mark D. Freeman) says: > > We have a program called memfree.exe that just prints out the > available memory. Memfree always agrees with chkdsk. > > We wrote a program that does nothing but spawns memfree and returns. > Running memfree from dos shows 70K more available than running memfree > from our spawn test program (that is, of course, running under dos). > > Why does spawn eat up 70K? Is there a way around this? > > -- > < < < < < < < < < < < < < < < < < < < <> > > > > > > > > > > > > > > > > > > > > Mark D. Freeman I assume you'd like to be able to call disk files, do commands etc when you run spawn so you have to have a copy of the command processor loaded into memory for one thing. Bob .
kneller@socrates.ucsf.edu (Don Kneller%Langridge) (05/27/87)
In article <3605@osu-eddie.UUCP> mdf@osu-eddie.UUCP (Mark D. Freeman) writes: >We have a program called memfree.exe that just prints out the >available memory. Memfree always agrees with chkdsk. > >We wrote a program that does nothing but spawns memfree and returns. >Running memfree from dos shows 70K more available than running memfree >from our spawn test program (that is, of course, running under dos). > >Why does spawn eat up 70K? Is there a way around this? By default, small model programs get 64K of data space. This can be reduced to a minimum by using the /CP (can't recall the full name - CPARAMAX?) switch of the linker. Use /CP:1 and LINK will figure out how much to actually allocate. Alternatively, "exemod memfree.exe /min 1 /max 1" should also do it. ----- Don Kneller UUCP: ...ucbvax!ucsfcgl!kneller ARPA: kneller@cgl.ucsf.edu BITNET: kneller@ucsfcgl.BITNET
srp@ethz.UUCP (05/29/87)
In article <222@idacrd.UUCP> mac@idacrd.UUCP (Bob McGwier) writes: >in article <3605@osu-eddie.UUCP>, mdf@osu-eddie.UUCP (Mark D. Freeman) says: >> >> We have a program called memfree.exe that just prints out the >> available memory. Memfree always agrees with chkdsk. >> >> We wrote a program that does nothing but spawns memfree and returns. >> Running memfree from dos shows 70K more available than running memfree >> from our spawn test program (that is, of course, running under dos). >> >> Why does spawn eat up 70K? Is there a way around this? >I assume you'd like to be able to call disk files, do commands etc when >you run spawn so you have to have a copy of the command processor loaded >into memory for one thing. > >Bob I believe that this is incorrect. Spawn does not call command.com, that is a job for system(). As an example, try spawning a batch file -- I don't think it will work. Some of the things that are in those 70k are 1) Open file (and pointers) table, 2) Personal copy of the environment (though on my machine that comes to a measly 0x22d bytes). The rest?? who knows -- (really, anyone know?) -------------- Scott Presnell Swiss Federal Institute of Technology (ETH-Zentrum) Department of Organic Chemistry Universitaetsstrasse 16 CH-8092 Zurich Switzerland. uucp: ...seismo!mcvax!cernvax!ethz!srp (srp@ethz.uucp) earn/bitnet: Benner@CZHETH5A