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 Multifinder, 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 gathered 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 Multifinder, 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:

<Number of Frames: Int>
<Frame counter: Int> 
[repeat n times:<CURS ID:Int> <Filler:Int>]

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 anything as far as the user is concerned. It is just as bad as using hardware blinking on terminals connected to minicomputers or mainframes with a message that such and such is happening. I’ve seen people wait hours on a dead program in situations like that.

From: dumacker (John Vinje)

Subject: Word Perfect

I just ordered the “betaware” copy of Word Perfect after reading an article in a recent Infoworld. For $99.00 you can get the beta copy and docs. When WPC releases the final product in March you will get the full (395.00) product without any fee! So far WPC boasts the Mac version will have data compatibility with its MS-DOS counterpart, be able to import MacWrite and hopefully WORD files. It will have a 110,000 word speller and thesaurus. If you would like to see if the gamble pays off, call 1-800-222-9409. According to the people I know, Word Perfect is the S.O.T.A. Word Processor for the MSDos’ers.

From: mysteray (Raymond Weisling)

Subject: SE fan upgrade

I read that the “noisy fan” in the SE can be swapped out now, and that Apple will be charging $90 for it. That seems rather expensive to correct THEIR mistake. Ooops, if its just noisy, then its YOUR problem, you have a thing about noise, that’s all, and you can pay to get it fixed. That must be their reasoning.

B.U.T... nobody mentioned the screen wobble or swim. I hate it more than the noise, actually. If it was reported in this light then Apple would look a bit worse and may even look foolish charging so much to cover their goof-up. [Their foolish! -Ed]

I’d like some feedback on this from SE owners/users who have the older fan. Do you have a noise problem or a jittery screen (left side)? or both??

A reply here or in my e-mailbox is fine. By the way, now that Apple has acted on this, it is time to seek a 3rd party solution that isn’t $90.

From: royh (Roy Hashimoto)

Subject: Dumping PostScript

Does anyone know how to get the Laserwriter driver to dump PostScript to a file instead of out the AppleTalk line? Is this an ‘official’ feature, or just a debugging back door? [It is an official feature; just press cmd-K after clicking OK at the print dialog. This dumps the postscript and the LaserPrep header to a file named ‘postscript0’. Cmd-F dumps without the LaserPrep header. Any cmd-K dump can later be sent via a postscript dumper utility and will print as expected. You can even edit the file as we demonstrated in a previous MacTutor, to get double column printing from data base programs that don’t know how to format in columns easily. -Ed]

From: mikesteiner (Mike Steiner)

Subject: FullWrite Pro eats memory

FWP really requires at least 2 megs (and more if you want to use it under MultiFinder). With a 1 meg Mac Plus, and TOPS active, there is not enough memory to even open a new document. With TOPS off, but with Suitcase active, there isn’t enough memory to handle all functions. I had a “not enough memory” message when I tried to reshape a bezier curve and when I tried to resize a graphic. This was with the demo version they gave away at Expo.

From: rickhyman (Richard Hyman)

Subject: Re: color Monitors

The latest issue of Byte has a nice article on multiscan monitors. It also does a nice job of describing the differences between all of the IBM video standards. Of all of the monitors tested, they described only a couple that came close to the Apple monitor abilities. The point to remember is that the Apple monitor is not multiscan; it is designed to run with the Mac video card, so the performance it provides over mutiscans is not surprising.

From: markg (Mark Guidarelli)

Subject: Color resource support...

Ok I have a question...has anyone seen a program that will allow the designing of color cursors, icons, pattern or control items? I have looked around and none are to be found. One would think that Apple would have added that to ResEdit by now, but the most recent version of it doesn’t support it. So unless one of you heroes out there has one or know of where I can get/buy(cheaply) one I’ll have to write one.... It wouldn’t be all that difficult but I would rather not re-invent the wheel (out of pure laziness). [What you describe is not available, but COLORIZER from Palomar Software, available from the MacTutor mail order store, is a useful color utility that has some of this capability. -Ed]

From: rguerra (Rich Guerra)

Subject: List Manager Question

I’ve been using LightSpeed Pascal to write an application that uses the List Manager. I create a list and draw it in a window. All functions (scroll bar tracking, highlighting, hit processing, etc.) are functional. A user double clicking on an item in this list causes another list to be created and drawn in the same place as the first, thus replacing it. This is where I run into a problem. This second list is functional in all ways save one: the scroll bar does not work. One can scroll the list by dragging the mouse, though with appropriate scroll bar tracking. I can even switch back to the original list which works perfectly. I know LClick is being called for clicks in the scroll bar of the second list. In fact, I create the second list exactly the same way as the first. This may be something obvious, but I’m at a loss. Any suggestions would be greatly appreciated.

I’ve tried the obvious things first:

The boundary rectangle for the second (and subsequent) list(s) includes the scroll bar (It is the same one that I used in the first list which works.) LClick does get called when I click on the non-functional scroll bar.

