Letters

MacTutor Editorial

Multi-Finder Changes the Game

The arrival of Multi-Finder changes the game for tool makers in the Macintosh world. When the Mac first came out, the emphasis was on one tool, one job. Consulair C and TML Pascal followed this design philosophy by making their compiler products seperate tools. There was the editor tool, the compiler tool, the linker tool and so forth. Using switcher, these tools could be used very easily, switching back and forth between them. After a while, this mode of operation fell out of favor as new system enhancements made switcher unreliable. This led to the creation of the “all-in-one” environment of LS C and Pascal and the MPW shell. In these products, the tools are not seperate anymore, but integrated with the shell environment of the tool maker. These products have become very popular. This change in thinking has also affected application development. With Pagemaker, the tools for creating layouts were unbundled and seperate. You use a word processor to create text, a drawing program to create graphics, and a layout tool like Pagemaker for combining and creating layouts, using the files created by the other tools. Lately, however, there has been a movement to return to the large, integrated tool, that does both word processing, graphics and layout in one. Microsoft Word has expanded into page layout, FullWrite is supposed to rival Pagemaker, Scoop combines an editor, Paint and Draw program with it’s layout capabilities. The result of this is that applications are bigger, more complicated and attempt to do all things for all people. This also makes them harder to debug, so that products like FullWrite and Scoop run over their ship dates by six months or more, and products like MS Word ship with bugs, causing a furor in the marketplace.

In the new world created by Multi-Finder, these integrated environments are the exact opposite of what we want today. Multi-Finder gives the user the opportunity to create his own integrated working environment, by mixing and matching the tools he wants open at any one time. The integrated environments prevent this by either not working at all with Multi-Finder, or by being so big and massive as to make their use under Multi-Finder impossible without five megabytes of memory!

The New Way of Tool Design

To take full advantage of the new Multi-Finder way of doing things, tools should go back to the old adage “keep it simple, stupid!”. One tool for one job is our motto. And each tool should have a re-sizable, dragable window because Multi-Finder operates best with normal windows. By clicking in the tool’s window, that tool is immediately activated. The user can then open the tools he wants and arrange their windows on the screen or screens at his disposal. Also, tools should confine their controls to their own window, rather than blasting a control all over the screen (as in WriteNow’s ruler). Normal, scrolling windows should be supported rather than fixed dialog boxes (as in Absoft’s Fortran). Windows should be moveable rather than fixed (as in Apple’s MacPaint). MacTutor encourages tool makers, both applications and programming products, to return to the idea of simple, reliable, one purpose tool making, each tool in it’s own window. Lets concentrate on creating tool families that can share information easily and painlessly in the new Multi-Finder environment.

Apple Defines the User Interface

Apple has published a new book with Addison-Wesley that defines the user interface for Macintosh type computers. Because Apple is trying to port the Mac look and feel back to their Apple IIgs, the name of the book is Human Interface Guidelines: The Apple Desktop Interface. But in reality, this is a complete, single volume statement of how a Macintosh application should look and feel to the user. The book contains descriptions of the look and feel associated with such new topics as tear off menus, pop-up menus and hierarchical menus. What is not in the book, and is needed, is some idea on how the user interface the book describes can be implemented! (I’m thinking of writing a little booklet that would implement the user interface as Apple describes it as the Pascal shell example they left out!) Also missing is some discussion of the philosophy of tool design as I’ve indicated in this editorial, now that Multi-Finder allows multiple active tools to be sitting around on the desktop. Tools need to be designed in such a way that they can be confined by the user if he wants to push that tool off to the side of the screen somewhere. Also missing from the book is a discussion of tool design for Apple Share, and what constraints that environment puts on good programming practice. Perhaps we need a volume 2 of the Apple Desktop Interface: The Developer’s Perspective. Human Interface Guidelines is part of the Apple Technical Library Series from Addison-Wesley and should be available at the MacWorld Expo in San Francisco. A must purchase for developers.

Colorizer Fixes Color Problems

