Mar 88 Mousehole
Volume Number: 4
Issue Number: 3
Column Tag: Mousehole Report
Mousehole Report 
By Rusty Hodge, Mousehole BBS
From: billr (Bill Rausch)
Subject: MacTutor article Bug
I just had a two page tech note printed in the January issue of MacTutor. It has an
error. The address of the EventRecord must also be passed to the routines doing the
event processing for the various window types. Sorry. Bill
From: jimr (Jim Reekes)
Subject: Finder problems
Is there a problem with the Finder or MultiFinder copying large amounts of files?
Reason I ask, I couldn’t copy my “Utils” folder that contained about 300 files (or
7.5MB) while running MultiFinder on a 4MB Mac II. It gives a message “Ran out of
memory....” I tried to reboot into the Finder, but the same folder caused a BOMB=01
error with the said folder. Had to copy it in smaller chunks.
From: jck (Jack Kobzeff)
Subject: copying files in MF
It does seem that running with MultiFinder sure can limit the number of files you can
copy. Even if there is no other program loaded, it looks like it can only use the memory
allocated for Finder. I’ve run into this even with a fairly small number of files, you
still get the ‘out of memory’ message. Whereas when running without MF, it copies
several times the number of files without a problem.
From: rick (Rick Boarman)
Subject: Re: Finder problems
I had many problems using MultiFinder and large folders until I allocated 512k for it
to use. After that, no more problems.
From: rusty (System Administrator)
Subject: Re: Finder problems
I’ve had a few ‘ran out of memory’ dialogs when trying to copy one hard disk to another
under MultiFinder. Re-starting without MultiFinder made it work fine.
From: lsr (Larry Rosenstein)
Subject: Re: copying files in MF
There was a discussion of this on Usenet. The Finder uses the MF temp memory
services for copying the files, but it has to use the Resource Manager to update the
desktop file. This is the place where the Finder can run out of memory.
The Finder also uses a fixed size (200K, I recall) buffer for the copying, unless the
copy involves removable media. Then it uses as much memory as it can grab to
minimize disk swapping. However, there is a limit of about 40 file forks that it can
copy in one pass, so if you copy a lot of files (or a lot of files with both a data and
resource fork) then there may be extra disk swapping.
From: mark.chally (Mark Chally)
Subject: Multifinder file copies
According to the MultiFinder Programmer’s Guide thing, the finder checks to see if
MultiFinder global pool type memory (I don’t remember the frigging terminology) is
free. It then allocates as much as needed/or as much as it can. If you don’t have any
spare memory outside of the finder area, maybe this can be a big problem. Some
programs can hog that other memory It also said that if you don’t have enough spare
outside memory to be allocated by Multi finder, the Finder uses a small, spare buffer of
its own. Don’t know about errors though--I haven’t had any problems--but I’m using
four megs too
From: jimr (Jim Reekes)
Subject: new desktop management
There is a ‘Desktop Manager’ that I’ve uploaded to the MHDL. It has been taken from
the Apple Share system folder. It is a MUCH faster method of keeping track of the
desktop while in the Finder/MultiFinder environment. Anyone that is using a 80MB
(or bigger) drive should put this file into their system folder and then reboot. After
that, you can delete the desktop file. It is no longer used by the Finder/MultiFinder.
The new method of desktop management is to use B trees instead of the resource
manager. This has already proven itself to me as a BIG improvement of the desktop’s
performance. Copying very large directories and lots of files only shows the “updating
desktop file...” message briefly. Returning to the Finder is also quicker. Only
drawback is that we can no longer unmount volumes by dragging the hard disk to the
trash. Small price to pay. (Anyone can get this file from the Apple Share disks)
[Why didn’t Apple distribute this file as part of the regular system 5.0 update if
it is such an obvious improvement? -Ed]
From: brett (Brett Bilbrey)
Subject: Ray Tracing update
Hi everyone, happy new year to you all...
I have been busy playing with Ray Tracing code for a while and have some very simple
code up and running. (For those of you keeping track, I’m still working on the
Pinichole game, I should finish before I die...) I’ve noticed some questions about
sources for information on Ray Tracing and the best that I have found so far is ACM
SIGGRAPH. IEEE has a few good articles too.
I would like to thank both Frank Henriquez and Steve Sheets for help in getting my code
up and running (examples, suggestions, ...)
I don’t really know what I’m going to do with the code when it starts to get fancy, but at
the moment I am trying to get things in shape for an article on Ray Tracing. Anyone
interested in exchanging information about ray tracing can contact me, I do have a list
of people to send stuff out to so if you already dropped me a note I will send out a listing
to you when it is slightly less buggy (OK, OK - WHEN I GET MIRRORED SURFACES TO
REFLECT RIGHT SIDE UP!!!).
I am trying to get together my list of references in filemaker. I have about 300
references to Ray Tracing articles.
What I am trying to get at is that I am acting like a clearing house at the moment
collecting information about Ray Tracing and will pass what I have ga thered back to
those who contribute. (Or send me sports cars. hee, hee)
From: dhill (David Hill)
Subject: multifinder Window Funnies
I found something interesting out about MultiFinder the other day. It will not put any of
your windows in the front until your application calls GetNextEvent(). I found this out
when I was calling SelectWindow() then ShowWindow() for my about window while
the program was booting up. But when it would run under Multi finder, the about
window would open behind the finder windows. The fix was to make a call to
GetNextEvent before opening the about window.
From: jimr (Jim Reekes)
Subject: Re: multifinder funnies
I also found this out while trying to open a window during the boot process. I was
using Dialog Manager calls. Until the program calls either GetNextEvent or
WaitNextEvent, the program’s layer doesn’t come to the front. Ever seen a modal
dialog in the background?
From: the_cloud (Ken McLeod)
Subject: ‘acur’ resource
Is Apple going to make the workings of the ‘acur’ (animated cursor) resource public?
I don’t see it mentioned in Inside Mac 5, but the latest ResEdit has a template for
it...hmm... It would be great to be able to use animated cursors in other programs than
the Finder! So...how ‘bout it?
From: rdclark (Richard Clark)
Subject: Animated Cursors
If you examine the Finder’s “acur” resource using ResEdit (some recent version),
you’ll see what the format is. But, to summarize:
[repeat n times: ]
Namely, a bunch of integers.
A typical entry would read:
Number of Frames: 2 (* This is a short one! *)
Frame counter : 0 (* typical *)
CURS ID : 128 (* First cursor *)
Filler : 0
CURS ID : 129 (* Second cursor *)
Filler : 0
Writing a program to use this information is left as an exercise to the reader
(although I may decide to do it myself some day...)
From: the_cloud (Ken McLeod)
Subject: Re: Animated Cursors
Thanks...actually I was hoping Apple had plans to implement this as a patch to
SetCursor or something (that is, on a lower level than my having to write it!) so that
if I set the cursor to one with an ID included in an ‘acur’ list, the animation would be
automatic...
From: cderossi (Chris Derossi)
Subject: Re: Animated Cursors
Animated cursors are meant to perform two functions. First, they show the user that
some lengthy process is underway, and he shouldn’t panic. Second, the movement shows
that the program hasn’t crashed. But actually, the watch cursor itself handles the first
requirement, so the animation is for the second reason.
This means that if you do the cursor animation as an interrupt process (like a VBL
task, as some do), your program can crash and the cursor will still animate. So in
order to use the animating cursor to show that the program is still alive, the program
itself has to make the call to animate it.
And since that call is just SetCursor, addition System support isn’t really needed.
Granted, the System could help you figure out which cursor was next, but that isn’t a
very hard calculation.
Each of Apple’s programs that animate the cursor (i.e. the Finder), do the work
themselves. The ‘acur’ resource is just a handy mechanism for getting all of the data in
a reasonable form.
From: the_cloud (Ken McLeod)
Subject: Re: Animated Cursors
You’re right, of course... I tend to think more thoroughly about these things after my
initial confused ramblings, but hey, I’m an impulsive poster. I do appreciate the
answers and discussion generated about things that aren’t necessarily documented
elsewhere. It seems to me that the way to implement animated cursors must involve
some sort of low-level installation, so that the repeated calls to SetCursor are
asynchronous (something like a call to SetSound, for example..strike
that..*StartSound*), and not just inserting a SetCursor(ID + 1) in every loop
(assuming I have a loop to work with). Perhaps this will become ridiculously clear the
moment I log off...
From: billr (Bill Rausch)
Subject: Re: Animated Cursors
Yes that is exactly what you do -> insert a SetCursor(nextID) into each and every place
in the program where you need it. As it turns out, making it into a separate function
SETCURSOR() isn’t very tough. I use C, and just made the whole thing into a macro.
Like Chris Derossi pointed out, setting it up as something automatic doesn’t accomplish
Referenced by (2):