I turn drawing off on the first list [ LDoDraw(FALSE,FirstList); ] and also deactivate it [ LActivate(FALSE,FirstList); ] before swapping the second list into the display rectangle which is then activated and drawing set to true.

The lActive flag of the second (and subsequent) list(s) with a non-functional scroll bar is TRUE. The weird thing about this is that the scroll bar will track with the list when you drag on the items, still won’t work when you click on it, though. Also, when the first list is swapped back in, the scroll bar works perfectly again! [Sounds like you are not getting the proper control handle for the second list to your scrolling routine. -Ed]

From: jaff (Mark Jaffe)

Subject: Re: Linking Desk Acc with MPW C

Sonny: I had similar problems with a cdev in MPW. What’s happened is that you have some data that C puts into a DATA segment, and it’s trying to use a (nonexistent) INITIALIZATION code. You probably have a STR or some other data. Everything used by Stand alone code MUST come from resources. If you are writing a DA, they must be referenced from the DRVR refnum. Suggest you study some other DA code examples (try Art Browser DA) Good Luck!

From: dirck (Dirck Blaskey)

Subject: LSC libs

To whom it may concern at Think... (Rich?) the realloc/relalloc functions in storage.c are USELESS!

From: dirck (Dirck Blaskey)

Subject: LS C compiler bug

LightSpeedC generates two (2) ILLEGAL INSTRUCTIONS in the following code fragment: t() { register long d; int i; d |= i; d &= i; }

From: mark.chally (Mark Chally)

Subject: By the way..., Thin

(Rich) When can we expect each of the following?

1) LightspeedC with SOURCE LEVEL DEBUGGING. All lips were sealed at MacWorld Expo.

2) Lightspeed Pascal that doesn’t die a horrible death when “go”ing under MultiFinder.

3) Lightspeed Pascal that doesn’t tell you how to format your code, then make it unreadable when opened by another text editor. [Just set about 10 tabs and it will look the same under Edit as it does in LS. -Ed]

4) OPTIONAL COMPILER LISTINGS and printer on/off toggle for the text window. (Numbers three and four are because I have to use A FRIEND’S TURBO PASCAL to do my computer science projects!)

From: robh (Rob Humble)

Subject: LSC Printing

I just go LSC at the show, and for a beginning C hacker, its great. But, the first project I have in mind requires access to some of the printing toolbox calls, specifically PrValidate, which is part of the print record. In looking through the docs I got (v2.15) I can’t find any support for this. Am I wrong, is there a library that provides the support, or am I going to have to find another way to do what I want (determine the Chosen printer, a la Tech Note 72). [Printing support is now in the ROMs, rather than a separate linkable print interface. See the Feb. issue of MacTutor for a Pascal example of printing a quickdraw picture. -Ed]

From: mcoren (Michael Coren)

Subject: Consulair (lack of) support

I just received some disturbing news from Consulair’s Tech support number. At the present time (mid January), Consulair has “no plans” to update their MacC Jr. compiler for the new traps available in System 4.1 and the Mac II. The reason I was given was that MacC Jr. is sold as a “low end product, meant for learning C.” Funny, I seem to remember their advertising literature (i.e. ads in MacTutor) touting it as a full-featured Macintosh development system. I guess at $79, there isn’t enough profit in serving the user community. I ask the Macintosh programming community: Are we going to stand for this? I should think not, and I think Consulair should be reprimanded for their attitude.

From: arnoldw296 (Arnold Woodworth)

Subject: Re: Consulair (lack of) support

Consulair should either update Mac C Jr. or stop selling it. Selling Mac C Jr. without updating it will damage Consulair’s reputation. Someone who buys a new Mac SE (automatically getting Apple’s latest system software) and then buys Mac C Jr. will be unhappy after paying $79 for a compiler that doesn’t work on his machine. Especially after reading the advertisement. [Consulair seems to have lost some interest in the Mac market, much like TML did. -Ed]

From: the_cloud (Ken McLeod)

Subject: INIT icons II

I just heard that the code for placing an INIT’s icon on the screen in the lower-left corner at startup was placed into the public domain by its author, and people have been putting it to use, hence the proliferation of INITs that show icons. What is the “true story” here? Can anyone direct me to this code, if it exists?

From: lsr (Larry Rosenstein)

Subject: Re: INIT icons II

The code to do this is called ShowINIT, and was written by Paul Mercer (now of Apple Developer Tech Support). He just released a new version at MacWorld Expo, which is compatible with a future INIT 31 resource that will perform the same function. You can contact Paul at:

AppleLink: Mercer1

Delphi: PAULMERCER

CSNET: pmercer@Apple.COM

US Mail: P.O. Box 160165, Cupertino, CA 95016

From: lsr (Larry Rosenstein)

Subject: Re: Tear-Off Menus in LS

