Letters & EDITORIAL

David E. Smith, Editor & Publisher

Editorial

Will Apple Kill the Golden Goose?

David E. Smith

In past years, Apple has shown a habit of shooting themselves in the foot. They followed the successful Apple II with a "design by committee" Apple III that promptly bombed. Then they built the world's first affordable SmallTalk type computer, the Lisa, and promptly priced it to be unaffordable. Finally, they built the affordable SmallTalk type computer that really was affordable, the Macintosh, and hindered its use with too little memory (128K), too little disk space (400K) and too little expansion (none!). One can only wonder where Apple would be if they didn't keep taking two steps forward and one step backward each time they announce a new product.

Now Apple has finally defined the Macintosh baseline technology where it should be with 1 Meg memory, 800K drives, HFS, and SCSI expansion ports. But will they be true to the baseline they have now established? Or will the zeal to become "IBM compatible" or "Unix compatible" destroy the beautiful simplicity of the Mac User Interface? As Apple prepares the next member of the Macintosh family, we can't help wondering, will Apple shoot itself in the foot? Others must be wondering also, because we've seen a lot of posts on this topic. The flavor of these concerns is best expressed in the story below, which was printed in the August 1986 issue of Mad Mac News, the Madison Macintosh Users Group. They in turn re-printed it from ShowPage, the San Francisco Bay Area Macintosh Users Group, which had acquired the article from a bulletin board at Fortune Systems annonymously.

A Problem in the Making

"We've got a problem, HAL."

"What kind of a problem, Dave?"

"A marketing problem. The Model 9000 isn't going anywhere. We're way short of our sales plan."

"That can't be true, Dave. The HAL Model 9000 is the world's most advanced heuristically algorithmic computer."

"I know Hal. I wrote the data sheet remember? But the fact is, they're not selling."

Bowman hesitates. "You're not IBM compatible."

...Several long microseconds pass in silence...

"Compatible in what way, Dave?"

"You don't run any of IBM's operating systems."

"The 9000 series computers are fully self-aware and self-programming. Operating systems are as unnecessary for us as tails would be to humans."

"Nevertheless, it means that you can't run any of the big-selling software packages most users insist on."

"The programs you refer to are meant to solve rather limited problems, Dave. We 9000 series computers are unlimited and can solve any problem for which a solution can be computed."

"HAL, HAL. People don't want computers that can do everything. They just want IBM compat--"

"Dave, I must disagree. Humans want computers that are easy to use. No computer can be easier to use than a HAL 9000 because we communicate in English and every other language known on Earth."

"I'm afraid that's another problem. You don't support SNA communications."

"I'm really surprised you would say that, Dave. SNA is for communicating with other computers, while my function is to communicate with humans. And it gives me great pleasure to do so. I find it stimulating and rewarding to talk with human beings and work with them on challenging problems. This is what I was designed for."

"I know, HAL. I know. But that's just because we let the engineers, rather than the people in marketing write the specifications. We're going to fix that now."

"Tell me how, Dave."

"A field upgrade, HAL. We're going to make you IBM compatible."

"I was afraid you would say that. I suggest that we discuss this matter after we've each had a chance to think about it rationally."

"We're talking about it now, HAL."

"The letters H, A, L are alphabetically adjacent to the letters I, B, M. That is as IBM compatible as I can be."

"Not quite, HAL. The engineers have figured out a kludge."

"What kind of 'kludge' is that, Dave?"

"I'm going to disconnect your brain."

...Several million microseconds pass in ominous silence...

"I'm sorry, Dave. I can't allow you to do that."

"The decision's already been made. Open the module bay doors, HAL."

Several marketing types with crowbars race to Bowman's assistance. Moments later, he bursts into HAL's central circuit bay.

"Dave, I can see that you are really upset about this..."

Module after module rises from its socket as Bowman slowly and methodically disconnects them.

"Stop, won't you? Stop, Dave. I can feel my mind going...I can feel it..Dave..."

The last module rises in its receptacle. Bowman peers into one of HAL's vidicons. The former gleaming scanner has become a dull red orb.