Last month, we said you can’t take a snapshot of the color screen. The Colorizer cDev from Palomar Software does allow you to capture a color screen and to save it as a color PICT. Eventually the graphics programs will get updated to work with color PICTS so this will be very useful. A new version, 1.1 is now shipping and we recommend this product if you have a Mac II. Colorizer is a utility that adds colors to PICT compatible objects, allowing you to colorize MacDraw and other object oriented documents. See the mail order store in this issue, or contact them directly at (619) 727-3922.

WriteNow Cures Pagemaker Problems with MacWrite Formatted Files

As we have reported previously, the file filter in Pagemaker for MacWrite formatted files is buggy and often fails to place the file correctly. A dialog box comes up and says “you’ve used fonts not in your system file” and so forth. This problem has been a pain for us since we normally use MacWrite as our “galley editor” tool. This gives me a chance to again rant and rave about how we need tools for specific jobs.

In setting a magazine every month, you don’t need or want the world’s most comprehensive word processor. All that stuff just gets in your way. All you really need is a “galley editor”. Such a product need only set the column width, leading, font, style and tabs for creating galley strips of editorial. But it must be fast, and bomb proof. Those strips are then typeset into magazine columns with a page layout program like Pagemaker. It is much more efficent to keep these two tasks seperate. But Pagemaker has to be able to read a formatted file and version 2.0 can’t do this reliably with MacWrite. So we have switched from MacWrite to WriteNow by T/Maker and NeXT, which apparently owns the copyright. All the editorial in MacTutor is now set up with WriteNow. A translator program allows MacWrite and Word files to be translated into formatted WriteNow files. (The translator seems to have problems with Word 3.01, but you can save word files as MacWrite files, and the translator can convert those to WriteNow files.)

WriteNow is an excellent example of what I mean by a “galley editor”. It is simple, fast and obvious, like MacWrite, only better. It conforms to the new tool design philosophy by doing one thing well, like Filemaker. In fact, I think of it as the “Filemaker of word processors”. (The only drawback is that it’s ruler is not confined to a window as it should be to be truly Multi-Finder friendly.) The ability to set the leading and check the spelling in WriteNow, and have that leading respected by Pagemaker is what makes this tool so great for use with Pagemaker. As we have reported before, leading is a design goof in Pagemaker that can waste a lof of time trying to re-set the results of the auto leading calculation.

What I really like about WriteNow is that it follows the user interface in an obvious and simple way, unlike MS Word, which tries to go out of it’s way to be obnoxious. A simple example: you can set bold face type by pressing command-B, which should be obvious. But Pagemaker requires you to press shift-cmd-B, which is a physical impossibility for most normal people. I asked them why they did that and they said “because MS Word does!”. Obviously, they never tested their own interface. Another example: fonts and style are easily changed, both globally and locally, without the pain of a messy dialog box like MS Word and Pagemaker require. And the built-in spell checking is so easy and fast that even I can use it! (No more letters on MacTutor’s spelling problems!)

So if your looking for a good galley editor for Pagemaker, take a took at WriteNow. It has multiple windows, spell checking, leading, and simplicity. Once more, it’s file filter for Pagemaker works correctly. If you write for MacTutor and have WriteNow, please submit articles as WriteNow files instead of MacWrite files, although we can easily convert them. Contact T/Maker at (415) 962-0195. Current version shipping is 1.07, although I am using 1.0 on a Mac II with no problems.

Big Arrays for LS Pascal?

Noel Godlsmith

In the September issue of MacTutor, you published an article by Daryl Lovato on how he creates large arrays in TML Pascal (getting around the 32K limitation of the segment loader). I’ve tried everything and I can’t get this example to work in LS Pascal. I’ve written to Think also to ask them about this.

