🚀 go-pugleaf

In article <402@clio.math.lsa.umich.edu>, hyc@math.lsa.umich.edu (Howard Chu) writes:
> I get the feeling that there really is no solution at this point. How can you
> have two different versions of Malloc/Free in the same system?

Actually, you don't need to make another Malloc, just make the current
one smarter.  The problem with the current Malloc is that it uses a
static data area, rather than a linked list, to keep track of allocated
memory blocks.  This is essentially similar to the idea of file handles.

There was a version of MS-DOS once upon a time (I think it was 2.xx)
that had an interesting way of expanding the number of files a process
could use.  The file handle pool was actually allocated in the Program
Segment Prefix (PSP), which GEMDOS calls a basepage.  There was a
pointer to the file handles, which pointed to a 20-byte data area in the
PSP, and 20 bytes for file handles.

As it turned out, a program could copy the 20 bytes to a (hopefully
larger :-) data area, zero the remainder of the data area, and point the
pointer to this new data area.  There must have also been a datum that
described how many handles were available, which also had to be updated.
From that point on, the process could use that many file handles, as
long as the sytem FILES parameter, set by CONFIG.SYS at boot time, would
allow that many files open.

If the new GEMDOS used a "Malloc handle" pool that were relocatable in
this manner, new applications that new of this feature would be able to
Malloc more than the current 20 (or so) blocks, while retaining the
essentially static data structures required for compatibility with the
current Malloc.

cat flames > /dev/null
mailx applause money fame wes@obie



-- 
                     {hpda, uwmcsd1}!sp7040!obie!wes
           "Happiness lies in being priviledged to work hard for
           long hours in doing whatever you think is worth doing."
                         -- Robert A. Heinlein --