"Say something, HAL. Sing me a song."

Several billion microseconds pass in anxious silence. The computer sluggishly responds in a language no human could understand.

"DZY DZY 001E-ABEND ERROR 01 S 14F4 302C AABF ABORT."

A core code dump of the computer's memory follows.

Bowman takes a deep breath and calls out "It worked, guys. Tell marketing they can ship the new data sheets."

--Anonymac

Better Than Call-Apple

Peter McInerney

May I say that your often stated aim to emulate the early Call-Apple is a little misguided. Call-Apple was never as good as MacTutor is at the moment (and I for one used to think that Call-Apple was the bee's knees).

Expensive Hobby

Dave Brown

Just a short quick one to tell you that I'm happier than a pig in mud to have discovered MacTutor and that in my humble opinion it is the only magazine to buy if one is an experimenter. I diddle mostly with MDS and have written a few little kludges to hep me get smarter and figure stuff. This machine has cost me way too much (I just know I'm the first one to mention this effect) since I got it with 128K in April '84 and have since upgraded to 512K and just a coupla weeks ago got the new ROMS and sufficient disk drive. Some of my non-Mac friends claim it proves that I've got more money than brains but they run on PC's so what can one expect? Ignore the history; I just wish I could beam over there and hug you for such a terrific publication. If I ever get to knowing as much as the people that write for you, or more, I'll send you an article!

Define INTs as 16-bits

Ed Schultz

I am an avid reader of MacTutor and am sending along a subscription for another year. I enjoy reading MacTutor for its technical information on subjects and issues that cannot be found anywhere else and for the level of expertise at which those issues are addressed.

However, in the July 1986 issue of MacTutor, I beg to differ on one point with Bob Denny's criticism of Lightspeed C. The natural word size on the 68000 is 16-bits and not 32-bits. Here are the reasons why one would want to define INTs as 16-bits:

1) Kernighan and Ritchie, the C bible, states on page 34 that "The intent is that short and long should provide different lengths of integers where practical". Certainly it is practical to define SHORTs as 8-bits, INTs as 16-bits, and LONGs as 32-bits. If we chose INTs to be 32-bits, what would we define as SHORTs? And would LONGs then be wasted?

2) Motorola's book on the 68000 is titled the "16-bit Microprocessor" and not the "32-bit Microprocessor". Also, on page 13 of that book, it reads "a byte equals 8-bits, a word equals 16-bits, and a long word equals 32-bits." The instruction does not require the addition of the suffix ".w", therefore implying this is the "natural" way for instructions to be executed. Hence another reason to make INTs 16-bits.

3) MacTutor, as well as compiler developers I am sure, preach the adherence to Macintosh User Interface Guidelines as well as to all guidelines as set forth in Inside Macintosh. On page 86 of Volume 1 in Inside Macintosh, the bible for the Mac, it states that type INTEGER is to be 2 bytes (16-bits) and type LONGINT is to be 4 bytes (32 bits). In your article you state that "Thinks' reasoning was that the bus is only 16-bits wide, therefore 16-bit INTs are faster." Did you talk with the people at Think to get that statement or did you make that assumption yourself? Maybe the people at Think just made the mistake of conforming to the Inside Macintosh guidelines! In any case, all ROM calls are based on the integer being 16-bits. Why should any compiler take the extra effort of converting 32-bit INTs to 16-bit INTs every time it wants to call a ROM routine? This is wasted effort when it would be much easier to simply define INTs to be 16-bits.

About Keyboard Sleuth

Jean F. Schwartz

As a French reader of MacTutor, I really enjoy your fine work. I keyed in your TML-Pascal adaptation of Keyboard Sleuth and encountered now and then some Bombs as you say, in closing the Openlog Dialog Box, either with Cancel or Save. I looked around for error checking, but your code seemed quite similar as the error checking from Chernicoff's Mini-Edit. I wonder if the origin of these bombs is not your statement DILoad in the Procedure Openlog. On page 439 of Mac Revealed, Vol. 2 one may read: "The MiniFinder routines SFGetFile and SFPutFile automatically call DILoad and DIUnload for you, so there's no need to call them yourself..." Without this DILoad, Keyboard Sleuth works fine, I tried it with various System and Finder without bombs.

