🚀 go-pugleaf

Well I believe I have found a real interaction problem between GEMBOOT and
another program, namely the ZOOMRACKS database. I have a 1 meg system with
the SUPRA 20 meg hard drive. ZOOMRACKS is on the hard disk (I have found
that this doesn't matter-problem still exists when its on a floppy and
GEMBOOT is active on the HD. THE PROBLEM: with GEMBOOT installed in my
AUTO directory on the hard disk, and ZOOMRACKS in a partition C sub-directory
I try to execute ZR. (This is ZOOMRACKS II, but I doubt it matters). All
I get is 3 bombs (sometimes 6) and the system goes through reset. Well this
looked suspiciously like a problem I had with ZOOMRACKS and the BARREL printer
spooler. It seems that ZR is not a well behaved GEM program. It uses parts of 
RAM without checking whether it's being used by anyone else! I suspect that
GEMBOOT now expands into this RAM area (as the printer buffers in BARREL) and
results in ZOOMRACKS crashing. I checked this out with someone at QUICKVIEW
(ZOOMRACKS) and he confirmed that ZR is not well behaved. He stated that he
hoped to fix it in the next 3-4 months. I believe that this has been a problem
for a while. I really like the ZR database program but now I can't use it
while protecting the integrity of my hard disk. If I don't have GEMBOOT in
my AUTO directory ZR works fine. I retried executing ZR without GEMBOOT and all
is well. Fortunately I still have only 33 directories on my HD. I hope both
applications programmers (like ZOOMRACKS) and system programmers (like ATARI or
DRI) stop taking short cuts on this fine machine (the ST) or its going to get
a bad name fast. I really hope both the HD 40 folder limit problem and the
ZOOMRACKS memory allocation problem are fixed soon.



Mike Winseck
..!inhp4!drutx!winseck
AT&T - Denver, CO.
303-538-3847