🚀 go-pugleaf

  Extensive apologys to all concerned for the length of this response!

  Konrad made several points in his response to my request for info
that I felt had to be answered....  I'm greatful for his work to provide
a fix to the 40 folder problem, but the fact that he has produced a
wonderful program does not give him the right to attack someone asking
questions about how that program works or to attack that person (me)
as being overly cautious when the documentation provided does little
to answer several significant points about how his program manages to
do things so far beyond what anyone else (including Atari) has been able
to do.

--------------------------

In article <8704162303.AA17594@ucbvax.Berkeley.EDU> XBR4D76H@DDATHD21.BITNET writes:
 >In Digest 161, Vol 87, dayton!viper!john@RUTGERS.EDU writes:
 >
 >> .....
 >>   3rd)  (And the PRIMARY reason) Is that nowhere in the message that came
 >> with the posting -OR- with the archive itself is there -any- explanation
 >> of "What GemBoot Does to the System"....  It says that it potentialy
 >> corrects "some" of the 40-folder problems, but it has -no- details about
 >> how it works or what functional changes are caused by running it in an
 >> AUTO folder...
 >> .....

  Well, ok...  I was wrong in one significant point...  There -is-, in
fact, an explanation.  It's not a very complete description, but it is
there.  My remaining comments then, -and- here, relate to the gaps in
the explanation that did exist.

 >
 >If you would have read a bit further than the first 4 lines of my posting
 >you could have extracted following how GEMBOOT works:
.............
 >2) It forces GEMDOS to build up a complete internal directory tree by
 >   scanning all directories on hard disk drives with Ffirst()-Fnext().
 >   The internal dir. blocks generated by this duo are errorfree and prevent
 >   GEMDOS from generating duplicates which overflowed the system memory
 >   formerly.

Yes, your msg did say that...  But the remainder of your explanation was
somewhat convoluted and vauge.  Since I posted my previous msg on this
topic, I have managed to make sense of the msg, but that information
could have been -much- clearer and should have been included in the
archive itself (as part of the documentation).

 >GEMBOOT does *not* modify any GEMDOS internal dir. blocks.

I also suspect it does *not* make coffee...  So what?  :)


 >After booting GEMBOOT stays resident only to prevent memory space for the
 >additional dir. blocks and the DESKTOP path buffer.

Why would you want to "prevent" memory space??
I suspect you mean "protect"...(?)

 >
 >BTW:
 >What could you say to someone who is afraid of using your posted programs
 >because of the risk of blowing his system ?
 >Nothing.
 >We all know of this risk using PD Software.
 >We weigh the goods against the risks and make our individual choice.
 >

  Oh come on now.  Just because Atari -and- Supra have been working on
this for a -long- time and have not come up with anything they can
release is reason enough IN-THIS-CASE!  Don't go trying to make someone
sound like a nut-case just because the biggies with lots of resources 
are unable to fix a problem and I'm cautious when someone claims to have 
found an answer but doesn't give a good explanation of how it works!

  Also, the first -text- lines in your .DOC file read:
-Warning:  Most programs in this archive uses TOSinternal memory addresses.
-#######   These addresses are based on the *german* ROM-TOS and may be
-          incompatible to the US version.

  With a disclaimer like that in the file, I'd have to be a nut-case if
I wasn't a bit more cautious than with a "normal" PD program.  (Normal:
one that does things in a clear-cut, non-cheating manner...)  Yes, there
is such a thing as being too cautious, but I don't think waiting to see
if other users have problems and publicly asking questions to better
understand what the program does fits into that category...  Do you?

 >If you can live with the permanent system crashs and the 40 folder limit
 >leave it.
 >If not try GEMBOOT.

No, I don't like the problems any more than the next guy.  I'll probably
try GemBoot sometime soon.  The only reason I can think of for not using
it is the excess memory it takes up....  Have you considered modifying it
to just reserve the space necessary for the additional buffers and freeing 
up the space taken by the GemBoot program itself?

 >But please don't write comments on a program you haven't tested nor even
 >read its description entirely.

  I did read (and re-re-re-re-read) your descriptions.  The questions
they prompted appeared to not have any answers provided.  Appon later
later re-examination, your explanation finaly made sense, but it's not 
a good idea to attack someone when the failing might lie in your
documentation...  Since nobody else responded to my request for further
information, I strongly suspect I'm not the only one who had trouble
making sense out of your "explanation".

 >  Konrad A. Hahn
 >  Dept. of Computer Science @ Techn. University Darmstadt, W.-Germany
 >  BITNET: XBR4D76H@DDATHD21

--- 
John Stanley (john@viper.UUCP)
Software Consultant - DynaSoft Systems
UUCP: ...{amdahl,ihnp4,rutgers}!{meccts,dayton}!viper!john