|
Thanks Jeff. Whenever I run the program that shows me the remaining
folder slots it comes up with "Folders left: ???" so I thought that
the FOLDRXXX.PRG is not neccessary anymore. Well, I'll put it back
into the Auto-folder and take a look if I have POOLFIX.TOS in my
PD library. What is it for, b.t.w.?
Bernd
|
| > 40 FOLDER BUG? STReport OnLine? Clarification of the 'bug rumor'.
==============================
ctsy GEnie RT
Category 14, Topic 10
Message 39 Tue Dec 12, 1989
MJANSEN [Mark @ Atari] at 20:54 EST
Allan Pratt asked me to post this message, which he wrote in response
to the same topic on UseNet.
----------------------------------------------------------------
Subject: 40-folder limit has returned with a vengeance in TOS 1.4.
A user posted that TOS 1.4 was flawed with the same old 40 folder bug, A.
Pratt of Atari offers the following clarification.
He is wrong.
He says that the space where memory block descriptors are maintained
and the space where directory node descriptors are maintained overlap.
This is true. But this is no bug: both data structures, and some other
things, are dynamically allocated out of the same pool of memory (called
"the OS pool").
He says that using FOLDRXXX.PRG will alleviate the problem. He is
right, but not for the reason he thinks.
The root of all this evil is that the OS pool itself is statically
allocated. There is only so much room there, for directory descriptors,
memory block descriptors, and open-file descriptors. Using FOLDRXXX.PRG
adds more memory to be used for these things.
The original problem with the pool was that it was not only statically
allocated, but it was also managed poorly: once a piece of the pool was
used as (say) a memory descriptor, it was forever tagged as a memory
descriptor, and could never be used as a directory descriptor. Starting
with TOS 1.4, this is no longer the case. When something allocated from
pool is freed, the memory becomes available for any other data structure
which is allocated from the pool.
Furthermore, once a directory descriptor was allocated from the pool,
IT WAS NEVER FREED. It stood forever, recording its place in the
directory structure, even if you never used that directory again. And it
was allocated if you even so much as SAW the name of the directory in a
window, let alone actually opened that directory. I fixed that, too, so
only "active" directories take up memory in the pool, and others can be
freed when the memory is required for something else.
That's why I say that TOS 1.4 pushes the limits of the admittedly-evil
static OS pool farther away than previous OSes. And using FOLDRXXX.PRG
adds pool (for all its uses, not just folders), so you can push the limits
arbitrarily far.
========================================================================
Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp.
reflect those of Atari Corp. or anyone else. ...ames!atari!apratt
========================================================================
Hope this clears things up.
Mark Jansen
Atari Corporation
|