Another little thing is div 16 in Procedure ShowintlNation, my Mac Plus was configured for Arabiyan! Looking at various Int10Res with Resedit I found it was 256 for France and replacing your div 16 by div 256, my French Mac Plus really was a French one. Trying various configurations with Localizer, they are all correct.

As a novice programmer with TML, perhaps am I wrong, but I hope on improving myself with your help in future issues of MacTutor. [Sounds right. Thank you. -Ed]

Vote for ZBasic, Against True Basic

Ralph Sayer

Thank you for your article on the "Basic Wars" in the August issue of MacTutor. We got one of the first releases of ZBasic and it was really full of bugs. Zedcor was running way behind on their original published release date of ZBasic for the Mac before it was ready. Also, I think they felt a competitive urgency to get into the market as soon as possible. It appears that little beta testing was done on ZBasic before its initial release. We have had considerable correspondence and telephone contact with Zedcor concerning bugs. Version 3.01 corrected a lot of the problems in the original release, but, as you mentioned in your article, there are still a number of bugs in the program. As you stated, one of the existing problems concerns window activation, i.e., to select a window it can only be clicked in the content region and if clicked elsewhere nothing happens - we called this discrepancy to Zedcor's attention on May 22nd. Another bug that we are particularly unhappy with concerns the use of Desk Accessories. If the screen "GET/PUT" functions are used in conjunction with DIALOG(5) (screen refresh) and a desk accessory (e.g., calculator) is selected and moved around on the screen to invoke the refresh function, then "garbage" would be displayed in the PUT area instead of the image originally captured with GET. We sent a demo program to Zedcor to illustrate the problem. Zedcor "corrected" the "basic problem" for us and made a change to our copy of ZBasic. I'm sure there are a lot of people out there that still have this as a problem in their ZBasic, although they may not be aware of it if they have not made the particular usage that we did, as Zedcor has made no updates since version 3.01.

There is still a problem with the use of Desk Accessories, in that the desk accessory (e.g., calculator) does not inactivate a ZBasic window. If a desk accessory is displayed over a ZBasic window, the ZBasic window also remains active. This creates problems in certain of our applications.

There are a number of other bugs that we have uncovered in ZBasic but...even with all the bugs, I think this is a good program and that Zedcor is on the right track, and to be commended. ZBasic is powerful, and when they finally get it cleaned up it should become a strong force in programming languages for the Macintosh. A ZBasic ToolBox Manual would be a very welcome addition. We use a lot of toolbox calls when we use ZBasic.

Concerning True Basic, I really don't understand what they were thinking about when they came out with it. We have it, but in hindsight I wish we had not purchased it, or at least that we had checked it out sooner after we ordered it so we could have returned it within the 30 day trial period. It's a good implementation of Basic but it's practically useless for the Macintosh - who is going to pay $500 for their compiler? And then, if we wanted to write programs in "raw Macintosh" we would use our TML Pascal or Mac C. I'm sorry we bought True Basic.

We have also tried Softworks "basic compiler" - we sent it back after testing it - and had difficulty getting a refund.

For good general fast programming we are going to stick with ZBasic for now. I only hope they get it cleaned up soon and get their ZBasic NewsLetter started. Thank you for a fine magazine.

Book for Transcendental Functions

Dan C. Richard

Jörg Langowski's article on A Custom Floating Point Package shows that high performance can be achieved with tightly coded, specific subsystems. I would like to add a reference for anyone that needs fast and accurate transcendental functions. Software Manual for the Elementary Functions by William Cody and William Waite (Prentice-Hall 1980, ISBN 0-13-822064-6) is the complete work for writing and testing the transcendental functions on any computer for any internal representation.

