Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!elroy.jpl.nasa.gov!jarthur!uunet!mcsun!ukc!warwick!nott-cs!christopher-robin.cs.bham.ac.uk!cjr From: cjr@cs.bham.ac.uk (Chris Ridd ) Newsgroups: comp.sys.atari.st.tech Subject: Re: Memory deallocation after TSR Message-ID: <1372@christopher-robin.cs.bham.ac.uk> Date: 11 Dec 90 15:51:47 GMT References: <8381@star.cs.vu.nl> <5208@brahma.cs.hw.ac.uk> Reply-To: cjr@christopher-robin.UUCP (Chris Ridd ) Distribution: comp Organization: University of Birmingham, England Lines: 43 In article <5208@brahma.cs.hw.ac.uk> neil@cs.hw.ac.uk (Neil Forsyth) writes: >In article <8381@star.cs.vu.nl> rfschaa@cs.vu.nl (Schaaf R F ) writes: >> >> I have a problem: I have written a device driver for some virtual >>device. It performs some initialisations, then quits by using the >>gemdos(49) call (TSR). After a while, when I don't need the driver >>anymore I would like to free the memory used up by the driver and >>give it back for general use. Is there any way this can be done? > [...deleted...] >What I want to write is a temporary RAM disk for use under Gulam. >That way I could have a RAM disk while compiling a C program but throw it >away afterwards leaving more memory for the compiled application to play >with. Pure joy! Pure fantasy? The latter, I think... The Lattice C5 manual says something to the effect that any memory belonging to a process which does a Ptermres is *removed* from the free-memory pool, and is effectively lost forever (or until the next reboot, whichever comes first). A thought - can you stick the code above phystop, making it reset-resident, and then move phystop back up again to 'delete' it? Or do changes to phystop only get noticed on reboots? I might have the wrong variable here, but do you all know what I mean? > >I tried some really weird things like re-executing the TSR using Pexec #4 >in the hope that a Pterm instead of Ptermres would blow it away on the second >run. Another good try was for the TSR to Mfree it's own basepage. The results >were either no effect or bomb outs. > Presumably the Mfree would not be able to re-insert the memory back into the main 'pool'? >Come on Allan, help us out on this one. Chris -- Chris Ridd, Computer Science, Birmingham Uni, UK -- RiddCJ@Cs.Bham.Ac.Uk -- "'It's going to look pretty good, then, isn't it,' said War testily, 'the One Horseman and Three Pedestrians of the Apocralypse.'" - Sourcery