Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!yale!cs.yale.edu!fischer-michael From: fischer-michael@cs.yale.edu (Michael Fischer) Newsgroups: comp.sys.atari.st.tech Subject: Re: Memory deallocation after TSR Message-ID: <27629@cs.yale.edu> Date: 6 Dec 90 16:55:14 GMT References: <8381@star.cs.vu.nl> <5208@brahma.cs.hw.ac.uk> Sender: news@cs.yale.edu Distribution: comp Organization: Yale University Computer Science Dept., New Haven, CT 06520-2158 Lines: 40 Nntp-Posting-Host: ginkgo.theory.cs.yale.edu Originator: fischer@ginkgo.CS.Yale.Edu In article <5208@brahma.cs.hw.ac.uk> neil@cs.hw.ac.uk (Neil Forsyth) writes: >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? I wrote such a ramdisk some time ago and use it regularly. The ramdisk program consists of two parts: a small resident driver and a configuration program which allocates and frees memory for the ramdisk. To keep the memory from disappearing when the configuration program exits, I change the current process pointer (a documented system variable in low memory) to another value before doing the Malloc and restore it to its old value immediately after. (I think I set it to the basepage of the driver program, but I might be using the basepage of the desktop or some other process that isn't likely to go away.) This causes Gemdos to think the allocated memory "belongs" to the driver instead of to the configuration program and hence it won't be freed automatically when the configuration program terminates. This method of allocating persistent memory works under TOS 1.4. However, I don't think it is officially approved for the user to write to the current process pointer, so this scheme probably isn't guaranteed to work under future versions of TOS. (I also don't recall whether or not it works under older versions of TOS.) Unfortunately, I don't know of any way that IS officially sanctioned to allocate and free resident memory. I should point out that another problem one faces is memory fragmentation. Memory is allocated and freed in blocks. If one allocates blocks A, B, C in that order and then frees block B, there will be a "hole" in memory between blocks A and C. Free memory has now been split into two pieces, the hole and the rest of memory after block C. Whether or not the memory in the hole is useful depends on how big it is and how large the blocks are that are needed in the future. -- ================================================== | Michael Fischer | ==================================================