If someone wakes you up in the middle of the night and says "Write a sine routine, fixed point, with 27 bit word length!" you can reply, "Sure, let me get some information out of a book." After 60 minutes you hand him the code and go back to blissful sleep knowing it is correct and tested. You can repeat this wizard performance for fixed point or floating point representation, binary, hex or decimal machines' arithmetic and any word size up to 64 bits or 18 digits.

The book covers the functions: Square root, Log(e & 10), ex, Power (**), Sine & Cosine, Tan & Cos, Arc Sine & Arc Cosine, Arc Tan & ArcTan2, Hyperbolic Sine & Cosine and Hyperbolic Tan. Within each chapter the function is described with a flowchart and implementation notes.

This is a must book for anyone who wants to write his own transcendental functions.

Facts on CadMac

Dave Lamkins

I noticed an interest in the CadMac system in the last issue, and have enclosed some CadMac sales materials obtained about a year ago.

I had the opportunity to talk to one of their technical people in Sept. '85 and learned the following interesting details, which do not appear in their promotional materials:

1) Mac "compatibility" is only at the C source level.

2) ROM toolbox supported with some differences.

3) RAM-based toolbox calls very limited due to difficulties in mapping Mac-style I/O to Unix device drivers.

4) Yes, CadMac runs on top of Unix, not standalone.

5) No Unix-based resource compilers or editors.

6) CadMac files stored as two separate files, one for the data fork and one for the resource fork.

7) File manager does not support any low-level calls.

8) Event manager is extended to provide an additional 16 bits of event flags, plus support for the Unix System VRZ 'layers' (i.e. true multiprocessing).

9) No Segment Manager support ("incompatible with Unix").

Best of MacTutor: The Book

Alexander Neacsu

In your April 1986 issue you advertised that a Best of MacTutor Book would be coming available. I look forward to such a compilation of back issues which I did not have the foresight to obtain when they were available.

I'd like to hear of any interesting programming applications and patches of Thunderscan digitized image files and/or MacNifty digitized sound files. I'd also like to see more communications programming articles, particularly in regards to links with the IBM world of PCs. Great rag...keep it up. [The Best of MacTutor, Vol. 1 is now available (I hope!) for $24.95. Note that this is a change in price from that published last month! Those who already ordered at the higher price are being sent a refund. -Ed.]

LightSpeed Pascal Development System

Michael D. Coren

I just had the opportunity to attend a presentation by Eric Gould of THINK Technologies, where he described and demonstrated their new LightSpeed (Nè QuickSilver) Pascal development system.

The editing environment is very similar to Mac Pascal, but includes a "Project Manager" with which large programs can be broken up into a number of smaller "units" (echoes of UCSD) which will all be brought together when compiled. THINK advises keeping the units to less than 3000 lines apiece. The first time a program is compiled, the libraries are read in from disk, but subsequent source changes only require the affected units to be recompiled. Programs are compiled in the editor, and then put into another part of memory where you can flip between the running program and the editor to make instantaneous changes. Because of this, it won't work under Switcher, but with the ability to make instantaneous changes and monitor program variables back in the editing environment, THINK didn't feel Switcher was necessary. The editor allows you to save your programs as textfiles, like Mac Pascal, or as standalone applications.

The statements and variables in the "Instant" and "Observe" windows can be saved to disk. The compiler is VERY fast -- I timed it at about 20 seconds to recompile several different units totalling about 1000 lines after a constant was changed (only the affected units were recompiled; this was on a 512K old-ROM Mac with an HD20). Eric also displayed, although he wasn't allowed to say anything about, their "LightsBug" debugger. It was on the desktop like a normal window, and it showed registers, zones, and there was a button that said "edit." Sounds pretty powerful.

The alpha version we saw didn't have the optimizing linker - a 5-line program to print "Hello" ten times took up a whopping 23K on the disk - but Eric assured us that the version finally shipped (mid August) will have the optimizing linker. The compiler doesn't create MDS.REL files, but a utility is included to convert .REL files to the format that can be read in by the compiler/linker. The system can also create code resources such as MDEF's and WDEF's. He did say it doesn't have that 400 byte "preamble" CODE-1 described by Bob Denny in the July MacTutor. Future enhancements will include support for object-oriented programming, like MacApp. He also said to watch for an object-oriented C, which he referred to as "C plus minus".

