trb@stag.UUCP (04/01/87)
Simon,
Just to clear up a comment you made in your last post, HDSCAN shouldn't
really be affected by the 40 folder limit (I don't do any sfirst, snext stuff
in the program...just cluster tracing using rwabs and then only doing reads...
so it should be pretty hard to grunge a hard disk using hdscan.) I do do some
memory allocating, but the only gemdos calls I use are related to file renaming
and checking free space on drives A and B. Please let me know if anyone does
find a problem HDSCAN, however...I only have used it on the Atari 20 meg and
the Supra 10, 20, and 30 meg drives...
-Todd {...meccts!zeke!stag!trb}K538915@CZHRZU1A.BITNET.UUCP (04/04/87)
Todd, you're naturally right, it was not the 40 folder bug causing HDSCAN
to blow up (it just happend at a folder count which made it seem likely).
The problem is/was HDSCAN trying to read from a non-existant ram-disk.
It seems as if a reset doesn't reset the drvbit vector........
BTW has anybody besides myself actually tried GEMBOOT.PRG? It works
VERY well, but I'm slightly supprised that there seems to be a great
lack of enthusiasm about this program. Konrad THANKS A LOT!
Simonbraner@batcomputer.UUCP (04/04/87)
[] Some things I don't understand about the "40-folders" bug (should be called something else by now!): Is calling the GEMDOS function Dfree() a possible danger? (Does that cause reading subdirectories, or does it simply read the FAT and count bits?) Is repeated use of a program that uses dynamically-allocated RAM (e.g. micro- EMACS) a danger? I.e., when the program quits, are the blocks used for keeping track of Malloc()ed RAM completely freed in the infamous, fixed- size, system tables? (Even if your compiler minimizes Malloc() calls by Malloc-ing in big chunks and then malloc-ing out of it, it has to call Malloc() at least once.) - Moshe Braner PS: could somebody send me "unshar" for the ST, or some other method for easy transfer of many small files from a UNIX system to the ST? Thanks. PPS: still looking for a GEM metafile --> Postscript translator.
john@viper.UUCP (04/05/87)
In article <8704040134.AA06662@ucbvax.Berkeley.EDU> K538915@CZHRZU1A.BITNET writes: > >BTW has anybody besides myself actually tried GEMBOOT.PRG? It works >VERY well, but I'm slightly supprised that there seems to be a great >lack of enthusiasm about this program. Konrad THANKS A LOT! > > Simon Simon, I for one have not used the GEMBOOT program for three major reasons...: 1) When it was posted, there were no sources given. This isn't that unusual, but for something this important along with reason (2), I'll wait a bit longer before I try it. 2) Only one or two people have said anything about it seeming to work. Since I use my machine on a daily basis for work, I can't afford experimenting with programs with -potentialy- disasterous side effects. (NOTE: I'm -NOT- saying GEMBOOT has -any- problems at-all...! I'm only saying that as far as I can tell, there hasn't been enough use for me to feel safe using it...) 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... Until I have a good idea what a program is going to do, and that includes ANY program not just GemBoot, I'm not likely to take chances running my own development software on a system which has been modified in totaly-unspecified ways. If GemBoot does work, I see no reason for Konrad to keep the workings of how it does whaever-it-does a TOTAL secret. I have no objections about his keeping the sources to himself, but I'd sure like to have some idea of what he thinks he's doing to my system before I try it... --- BTW: Konrad (sp?), I would be -very- interested in seeing the source (or at least some data-structures + locations information) for the two programs you included along with GemBoot. Those being GEMMEM and GEMDIR. I have a few system-status indicators I have running on my sytem just to keep track of things that effect it's performance and the two tables (memory blocks & directory block cache) would be nice additions... Any objections to sharing those two with the ST community? --- John Stanley (john@viper.UUCP) Software Consultant - DynaSoft Systems UUCP: ...{amdahl,ihnp4,rutgers}!{meccts,dayton}!viper!john
mdoerr@uklirb.UUCP (04/06/87)
See my previous response concerning that GEM-Metafile to PostScript converter. Michael
at@laura.UUCP (04/06/87)
I've tested GEMBOOT.PRG well and found no problems at all. (Test with 180! folders on one partition) Gemboot.prg scans the HD and creates some extra directory space for each folder found. This additional space is linked with the existing 3K space in the gemdos data area. This means that the 40 (60-80?) folder limit is still active but all of your HD folders won't count. I've tested GEMBOOT.PRG with the following software: MWC system, Cambridge Lisp, lots of TOS games (infocom, hack ..), Silent service, Hex .... without any problems! For the curious: A german company (sorry forgot who) sells a similar product for ~40$. Their program creates space for about 900 folders. Andreas Toenne CS Dept., IRB University of Dortmund, W-Germany at@unido.uucp ...!seismo!unido!at at@unido.bitnet D
tony@wldrdg.UUCP (04/06/87)
> In article <8704040134.AA06662@ucbvax.Berkeley.EDU> K538915@CZHRZU1A.BITNET writes: > >BTW has anybody besides myself actually tried GEMBOOT.PRG? It works > >VERY well, but I'm slightly supprised that there seems to be a great > >lack of enthusiasm about this program. Konrad THANKS A LOT! > > Simon > Simon, > I for one have not used the GEMBOOT program for three major reasons...: [various sensible reasons given for not using gemboot...] > John Stanley (john@viper.UUCP) > Software Consultant - DynaSoft Systems > UUCP: ...{amdahl,ihnp4,rutgers}!{meccts,dayton}!viper!john After finally giving up on waiting for Atari's fix I bit the bullet this weekend and hacked around on my hard disk. I made a full backup and installed the hard disk auto-booting code that was posted to the net a while ago. That seemed to work okay. Then last night I started using gemboot and re-organized my disk in a more reasonable fashion making lots of subdirectories. I'm up to 61 folders on my hard disk between two partitions and so far haven't had any trouble. I'm going to make backups very often for a while until I build more confidence in gemboot, and I'll certainly report any trouble to the net. I *REALLY* wanted to wait and use Atari's program to relieve the 40 folder limit, but after months of empty promises I had to do something. So the question remains... when is Atari going to release their fix. It's been in testing for a long time now. I can understand their caution with something like this but the program was supposed to be available some time ago. Tony Andrews Wildridge Consulting, Inc. Boulder, CO ...!ihnp4!onecom!wldrdg!tony
axel@coma.UUCP (04/08/87)
/***** coma:comp.sys.at.st / ucbvax!K538915 / 3:25 am Apr 4, 1987*/ >... >BTW has anybody besides myself actually tried GEMBOOT.PRG? It works >VERY well, but I'm slightly supprised that there seems to be a great >lack of enthusiasm about this program. Konrad THANKS A LOT! > No Simon, you're not the only one using GEMBOOT.PRG. Three days ago a completely enthusiastic collegue of mine dropped in my room and immediateley installed the program on my ST. Obviously I'm not the only one who almost missed out on this gadget. Looks like the 40 folder problem is solved (i.e. pushed outasite) after all, doesn't it? The question that came to my mind when I realized this was: why didn't Atari supply the ST user community with such a program a long time ago ? Boy - are they gonna be flamed ! axel@coma.uucp
XBR4D76H@DDATHD21.BITNET.UUCP (04/17/87)
Received: from BR4.THD.DA.D.EUROPE by DDATHD21.BITNET
via GNET with RJE ; 17 Apr 87 01:00:05
Date: Fri, 17 Apr 87 00:55:08 +0200 (Central European Sommer Time)
From: XBR4D76H@DDATHD21.BITNET
Subject: Re:Re: HDSCAN (and GEMBOOT.PRG)
To: info-atari16@score.stanford.edu
X-VMS-To: X%"info-atari16@score.stanford.edu"
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...
> .....
If you would have read a bit further than the first 4 lines of my posting
you could have extracted following how GEMBOOT works:
1) It adds 300 system blocks to the free lists.
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.
GEMBOOT does *not* modify any GEMDOS internal dir. blocks.
After booting GEMBOOT stays resident only to prevent memory space for the
additional dir. blocks and the DESKTOP path buffer.
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.
If you can live with the permanent system crashs and the 40 folder limit
leave it.
If not try GEMBOOT.
But please don't write comments on a program you haven't tested nor even
read its description entirely.
Konrad A. Hahn
Dept. of Computer Science @ Techn. University Darmstadt, W.-Germany
BITNET: XBR4D76H@DDATHD21XBR4D76H@DDATHD21.BITNET.UUCP (04/17/87)
Received: from BR4.THD.DA.D.EUROPE by DDATHD21.BITNET
via GNET with RJE ; 17 Apr 87 20:52:31
Date: Fri, 17 Apr 87 20:47:11 +0200 (Central European Sommer Time)
From: XBR4D76H@DDATHD21.BITNET
Subject: Re:Re: HDSCAN (and GEMBOOT.PRG)
To: info-atari16@score.stanford.edu
X-VMS-To: X%"info-atari16@score.stanford.edu"
Oooops, my last posting has a change by mistake due to similar sounds.
Sorry, but English isn't my mother tongue.
It should be
.... *provide* memory space ....
instead of
.... prevent memory space ....
Konrad
"Sure we make mistakes. But we find them before our customers do !"john@viper.UUCP (John Stanley) (04/19/87)
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