Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!uwvax!umnd-cs!umn-cs!meccts!viper!john From: john@viper.UUCP (John Stanley) Newsgroups: comp.sys.atari.st Subject: Re: Re: HDSCAN (and GEMBOOT.PRG) (long reply) Message-ID: <865@viper.UUCP> Date: Sun, 19-Apr-87 02:41:56 EST Article-I.D.: viper.865 Posted: Sun Apr 19 02:41:56 1987 Date-Received: Sun, 19-Apr-87 17:56:59 EST References: <8704162303.AA17594@ucbvax.Berkeley.EDU> Reply-To: john@viper.UUCP (John Stanley) Distribution: world Organization: DynaSoft Systems Lines: 116 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