I already wrote a TMenu object type that implements custom menus easily. Instead of worrying about defprocs, you define a subclass of TMenu and implement a couple of methods. The code for this is available on the 1st MacApp Developer Association disk. It would be easy to so a similar object type to implement custom windows.

From: thought.police (William Evans)

Subject: ApplScratch

Did I read somewhere that they were taking ApplScratch (the 12 bytes of low-address global space which can be used by an application for anything it wants) from us, or is that my imagination? It’s probably my imagination, but if it isn’t, I don’t want to get bitten?

Any help in exorcising my hallucinations would be appreciated.

From: dorourke (David O’Rourke)

Subject: Re: ApplScratch

I’m not sure but from talking to a friend of mine at Apple you’re not having delusions of grandure and the low memory globals you talk about are there.

They were originally documented in the 3 ring binder version of Inside Macintosh but were dropped in the “published” version. So far I haven’t noticed any official reason not to use them, but you have to admit that’s just too good to be true and since they aren’t in the most recent version of Inside Mac I doubt Apple is going to support them in the future.

In fact I am guessing that Apple doesn’t support them now, since Multi-Finder does switch {so I’m told} some of the Low Memory between applications. You might have a problem if you’re running next to another application that uses those locations. It depends if MF switches and saves those for you, and if it does what happens if you try to access them while you’re application is in the background. All sorts of nasty problems are associated with things like this so I wouldn’t.

Now for some legend and some facts. Early versions of MicroSoft software reportedly used these locations to indicate if there had been a “key” disk inserted at an early time. Microsoft did this so that you only had to put the key disk in once, and then as long as you didn’t turn the computer off it would remember that the copy you were running off of was alright. Now we’re talking early Mac stuff here, when the 128K was the new kid on the block.

Now for the legend: Apple reportedly put those locations there at Microsoft’s request, and in fact in early 3 ring binder versions of inside Mac there are some locations that have references to Microsoft.

Disclaimer: None of this information is official and I have no formal ties with Apple. Information presented here is to relate what I know and have heard over the years. I also have no association with Microsoft and I do not speak for them, and the information regarding them is also undocumented.

From: cderossi (Chris Derossi)

Subject: Re: ApplScratch

ApplScratch is (briefly) documented in Inside Mac, page I-85. This reference does not give its location, but it does say that ApplScratch will be preserved across ROM calls.

It also warns that ApplScratch must only be used by applications. INITs, cdevs, DRVRs, MDEFs, etc can’t use this location. (MultiFinder must switch them across applications.)

From: jmunkki (Juri Munkki)

Helsinki University of Technology, Finland

Regions: The Real Story, a Technical Note

1. What We Thought We Knew

The May 1987 “ABC’s of C” and October 1987 “C Workshop” in MacTutor provide descriptions of the region data structure. Obviously the region structure is reserved by apple and subject to change without notice (it’s undocumented), but sometimes it’s just too slow to do things the way apple intended us to do them. For this reason (and debugging purposes) it is useful to be aware of the structure. Unfortunately the “ABC’s of C” article is not complete and the “C Workshop” gives slightly false information.

2. Conventions

In this note the structure I call the region is in fact the data that comes after the length word and size rectangle. The first 10 bytes are documented and are thus of no interest to us. While I’m on the subject of documentation, I might mention that the note in IM I-183 about the speed of OffSetRgn is misleading. None of the information in a region is stored in offset format and OffSetRgn is a relatively slow operation when the region is very complex.

3. What We Now Know

A region can be thought of as a collection of block descriptions, but each block is related to those above it. The block description starts with the smallest line coordinate included in the block and ends with a $7FFF. The words in between the start and end describe the difference between the current block and the one above it.

Let’s examine a union of two rectangles: 10,10-100,100 and 80,80-200,200. The first line would then contain 10, 10, 100, $7FFF. This means that the first block starts at y position 10 and the pixels between x 10 and 100 are included in the block. The block extends until the block below it starts. The following block describes the changes to be made in the previous block. The second block would then be: 80, 100, 200, $7FFF. This means that those pixels that were between 100 and 200 should be inverted starting from y position 80.

The next block would then tell us to remove pixels between x positions 10 and 80 starting from y position 100. It should look like this: 100, 10, 80, $7FFF. The last block of our region would then cancel the remaining pixels from the block: 200, 80, 200, $7FFF. Since it is the last block, an extra $7FFF is appended.

The complete region structure would look like this:

Data Y X Pixels set Block

10 10 100 $7FFF-> 10 10-100 Block 1

80 100 200 $7FFF-> 80 10-200 Block 2

100 10 80 $7FFF-> 100 80-200 Block 3

200 80 200 $7FFF-> 200 None Block 4

$7FFF

In hexadecimal:

000A, 000A, 0064, 7FFF, 0050, 0064, 00C8, 7FFF,

0064, 000A, 0050, 7FFF, 00C8, 0050, 00C8, 7FFF, 7FFF.