Path: utzoo!mnetor!uunet!lll-winken!lll-tis!oodis01!uplherc!sp7040!obie!wes From: wes@obie.UUCP (Barnacle Wes) Newsgroups: comp.sys.atari.st Subject: Re: preloading programs Message-ID: <219@obie.UUCP> Date: 4 May 88 15:37:43 GMT References: <8804141742.AA01455@decwrl.dec.com> <693@ast.cs.vu.nl> <474@philmds.UUCP> Organization: Great Salt Lake Yacht Club, north branch Lines: 32 Summary: A problem or two... In article <474@philmds.UUCP>, leo@philmds.UUCP (Leo de Wit) writes: > [...] > Then I decided to preload the ls command (with gemdos(0x4b,3,"ls",0,0)). > The gemdos function returns the basepage address of the loaded program. > Now 'find', each time it has to 'ls', copies the argument string into the > basepage; then it runs 'ls' by gemdos(0x4b,4,0,0,0) (I don't remember whether > these are the correct values for the parameters). It is now (nearly) as fast > as a builtin function! > > There are however a few problems (and I have not solved all of them): One of the problems is that GEMDOS will release all of the memory allocated to program, including that gotten in the original load/Mshrink process, when the program exits via Pterm or Pterm0. I don't know if the Pexec(,4,,,) call re-allocates that memory or not. You might want to experiment by loading a program, then finding the size of memory in the parent program. Exec the program, then again find the size of memory in the parent. If it goes up, DOS has freed the memory consumed by the child program. You might also want to make the child program find the free memory size and print it, too. If it goes up after the first exec, down during the second exec, and up after the second exec (get that?), the DOS is re-allocating the memory when you do Pexec(,4,,,). BTW, you find the "free memory size" is Malloc(-1L). It returns a (long) size of memory in bytes. -- /\ - "Against Stupidity, - {backbones}! /\/\ . /\ - The Gods Themselves - utah-cs!uplherc! / \/ \/\/ \ - Contend in Vain." - sp7040!obie! / U i n T e c h \ - Schiller - wes