Letters

By David E. Smith, Editor & Publisher, MacTutor

Language Systems Plans

Rich Norling

In MacTutor’s April letters column, Bert Waggoner added his name to the list of those asking us to add a SELECT CASE statement to the Language Systems FORTRAN Compiler. We are now making plans for Version 2.0 and I want to let your readers know that SELECT CASE and NAMELIST are at the top of our list of new features to add. Both will be done according to the FORTRAN ’8X syntax, so no changes in FORTRAN source code will be needed when ’8X becomes a formal standard (let’s hope that happens before the proposed standard has to be renamed ’9X!).

Additional suggestions for new features in Language Systems FORTRAN are welcome. Please send them to us at the address listed in our ad (inside front cover).

Corrections

Don Koscheka

Joe,your article on adding windows to XCMDs was informative and, for the most part, well written. Your discussion of scroll bars needs clarification. You state that using ScrollRect to scroll a window is not the preferred approach because the window will not get redrawn until update time. This is not true. While Inside Macintosh does imply that you should pass the UpdateRgn of the current window to ScrollRect so that the vacated area gets accumulated into the window’s invalrgn, this is not strictly necessary. Consider the following code fragment:

 
Procedure TrackScroll( theControl : controlHandle; thePart : INTEGER 
);
VAR
    TempRgn     : Region;
    tempRect    : Rect;
    dh, dv      : INTEGER;
BEGIN
    {*** determine what part of the control we’re in... ***}
    {*** and set dh, dv accordingly                     ***}
    ...
 
    {*** now scroll the scrollable part of the window   ***}
    tempRect := theWindowsScrollablearea;
    TempRgn := newRgn;
 
    ScrollRect := ( tempRect, dh, dv, tempRgn );
    SetClip( tempRgn );
 
    {*** call whatever routine draws window contents    ***}
    Redraw_The_Window;
 
    DisposeRgn( tempRgn );
    ...
END;

This code has the advantage of requiring only enough extra memory to store the vacated region. Moreover, the novice programmer need not write any special screen drawing code. Whatever code is used to draw at update time can be called directly to redraw the window at scroll time. Since the window is clipped to only the vacated region, this approach results in fast, smooth scrolling.

The more experienced user can query the region to determine exactly which rectangle to update so that the application draws only what will be displayed in the vacated rectangle. This is useful in applications like word processors where much of the update time is spent calculating where things need to go on the screen.

Another interesting consideration is the possibility of creating universal scroll bars. We accomplished this by having track scroll operate on a “scroll record” that keeps track of all appropriate information relating to a given scroll bar. One of the fields passed to the scroll record is the address of the routine to call in lieu of “Redraw_the_Window” in the above example. The result is quite satisfactory: one pair of scroll bars can be made to behave consistently regardless of the number of window variations in a given application.

Thanks for the bent ear. Good luck at Apple (as a six-year veteran, I can tell you that it’s a great place to work...)

CDEF Corrections

Kirk Chase

It was brought up to my attention of another way to include CDEFs for debugging purposes. James Plamondon, from Abacus Concepts, pointed out a better, more legal (?), way of setting the contrlDefProc field of the control record.

const
 JMP_Instruction = $4EF9;

type
 JumpRec = record
 instruction  :  integer;
 function : Ptr;
 end; {JumpRec}

 JumpPtr = ^JumpRec;
 JumpHdl = ^JumpPtr;

var
 cdefJump : JumpHdl;
 ctrlHdl : ControlHandle;

begin { Open_Example_Window}
 {allocate and initialize jump record}
 cdefJump := JumpHdl(NewHandle(sizeof(JumpRec)));
 cdefJump^^.instruction := JMP_Instruction;
 cdefJump^^.function := myCDEFProc;
 {this ends initializing the jump record}
 
 {get the control record}
 CtrlHdl := GetNewControl(ButtonID, MyWindow);
 
 {Set the contrlDefProc}
 CtrlHdl^^.contrlDefProc := Handle(cdefJump);
 
end;

After diving into the tech notes, I also found what James already knew. James also mentions that the control definition proc should be locked by keeping it in code segment 1.

I appreciate James Plamondon help. The method I gave was essentially for prototyping controls. This made development time faster since you could bypass the Compile, ResEdit, Compile, Frustration loop. I hope Abacus realizes the asset James Plamondon is. Thanks A Bunch.

MPW vs. LSC

Will Flor

I thought I might give my views on the MPW vs. LSC controversy raging in the March issue of your excellent journal, and also report a serious error in Jerry Sweet’s otherwise excellent article on Ada.

In my last job, I developed finite-element modeling software on the Mac, and the project was started in LSC. This type of software uses a lot of file I/O, and we had a large set of routines known to work properly in several other environments (hundreds of units shipped without a single bug report dealing with file I/O). Upon porting these routines to LSC, they did not work. An examination of the problem showed the LSC libraries to be bug-ridden and unmaintainable. The errors we were getting included undocumented error codes being returned, “file not found” error code returned when we tried to create a file, and more. After wasting nearly a day, we ported to MPW 2.0.2 and never had these problems. The Think technical support people were not knowledgeable about their product, but admitted the sorry state of their libraries after the erroneous source lines were pointed out to them. I have heard other similar stories from other software developers, too. For very simple programs, perhaps LSC works adequately; for true big-time software development it simply doesn’t do the job. The “one segment per source file” restriction is untenable as well. I do not use LSC and cannot recommend it to my clients.