[The following unit will demonstrate how to create large arrays in LS Pascal following Lovato’s example. LS is very picky about things, especially handles, but the big problem seems to be that the address returned for a locked handle is not the correct address at all, but includes the lock bit, which currently is stored in the handle itself. To get the correct address, you have to clear the high order bit. In the SetElement routine, you need something like the following:

 MoveHHI(handle(mystuff));  
 HLock(handle(mystuff));  
 baseAddress := Ord4(@mystuff^^.dataStuff);
 BitClr(@baseAddress, 0); {clear lock bit}
 cellAddr:=fakePtr(baseAddress+(elemNum*mystuff^^.cellSize)); myPtr := 
fakePtr(elemPtr); 
 FOR i := 0 TO mystuff^^.cellSize - 1 DO 
 cellAddr^[i] := myPtr^[i]; 

This unit was set up to be used with the Pascal Code Tester that Jeff Fox wrote for us last month. If you add this unit to his program, and call GetBigArray in the test routine, then you can see the results of this unit. Note how the output is stuffed into the TextEdit record using TEInsert, where it will display with the next update event. Also, please be aware that the current version of LS Pascal is 1.11 and that this works (nearly) with the Mac II and provides the Volume 5 interfaces (still some bugs with the color video card turned on, switching context between the appl. and LS shell.) -Ed]

UNIT arrayStuff; 

INTERFACE 

 USES   ROM85, TestGlobals; 
 
FUNCTION CreateNewArray(elemSize,upperBound:Longint):Handle;
PROCEDURE SetElement(ary:Handle; elemNum: Longint;             elemPtr:Ptr); 

FUNCTION GetElement(ary:Handle; elemNum:Longint):Ptr; PROCEDURE GetBigArray; 


IMPLEMENTATION 

 TYPE   
 ArrayHdl = ^ArrayPtr;    
 ArrayPtr = ^ArrayRec;    
 ArrayRec = RECORD 
 hiBound: integer; 
 cellSize:  Longint; 
 dataStuff: integer;
 END; 

FUNCTION CreateNewArray;

VAR     
 tempHdl : ArrayHdl; 
BEGIN   
 tempHdl := ArrayHdl(NewHandle(Ord4(SizeOf(ArrayRec)) - 2 +    
 ((upperbound + 1) * elemSize)));  
 MoveHHI(handle(tempHdl));  
 HLock(handle(tempHdl));  
 WITH tempHdl^^ DO 
 BEGIN  
 hiBound := upperBound; 
 cellSize := elemSize;    
 END;   
 CreateNewArray := Handle(tempHdl);  
 HUnlock(handle(tempHdl));  
END; 
 
PROCEDURE SetElement;
 
TYPE    
 fakeary = PACKED ARRAY[1..10000] OF signedbyte;   
 fakeptr = ^fakeary; 
 
VAR     
 baseAddress : LongInt;   
 cellAddr, myPtr : fakePtr; 
 i : integer;    
 mystuff : ArrayHdl; 

BEGIN   
 mystuff := ArrayHdl(ary);  
 MoveHHI(handle(mystuff));  
 HLock(handle(mystuff));  
 IF (elemNum > 0) AND (elemNum < mystuff^^.hibound) THEN 
 BEGIN  
 baseAddress := Ord4(@mystuff^^.dataStuff);                    BitClr(@baseAddress, 
0);     
 cellAddr := fakePtr(baseAddress+(elemNum *                    
 mystuff^^.cellSize));    
 myPtr := fakePtr(elemPtr); 
 FOR i := 0 TO mystuff^^.cellSize - 1 DO 
 cellAddr^[i] := myPtr^[i]; 
 END;   
 HUnlock(handle(mystuff));  
END; 
 
FUNCTION GetElement; 
VAR     
 mystuff : ArrayHdl; 
 baseAddress : LongInt;   
 size : LongInt; 

BEGIN   
 mystuff := ArrayHdl(ary);  
 MoveHHI(handle(mystuff));  
 HLock(handle(mystuff));  
 baseAddress := Ord4(@mystuff^^.dataStuff);  
 BitClr(@baseAddress, 0); 
 size := mystuff^^.cellSize;  
 IF (elemNum > 0) AND (elemNum < mystuff^^.hibound) THEN       
 GetElement := Pointer(baseAddress + (elemNum * size));        HUnlock(handle(mystuff)); 
 
END; 
 
PROCEDURE GetBigArray;
 
TYPE    
 BigPtr = ^BigRec; 
 BigRec = RECORD 
 r : real;  
 r2 : real; 
 other : ARRAY[1..20] OF Longint;  
 END; 
 
VAR     
 myArray : handle; 
 i : longint;    
 Big : BigRec;   
 ValuePtr : BigPtr;  
 Value : real;   
 str0, str1, str2 : str255; 
 number : longint; 
