🚀 go-pugleaf

Here's the story:

GEMDOS has a statically-allocated memory pool called the OSPOOL.  It is
of fixed size.  Directory descriptors are allocated from this pool.  So
are file descriptors, handles, and other things.

The memory allocation for this pool is pretty bad.  Mainly, once a
directory descriptor is allocated from it, it only gets freed when
there's a media-change on that drive.

Hard drives never show media change, so directory descriptors are never
freed.

When this pool is exhausted, bad things happen.  Most of the OS checks
for failure to allocate, but parts of it don't.  When you have exhausted
the pool, you will get empty directories where you expected files, and
other odd behavior.  You can even lose the data on your hard disk because
writes are made on the basis of invalid data structures, but this is
pretty rare.

The upshot is that you can't have more than about 40 folders on all your
hard disk partitions combined.  Hence, "the 40-folder limit."

The program FOLDR100.PRG adds 100 folders to the limit.  Place it in
your AUTO folder.  (That is, a folder called "AUTO" in the root of the
boot device.) If you rename it to FOLDR050.PRG, it will add 50 folders
to the limit, and use up half as much memory.  Note that it looks for
the file "<boot device>:\AUTO\FOLDR???.PRG" for the number of folders it
should add: that's the only file name which matters. 

The next release of GEMDOS has this bug fixed.  The limit is pushed so
far away that nobody will run up against it, and if they do, FOLDR100.PRG
still works.  (The remaining limits are on things like the maximum DEPTH
of a folder, and on the distribution of open files.)

That's not the only improvement I have made to GEMDOS.  Other notable ones
are much faster FAT handling code (so much-used hard disks don't run much
more slowly than empty ones) and other miscellaneous fixes.

The completion/beta test/delivery schedule of the release that will
include this improved GEMDOS is currently being discussed. 

============================================
Opinions expressed above do not necessarily	-- Allan Pratt, Atari Corp.
reflect those of Atari Corp. or anyone else.	  ...ames!atari!apratt