Path: utzoo!utgpu!attcan!uunet!yale!root From: root@yale.UUCP (Celray Stalk) Newsgroups: comp.sys.atari.st Subject: Allocating long-lived memory blocks Keywords: Malloc, Gemdos Message-ID: <39617@yale-celray.yale.UUCP> Date: 5 Oct 88 18:31:16 GMT References: <39610@yale-celray.yale.UUCP> Reply-To: fischer-michael@CS.YALE.EDU (Michael Fischer) Organization: Yale University Computer Science Dept, New Haven CT 06520-2158 Lines: 49 The following problem came up while writing a resizable ramdisk. What I wanted was a ramdisk which could be installed, resized, and deinstalled without causing a reboot of the system and without losing memory blocks. The idea was to break it into two parts: a small memory-resident driver program and an ordinary transient program RD to interact with the user and allocate/deallocate memory for the ramdisk. The problem is, how can RD allocate a memory block that outlives the invocation of RD, for GEMDOS automatically frees all memory allocated by a process when it terminates. I have found two hacks which both seem to work, but both violate official Atari specs for safe programming: 1. After allocating the block, search GEMDOS's memory allocation chain to find the descriptor of the just-allocated block, and change its owner field to that of the oldest process in the process list. That way, the block is not recognized as being owned by RD and is not freed when RD terminates. 2. Change Gemdos's current process pointer to point to the oldest process in the process list, Malloc the memory block, and then restore the current process pointer. Again, the memory block ends up looking like it belongs to some other process and hence is not freed when RD exits. In both cases, the memory can be subsequently freed by a reverse of the above, namely, force the block's owner to agree with the current process pointer and then call Mfree. The first method requires the undocumented location of the head of the memory allocation chain and also relies on internal Gemdos data structures. The second method uses a location that has been newly documented in TOS 1.4, but it involves writing to that location, which is not supported. Question: Is there a supported way of accomplishing this? ================================================== | Michael Fischer | | Arpanet: | | Bitnet: | | UUCP: | ================================================== ================================================== | Michael Fischer | | Arpanet: | | Bitnet: | | UUCP: | ==================================================