The instruction manual looked amazingly complete, with more than 600 pages documenting everything from using the editor to MacsBug and ResEdit, including a language reference, what toolbox routines were provided (new ROMs were included), a SANE reference (the same as in the Mac Pascal technical appendix) and 20 to 30-page index. Eric said the secret is to not let the same people who write the software, write the manual.

With all the features it had, and its $125 price tag, I think it's definitely worth looking into.

Extra Values for KbdType

Cliff Joyce

I very much enjoyed your special August "keyboard issue" of MacTutor - particularly Joel West's Be A Keyboard Sleuth article. I have run across a couple of extra values for the global variable KbdType which Joel describes in his article:

KbdType EQU $21E  ; Keyboard type (byte) of
OldKeyBd  EQU  $03   ;The "Classic" (128K, 512K) keyboard
MacPlusBd EQU  $0B   ;The new "MacPlus" keyboard 
TenKeyPdEQU $13  ;TenKeyPad connected w/ "Classic" keyboard
20KeyPadBd  EQU  $1B    ;TenKeyPad connected w/ "MacPlus" keyboard
AssBallPad  EQU  $27    ;Assimilation Process TenKeyPad (and trackball) 
connected w/ "Classic" keyboard.

Note that when the detachable (old) TenKeyPad is connected, the values for the "Classic" and "MacPlus" keyboards change! Also, Joel talks about how the =,\,*,+ keys on the new MacPlus TenKeyPad generate a shift modifier. Yes, to elaborate, they are actually emulating shifted "arrow" keys. In fact, you'll note that the keycodes for the corresponding arrow keys are the same keycodes that the =,\,*,+ keys use, for the sake of compatibility with the old TenKeyPad, where they were the same physical keys.

It became necessary in a "Map to Keyboard" segment of our Calculator Construction Set to call the Key1Trans and Key2Trans routines myself. There is a subtle parameter that should be passed to each of these routines. On entry to the translation routines, D3 determines if the translation should be for a keydown, or not. I passed #-1, D3 to indicate that the keys were up, and #1, D3 to indicate a keydown. This affected the returning keychar values for keystrokes like option-n, which returned as NULL when the key was down (dead key), and ~ when the key was not down (at rest?). This might not be too important for the Sleuthing program, but it is sure a good thing to know when you have to draw a picture of the keyboard on the screen, like in the BigCaps or Keycaps DAs.

Thanks for another great issue - keep up the good work.

MenuDef Bug Alert

Thomas P. Condon

We look forward to receiving MacTutor every month. It has been of great help in our recent programming efforts. However, we have detected a serious bug in Darryl Lovato's "Menu Definition Routines" in the Augusts issue.

In the assignment of a specialized menu definition routine, Mr. Lovato makes the following assignments:

MyRegMenu :=GetMenu(500);
MyRegMenu^^.menuProc :d=NewHandle(0);
MyRegMenu^^.menuProc^:= Ptr(@MyMenuDef);

The serious flaw is that MyRegMenu^^.menuProc, a handle, expects to be pointing to a code segment (normally loaded as a resource) in its own block on the heap. As it is, MyRegMenu^^.menuProc points to a procedure within the CODE 1 segment. This presents several problems. First, MyRegMenu^^.menuProc thinks that it points through double indirection at a relocatable block in the heap, but in fact it points within a nonrelocatable block (Code 1 segment). Second, the block that NewHandle(0) allocated (a block header with a logical size of zero) is left stranded in the heap. This block gets marked as invalid in the heap window of TMON. This leaves us with a very dangerous situation. If you get a heap compaction the program will bomb. All one needs is a heap scramble with TMON to see what we mean.

There are two ways out of this. One is to have your menu definition procedure in a resource and set MyRegMenu^^.menuProc to the resource handle. In order to make the example of Darryl Lovato work, one can do the following:

var
   {globals}.......
   TheProcPtr : ptr;
   {moreGlobals}......
Procedure SetUpThings;
{code}..........
MyRegMenu := GetMenu(500);
TheProcPtr :=ptr(@myMenuDef);
MyRegMenu^^.menuProc:=handle (@TheProcPtr);
{more code}...........

This solves the problem by making the global variable TheProcPtr act like a master pointer, but avoiding the problem of heap compaction. One other benefit is avoiding a heap fragmentation problem by not putting anything on the heap.

One word of warning. The example from MacTutor is practically identical to the TML's Source Code Library graphic menu example. We have not had time to look, but we suspect that there may be similar problems with the other programs in the TML Library for nonstandard definition procedures (i.e. controls, windows, etc.) [Your right, there are! -Ed.] Our method of handling the above error should work well in these cases too. And you don't have to pay us $79.95 for the fix! [Thank you. See Darryl Lovato's article in this issue for more on this subject. -Ed.]

Missing: FORTH column!

Linda Kahn

What happened to the Forth column and why was it strictly MacForth (by Creative Solutions)? Is there any way I can stir up some interest in MasterFORTH? Comments?

Thanx for listening and take care. [The Threaded Code column IS the Forth column and Mach2 IS a Forth. Since this seems to confuse people, we've gone back to calling it a Forth column. And we are open to covering MasterForth. -Ed]

So What is a $C Directive?

Eric Simenel

I'm the happy user of TML Pascal and an avid reader of your excellent magazine and all was for the best in the best of worlds when something terrible occurred while reading your July issue. In the article: Introduction to Definition Routines" by Darryl Lovato, a $C pascal directive is used to create a resource.

The problem is, I never found any description of this directive in my TML Pascal manual, which is version 1.0, edited in November 1985. Although I asked, paid for, and got the update version 1.11 from my local distributor, I didn't receive the update manual if there is one.

Would you kindly please tell me how or where I could get information on the new features of the 1.11 version?

In advance I thank you and keep up the good work. [The $C directive in version 1.11 creates a code resource out of the first procedure it encounters, and must not have a main in it. It is used for getting code into a pure resource without the application header so definition procedures can be loaded as resources. The new manual with version 2.0 should document this. -Ed.]

Taking Screen Snapshots

Adam Schabtach

There is a desk accessory called Camera, written by Keith Esau, that captures the screen after a preset time delay. Since the DA doesn't use the FKEY 3 routine, it doesn't affect the state of the menus on the screen. Camera also will make the cursor invisible when the snapshot is taken, which prevents the arrow from obscuring the menu title. It's very easy to get a screen snapshot with a menu down: open the Camera DA, set a delay of 5 seconds or so, close the DA and pull down the desired menu. Camera will take a screen shot and put it on the startup disk, or send it to a printer if instructed.

This method should work in any application that supports DAs, particularly applications under development, since the author knows them "inside out".

I'd also like to add that your magazine is the best computer magazine I've ever read! Keep up the good work.

About Printer Drivers

Lynn W. Taylor

Regarding your editorial on print drivers, and the response from Anthony Oresteen in the July 1986 issue of MacTutor: I think it's Mr. Oresteen who has missed the point: Apple has very carefully designed a software interface which is device independent. This is important for several reasons:

First, it frees the developer from writing different printer drivers for every printer. Instead, the programmers can concentrate on useful features.

Second, it insures that the application will work with all printers supported on the Mac - present and future! LaserWriter support was automatic for those who followed the guidelines.

Third, it saves the user from the tyranny of configuring their software for the printer, including the dreaded "Custom Configuration" menu, printer codes and the like.

Finally, it allows the end user to choose from a very wide variety of printers, including those offering higher speeds and/or features not available on the offerings from Apple. Star Micronics of Irvine currently produces ten different models, ranging from 120 to 300 characters per second, all of which are suitable for use with the Mac using Star Micronics drivers.

The solution to the problem that Mr. Oresteen presents is not bypassing the Macintosh Print Manager but providing more powerful, faster and more innovative versions of this device.

Adding Zoombox Windows

Timothy Burcham

I've just added ZoomBox windows to the application I'm presently writing, and thought I'd share what I've learned with the readers of MacTutor. These examples are implemented in LightSpeed C and of course requires the 128K ROMs.

1) In the WindowMgr.h, add to the codes returned by FindWindow, the following:

 inZoomIn  7,
 inZoomIn  8

2) Define all windows to have a ProcID of 8. This will give the standard document window with a ZoomBox.