Comparing MPW 3.0 to LSC is like comparing a turbo SAAB to a tricycle--they do basically the same thing, and MPW (and SAAB) is arguably harder to learn to use properly, but there’s an obvious difference in power and capability. MPW 3.0 is so different from MPW 2.0.2 that it definitely warrants the upgrade fee, since it’s really a totally different product--the C compiler is totally different, the Projector source code control system is great (although it suffers from a few problems as well), and everything is 25-40% faster. Perhaps a tricycle is more appropriate for some, but I’ll take MPW and the turbo SAAB any day.

Jerry Sweet’s otherwise excellent article on Ada did contain one serious factual error. He states that the MPW C “integer” data type is 16 bits wide--it is 32 bits wide. The MPW C integral type that is 16 bits wide is “short integer” or simply “short.” This is crucial to writing a correct interface subprogram since, as he correctly points out, there is no data type cross-checking available, and it is easy to pass the wrong parameter type.

Thank you, Mr. Smith, for editing such an excellent journal. Please keep up the good work.

More On Compare Strings

John S. Stokes III

In Steve Brecher’s letter published in the March 1989 MacTutor, page 11, he pointed out a bug in my “Compare Strings” routine in addition to suggesting some improvements. I confess that I wrote the letter off the top off my head in response to seeing some wasteful code. In looking at the actual code from programs I’ve written, I do use the

 Moveq  #0,D0
 Move.B (A0),D0

technique to load up the length for the compare loop.

I agree that using

;2


@0 Cmp.B(A0)+,(A1)+
 DBne D0, @0

is much better than using

@10Cmp.B(A0)+, (A1)+
 Bne.S  @900
 Dbra D1, @10

and I thank Steve for pointing that out.

There is an error in his code if the comment “Return D0.L=1 if equal, 0 if not equal” is to be taken seriously. Consider what happens to register D0 if the strings compare equally. Register D0 will have a $0000FFFF after falling out of the loop. Executing

 Seq  D0

will cause D0 to still contain $0000FFFF since the FF will replace the existing low order FF. Executing

 Neq.B  D0

will cause D0 to contain $0000FF01 instead of $00000001. Ooops.

If the strings are not equal, D0 will contain $000000?? before the Seq instruction and $00000000 after both the Seq and Neg.B instructions. This is OK.

The solution is to change the Neg.B to a Neg.W.

A re-corrected CompareString routine would look like this:

;3

;A0 -> Pascal String 1
;A1 -> Pascal String 2
;D0 Returns D0.L=1 if equal, 0 if not equal
;Alters A0-A1

CompareString:

;4

 Moveq  #0,D0
 Move.B (A0),D0  ;gross length - 1
@0 Cmp.B(A0)+,(A1)+;loop until 
 DBne D0,@0 ; not equal or end
 Seq  D0;$0000ffFF if equal, else 0
 Neg.W  D0;1 if equal, else 0
 Rts

Also, Steve did err in saying:

“Ext.W propagates the value in bit 15 of the register through bits 16 31. Therefore, it will not have the desired effect of clearing bits 8 15. Ext.B would not work either for cases in which the string length is greater than 127, i.e., negative considered as a signed byte; in such cases Ext.B would set bits 8 15, making the unsigned word value very large.”

There is no “Ext.B” instruction. Ext.W does what was ascribed to Ext.B; Ext.L does what was ascribed to Ext.W. So my Ext.W instruction did have the desired effect as long as the string length was less than 128.

Correction to Correction to CompareString

Steve Brecher

John F. Reisor’s letter (Apr. 1989) correcting John Stokes’s original (Jan. 1989) made me realize that my own correction (Mar. 1989) was incorrect! Reisor’s code contains an error also.

My submission omitted an Ext.B D0 instruction just before the final Rts. Reisor uses Ext.W D0 where there should be an Ext.B D0.

Since this issue of conditioning bits 8..15 of a register has tripped up three of us, perhaps a review is in order. Ext.B sets each of bits 8 through 15 of a register to be equal to bit 7; it does not affect bits 0..7 or bits 16..31. Ext.W sets each of bits 16..31 to be equal to bit 15; it does not affect bits 0..15. In other words, Ext.B extends the sign of the low order byte through the high order byte of the low order word. Ext.W extends the sign of the low order word through the high order word.

Note that where I wrote

 Seq  D0
 Neg.B  D0

Reisor wrote instead

 Sne  D0
 AddQ.B #1,D0

which is equivalent.

My routine and Reisor’s, after correction, are both the same length. But any Macintosh assembly language programmer should be able to come up with a version that is one word shorter--left as an exercise for the reader. For those who wish to try, here is the final “long” version:

;5

; A0 points to a Pascal string
; A1 points to a Pascal string
; Returns D0.L = 1 if strings equal, else 0

 MoveQ  #0,D0
 Move.B (A0),D0
@0 Cmp.B(A0)+,(A1)+
 Dbne D0,@0
 Seq  D0
 Neg.B  D0
 Ext.B  D0
 Rts

Claris CAD

Kirk Chase

Claris has added another fine product to their line, Claris CAD. This is a fine CAD product, specifically designed to take advantage of the Mac and its graphic capability. This high-end product follows the trend of others by including a videotape for learning the program’s capabilities rapidly. It has a complete set of two-dimensional tools for design and drafting professionals. It also allows for changing dimensions and units.