root@yale.UUCP (Celray Stalk) (10/06/88)
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: <fischer-michael@cs.yale.edu> | | Bitnet: <fischer-michael@yalecs.bitnet> | | UUCP: <fischer-michael@yale.UUCP> | ================================================== ================================================== | Michael Fischer | | Arpanet: <fischer-michael@cs.yale.edu> | | Bitnet: <fischer-michael@yalecs.bitnet> | | UUCP: <fischer-michael@yale.UUCP> | ==================================================
uace0@uhnix2.uh.edu (Michael B. Vederman) (10/06/88)
You basically have the right idea as described in the second algorithm, ie.
change the _run variable pointer to point to the basepage of the oldest process
which should be the desktop. This however is a problem if allocated within a
program. We have just implemented this for SHADOW, and have it working very
well, with some helpful advice from ATARI.
The _run pointer MUST point to a valid basepage, not the desktop's, which we
found to cause trouble. Of course, the location of _run is not documented
for pre-Mega ROMs, so you will have to hack out the location and hardwire it.
- mike
Double Click Software
--
for (;;) : Use ATARINET, send an interactive
do_it(c_programmers); : message such as:
: Tell UH-INFO at UHUPVM1 ATARINET HELP
University Atari Computer Enthusiasts : University of Houston UACEapratt@atari.UUCP (Allan Pratt) (10/07/88)
No, there is no supported way to accomplish what you ask. However, the two methods you describe should work. Please note that, while the current-process variable was documented for TOS 1.4, it does exist in TOS 1.2 -- that's Mega ROMs. But it does not exist, documented or not, in TOS 1.0, so don't assume it was there and we didn't document it. As you say, writing to this variable is not supported. However, if I had to choose, that's the route I would take. I'm not promising, just advising. ============================================ Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp. reflect those of Atari Corp. or anyone else. ...ames!atari!apratt
apratt@atari.UUCP (Allan Pratt) (10/08/88)
In article <686@uhnix2.uh.edu> uace0@uhnix2.UUCP writes: > The _run pointer MUST point to a valid basepage, not the desktop's, which we > found to cause trouble. Oh, yes - I'd forgotten about that restriction. The most likely candidate is the basepage of the TSR portion of your application. If you don't have one, you'll have to get one. If you use the basepage of any current process (your parent or any of its parents, all the way to the desktop) you'll be sorry. That's because the context they need to return from the Pexec they've called is stored in the basepage. Please don't take this as license to do strange things with _run ... remember that _run is STILL only guaranteed as a read-only variable, and the things it points to are read-only, too (except by the OS itself). If something works, fine, but remember that you're taking a chance on not having it work in the future. ============================================ Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp. reflect those of Atari Corp. or anyone else. ...ames!atari!apratt