BEGIN   
 myArray := CreateNewArray(SizeOf(BigRec), 2000); 
 str0 := chr(13);  
 str1 := ‘Total Size of Record = ‘;  
 number := SizeOf(BigRec);  
 NumToString(number, str2); 
 str1 := concat(str1, str2);  
 TEInsert(pointer(ORD(@str0) + 1), 1, JeffsText);  
 TEInsert(pointer(ORD(@str1) + 1), length(str1), JeffsText); 
 str1 := ‘Total Size of the array = ‘;
 number := GetHandleSize(myArray); 
 NumToString(number, str2); 
 str1 := concat(str1, str2);  
 TEInsert(pointer(ORD(@str0) + 1), 1, JeffsText); 
 TEInsert(pointer(ORD(@str1) + 1), length(str1), JeffsText);   
 TEInsert(pointer(ORD(@str0) + 1), 1, JeffsText)   
 FOR i := 1 TO 2000 DO    
 BEGIN  
 Big.r := i / 1.0; 
 SetElement(myArray, i, @Big);     
 ValuePtr := BigPtr(GetElement(myArray, i));
 value := valuePtr^.r;    
 str1 := StringOf(value : 7 : 2);  
 IF (i > 500) AND (i < 519) THEN 
 BEGIN  
 TEInsert(pointer(ORD(@str0) + 1), 1, JeffsText);              
 TEInsert(pointer(ORD(@str1) + 1), length(str1),               
 JeffsText);     
 END;   
 END;   
 DisposHandle(myArray); 
END; 
END.

LaserWriter EEPROM Behavior

Herb Weiner

The following information relates to the item “LaserWriters Self-Destruct after One or Two Years!” on page 85 of the October MacTutor: It’s actually rather simple to “reset” the LaserWriter EEPROM, including the page counter: replacing the Version 23.0 PostScript (original LaserWriter Version 1.0) ROMs with Version 38.0 PostScript (LaserWriter Plus or LaserWriter Version 2.0) ROMs or vice versa resets the EEPROM, including all non-volatile parameters, the page counter, and the printer serial number used by the protected versions of the Adobe downloadable fonts. This is the reason that the page counter in early LaserWriters was reset to zero when they were upgraded to a LaserWriter Plus, but that the page counter in a newer LaserWriter (with Version 38.0 PostScript) is not reset by this upgrade. (I don’t know how the most recent version of PostScript behaves.)

The number at the lower left corner of the line graph on the startup page (1.0 or 2.0) indicates which version of the ROMs you have. If you have the old ROMs and your LaserWriter dies due to bad data in your EEPROM, perhaps you can persuade a sympathetic dealer to insert new ROMs long enough to power up the machine and reset the EEPROM. Alternatively, perhaps you’d rather spend the $800 on a LaserWriter Plus upgrade than a board swap! Note that this approach will work only if the problem with the EEPROM is bad data; if the EEPROM has physically gone bad, you can’t cure it by reprogramming. Each location in an EEPROM can be written only a limited number of times before it goes bad, at which point the EEPROM would need to be replaced. (I suspect you could unsolder and replace the defective EEPROM, which the software might then reprogram upon power up, but have never investigated this suspicion.)

I suspect it is somewhat unfair to blame Apple for the behavior of the EEPROM. PostScript is, after all, implemented by Adobe. It is my understanding that Adobe does not even provide source code to Apple. Perhaps I could expand this into an Article. (I am the author of the software for both LaserMagic™ and MacScan™)

CDEV Notes

Robert Rossevelt

Thanks to your recent articles about the new control panel and ‘cdev’ files, I have been doing some experimenting and have discovered the following (possibly trivial) facts which have not, as far as I know, appeared in print.

The control panel maintains a resource of type ‘clst’ in the System File. This resource contains information about the various cdev’s in the System Folder. In particular, it contains a copy of each cdev’s ICN# resource, which is distinct from the ICN# stored in the cdev’s file. This means that if you change the ICN# in the cdev file, the change doesn’t show up when you open the control panel.