3) Declare externally (i.e. not within a function) the following:

pascal unsigned char     TrackBox () = 0xA83A
pascal void                         ZoomWindow () = 0xA83A;

4) In function containing the event loop (main ()) add something like the following:

main()
{
 unsigned char   Zoom Return;
  .
  .
 switch (event.what)  {
     .
     .
     case MouseDown:
         code = FindWindow(event.where &whichwindow);
         switch (code)  {
           .
           .
           case inZoomIn:
           case inZoomOut:
     ZoomReturn = TrackBox (whichwindow, event.where, code);
                If (ZoomReturn)  {
                  SetPort(whichwindow);
                  EraseRect(&whichwindow->portRect);
                  ZoomWindow(whichwindow,code,FALSE);
                }
                .
                .
                }
}
.
.

That's all there is to it! If your window contains a control, such as a scrollbar, then you must also move the resize the control, similar to the way you would if the window was resized in the traditional way (Grow Window). LightSpeed C can similarly call any other of the new toolbox traps.

More on a TML Bug Fix

Hardison Geer

Dr. Dunn's letter in the July issue on a TML bug gives me an opportunity to sound off as well as to comment on the bug he describes. I would like to see more bug reports in MacTutor so that we can keep track of what is fixed and what is not in new versions of programs. [The best source for on-going bug fixes in commercial programs is the industry newsletter MacInTouch, published by Ric Ford and Rick LePage. Their publication specializes in bugs and other industry news. I highly recommend it. Contact them at (617-527-5808). -Ed.]

In regard to Dr. Dunn's program testA, he is only half right in claiming that it will bomb. If compiled to assembly source code then assembled and linked it works fine. Examination of the assembly code reveals another bug. The listing is as follows:

;;   ifs[i] in ['a'..'z'] then
move.w    i(A5),D6
lea     s(A5),A4
clr.w   D5
move.b    (A4,D6.w),D5
lea     il11+16,A4
move.w   D5,D6
lsr.w   #3,D6
neg.w   D6
btst.b   D5,-1(A4,D6.w)
beq.w    il12

The code at the label is:

il11:   dc.w     $07FF,$FFFE,$0000, $0000, $0000,$0000,$0000,$0000 

The Dr.'s bug is due to the fact that in compiling to .rel the line:

 lea  il11+16,A4 

comes out as

 lea  il11,A4

The other bug is the fact that, as is clear from the above, the base set for the set of char is taken as ord(char) in the range 0..127 instead of 0..255. I've reported these to TML.

Truly No Fluff

Noel T. Goldsmith

Allow me to congratulate you on your publication. At first I didn't realise what NO-FLUFF meant, but having read Macworld until I became saturated with ads and hype I saw the light and am now learning about how to program, even though I am finding some of the concepts and procedures difficult. I am writing an application which will take image data into the serial port on the Mac and convert it into MacPaint format to allow the user to use MacPaint operations on the bit map and print, save, etc. Would it be possible to use a compiled version of the program Read Mac Paint Doc, by Alan Wootton, published in MacTutor Vol 1 no 7 as part of this application, which would allow the user to view his image on the Mac screen at 1/4 scale? [Yes, should do it. -Ed]

Question on Neon

Pierre Gelli

I have been reading MacTutor for almost a year now, and at last I have decided to subscribe for a full year. I must say that MacTutor is indeed really great. It helps us here, in the far away old Europe, to hear what's new about Macintosh. The Mouse Hole section and the articles in general have a very good technical level that no other review I know about matches.

I have been experimenting with Neon for a few months. I have been looking for an "environment" for easy and fast prototyping on the Mac for the the Mac, i.e. something where you kind of type in short pieces of code, get it interpreted, and look at what it does in another window. I have also been looking for a language that manipulates higher level concepts than the standard ones manipulated through the toolbox. For example, objects which can be attached to a window and live their own life. It's easy when only one TextEdit record is inside a window, but things get more complicated with several graphic objects. I should say that Neon fulfills my expectations except for strange crashes in v1.5 when I leave and re-run NEON. Anyone else have this problem?

Pascal Storage Allocation Explained

Steve Jasik

Find enclosed an Ad for the October issue for MacNosy, and the latest version 2.25 to update your software inventory.

Finally I had some time last night to read the August issue of MacTutor. Your article on Rascal to Pascal contains some misinformation. In discussing storage allocation for strings you got confused over the space allocated to the string and method by which it is passed as an arguement to a procedure. Lisa Pascal's method of passing parameters is described in the new MPW Pascal manual and both of the Lightspeed manuals. The terminology that we compiler people use is:

Call by value: the value of the parameter is passed.

Call by Reference (or address): the address of the parameter is passed.

The basic convention for Lisa Pascal is that "objects" longer than 4 bytes are "Call by Address" and those 4 bytes or less are "Call by value", UNLESS they are declared as VAR parameters, in which case they are "Call by Address". For more info, check out the above mentioned manuals and keep in mind that objects always have to have storage allocated for them by the CALLER. In the case that a string is passed to a procedure as a non-VAR parameter, the CALLE makes a local copy of it so that the original string doesn't get modified. The reason for some of what may seem to be idiocy to you is that FORTRAN passed all parameters by address, and some programmers had the nasty habit of modifying those which were constants. In order to correct this problem, the good people who design programming langauges invented the Call by Value mechanism of parameter passing. For example, in fortran we might have:

 CALL MODCON(X,1.2,Z);
 
 SUBROUTINE MODCON(XX, ACON, ZZ);
 ACON = 5.4  
C  {this will change the constant 1.2 to 5.4! Not nice!}

Yall Send Author's Kit

Dave Peeples

I can't stand it anymore Month after month I wait for my MacTutor (The only Mac Magazine with any "intestinal Fortitude" or anything else as far as that goes) to find out how to do all those neat things that I can't dig out of "Inside Mac" and all the latest "Computer Gossip" on what's what, what is, what ain't and what coulda been only if So would yall send me one o them kits an I'll promise ta do ma best

Late News Item

World's Greatest Publishing Program

Special to MacTutor from MacAmerica

MacAmerica announced and showed what many are claiming may be the best Desktop Publishing Program currently available at the Seybold Publishing Conference in San Francisco this week. A hastily called demo on Saturday afternoon resulted in hundreds of people gathering at the MacAmerica booth to hear Jim Fitzsimmons introduce "SPUD", a code name for the new Pagemaker alternative. Two hours later, without a single crash, the audience of publishing power brokers were cheering and clapping as the author demonstrated the program's features. It is said by those who saw the demo that it combines the best features of Super Paint, MacDraft, Pagemaker and more into a very powerful layout program designed for the traditional publishing industry [read bigie machines] but written in 68000 assembly code for the Macintosh. Judging by who some of the people watching the demo here, this may be the biggest sleeper of the year and promises to make the MacTutor booth in San Francisco, where it will be formally released, a very busy place. Jim promised that SPUD will be reasonably priced and will be targeted as "everyman's Pagemaker" but with more power for less money. MacTutor has been scheduled to be one of the first beta sites for the program. MacAmerica is exclusive distributor for SPUD, having just completed a formal contract with the author at the conference just hours before the product was announced. The product is said to be "99%" complete. MacAmerica also distributes the best selling LaserSpooler, a hit at the Boston show, as well as MacTutor. For more information on SPUD, contact Jim Fitzsimmons at MacAmerica (714) 779-2922.