However, if you hold down the command and option keys when opening the control panel, it will rebuild the ‘clst’ resource from scratch, thereby incorporating your icon changes. This procedure is distinct from holding Command-Option-Shift, which on some machines, resets the PRAM memory as well as rebuilding the ‘clst’.

Remember that you’ll also have to inform the DeskTop file about your changes if you want them to show up there. Note that the Chooser maintains a ‘clst’ of its own; presumably it serves the same purpose there as well. Thanks for an informative and useful magazine.

Foreign View of Developers

Charles Dyer

One thing I really don’t like about shareware is when someone writes a shareware product and deliberately cripples it so that you have to send in the fee in order to get the ‘secret’ command to uncripple it, and then the author cashes your check but doesn’t bother to send you word one! Over the last two months, I’ve sent in two checks for useful shareware DA’s to people who did just that. Most people that I send shareware checks to break their necks getting back to me; these two don’t seem to be in any hurry.

I note that you don’t seem particularly interested in Modula-2 any more. I plan on getting either Semper Modula-2 or TML Modula-2. Right now, I’m leaning strongly towards Semper, mostly because it’ll work out cheaper for me and they bundle MPW in and ship for free. TML had the best shot, because Florida’s a lot closer, and cheaper to get at, than Illinois, but they don’t seem to like to answer letters there. If they don’t respond to my letters when I’m offering them money, how will they respond later on if I have a problem, and after I’ve given them my money?

The same kind of thing afflicts hard drive manufacturers. I’ve written at least a dozen and the only replies that I’ve received are from Jasmine, Warp Nie, and Relax. The others don’t seem to want my money. Maybe it’s my breath. Ah well. Enough moaning. I like your magazine. If you need someone to look at Modula-2 again, I’m available. [Developer’s, let’s be kind to our overseas friends. And yes, we are interested in Modula-2, but TML never sent me a Modula-2 compiler either, so -Ed]

68010 Rumor Mil

Gary Odom

The October issue of MacTutor had a Mousehole report that the 68010 chip, being pin-compatible with the 68000 could be put into a Mac (with no change in clock speed) and an “about 30%” speed increase would ensue. Scoth that rumor! A 30% speed increase is nothing to sneeze at, especially for a $50 chip you just slap in, but it just isn’t so.

I have an early Moster Mac (one where they rip the 68000 heart out, stick voodoo pins in the motherboard, and place the CPU on the “little beast”). I did some benchmarks with the 68000, then popped in a 68010 and ran the same tests. I found no difference when loading a MacDraw document or doing a Mac C compile from RamDisk. The Mac C Sieve with register integer math showed only a 3.6% improvement, and the floating point tests actually were 5% slower!

The 68010 has special “loop mode” instructions that are supposed to make for more effiecient processing in program loop situtations. This may account for the speed improvement in the register integer math benchmark. Why is the floating point slower? I don’t know. Perhaps Sane?

The Motorola 68000 Programer’s Reference manual has some instruction execution times (in clock cycles) for both the 68000 and 68010. The only significant difference is in the multiply and divide instructions, where the 68010 is about 30% faster in clock cycles. That may be how the rumor was started.

Debugger Art Work

Tim Hammett

Put your Mac II into 256 colour mode, double click on the MacsBug 5.4 icon, and watch the show! [This little note intrigued me, so I tried it. MacsBug 5.4 displays a color fractal that increases in resolution the longer it runs.]

Key Bug in System 4.1 fixed in 4.2

Neville Smythe

There is an error in one of the keyboard mapping resources in the System file 4.1, which is fixed in the new System file 4.2, which will not allow the characters A-tilde and O-tilde to be accessed from the keyboard. They are supposed to be obtained by pressing option-n A and option-n O respectively. The lower case characters work, as in ã and õ, but the upper case do not under system 4.1. This is a real problem since in the Symbol font, option-n A and option-n O are the heavily used ‘contained in’ characters, Ã and Õ. As you can see, under System 4.2, this apparently has been fixed, since I am now able to display them.

Custom Text Edit Project

Clifford Story

I’m working on a project to replace TextEdit with custom editing routines. Would you like an article on this subject? [Yes, we’ve been after a TextEdit replacement for over a year! -Ed]