ADVERTISEMENT

THINK Pascal 3.0 with MacApp

By Kirk Chase, Editor, MacTutor

THINK Pascal 3.0 Has MacApp Support

Kirk Chase

THINK Pascal 3.0 is shipping now with MacApp support. THINK has really pushed their fine product onto mainstream OOP programmers by giving them a choice of either using the THINK Class Library (TCL) or MacApp. In addition to this, THINK Pascal 3.0 will edit larger files (up to 32,000 lines). They have generalized function calls, methods, and type casting. THe declaration of KeyMap is now done the way it was supposed to be done. One of the better features is the segementation at the procedure level; you can put your procedures into virtual segments, name them, and drag them into the physical segment of your choice. The linker has also been optomized to generate direct procedure calls for monomorphic methods (those methods that are never overridden).

In addition to all these, you get a host of other goodies to play with. On top of the list is the Class Browser. This feature gives you more than just an overview of class hierarchy; the Class Browser is an indespesible navigational aid to your code by creating links between it and the Browser; just double click to go to the definition of a class to edit it, hold the mouse button down to get a pop-up menu of methods to go to, and option, double click to find all the classes that define that method. The next goodie is SARez and SADeRez (“Say Rez” and “Say DeRez”), these long awaited standalone MPW tools will sink the clumsy RMaker. In addition to this, there is the Pascal Source Code Converter which takes your code and makes it MPW/THINK compatible; this is what you do with MacApp to use it in THINK.

Now you can have you MacApp and your speedy development too. From the benchmarks I was given, THINK beat MPW in first compilation speed by almost half and rebuild time is sooo short. Bowers Development’s AppMaker 1.1 supports the TCL. Bear River Institute and Invention Software are both holding training courses.

Unfortunately, there is a price tag to all this. THINK Pascal 3.0 costs $249 (up $100) or you can upgrade for $69. You will also need 2 megabytes to use THINK’s TCL and 4 megabytes to use MacApp. You need to aquire MacApp seperately from Apple (800-282-2732). You can contact Symantec for the upgrade at 800-441-7234 outside California or 800-626-8847 if inside California.

.FileName Syndrome

HOL0166, Roland van Straten

When I was copying some folders from one harddisk to another I came across an old Finder™ quirk and as a result I started a little discussion on AppleLink.

Jim Reekes of Apple informed me about TechNote #102, which told me some more about my experienced problem. (I should read more!)

So what is the problem with the “.” and “:”?

As we all know (I forgot, shame on me) drivers are named using the “.drivername” convention. If we pass such a name in a PBOpen, FSOpen, or ? we can expect a driver refnum instead of a file refnum in return. If for instance we issue a PBWrite or ? we can have big trouble if the name should read “.Sony”. It could invoke a strange write and the contents of our inserted floppy is gone! So beware!

As for the colon: IM I-521 States “The User may specify a disk name (preceding the file name and seperated from it by a colon)... ; users should not be encouraged to do it. Well it is possible in almost every program.

My TROUBLE is gone

My solution to all this is presented below. Nothing to be proud of but, usable code.

{1}
 
{install the following procedure like this:
   SFPutFile(where,prompt,oldfname,@ClnPrdFilter,replyRec);
   Written by Roland van Straten, no copyright whatsoever }
FUNCTION ClnPrdFilter(item: Integer; theDialog: DialogPtr): Integer;
CONST
  kPoint = $2E;
  kColon = $3A;
VAR
  fNamStr: Str255;
BEGIN
  ClnPrdFilter := item;
  {there is always more than a character otherwise the putSave button 
would be
   grey and putSave value would not be the item number given to this 
filter}
  IF item = putSave THEN BEGIN
    GetDIText(theDialog,putName,fNamStr); {concatenate of GetDItem & 
GetIText}
    {check if first char a “.” and if there is a “:”}
    IF (fNamStr[1]= Char(kPoint)) OR (POS(Char(kColon),fNamStr)<> 0) 
THEN BEGIN
      SelIText(theDialog,putName,0,32767); {hilight the edit text item}
      SysBeep(0); {inform user about error}
      ClnPrdFilter := 100; {fake 0-event, another round of modal_dialog_ing}
    END;
  END;
END;

It is possible to filter the characters completely by using SFPPutFile(...). You are able to remove characters at the moment they are actually typed into the Edit Text Item. I found that this was not neccesary. It takes two filters and there is not much to gain.

Stolen from Apple Computer

David T. Craig

MacTutor magazine contained in its “The Completer MacTutor, Volume 2” two letters concerning the Macintosh ROM and a special ROM icon (see “Stolen from a Mac?” on page 556 and “Stolen from Apple Computer, Part II” on page 571). This icon, whose image appears below, appears to be used by Apple as a form of ROM protection from illegal ROM use.

MacTutor described the icon location and its display routine for the Macintosh Plus ROM. I searched my Macintosh II’s ROM for this icon and found the icon display routine at address $40860646 and the 128 bytes of the icon image starting at address $40860656.

I found the icon display routine using MacsBug by searching for the word $60FE which corresponds to the 68000 instruction “BRA *-2” which branches to itself resulting in an infinite loop and machine lockup. The actual MacsBug command I used to find the icon display routine was

F 40800000 40000 60FE

where $40800000 is the starting address of the ROM (obtained from the low-memory global pointer ROMBase at $02AE) and $40000 (256K) is the byte size of the ROM in my Macintosh II.

From MacsBug, you may see the icon display routine by typing IL 40860646. To see the icon data type DP 40860656.

The ROM code that displays the icon (A1 points to the screen):

40860646LEA *+$0010, A0
4086064AMOVEQ  #$18, D1
4086064CMOVE.L (A0)+, A1
4086064EADDA.W D0, A1
40860650DBF D1, *-$0004
40860654BRA.S  *+$0000

CompileIt!

Tom Pittman

While I’m sure that HyperBasic is a valuable contribution to the set of Macintosh development tools, it can hardly be said to have broken the C and Pascal monopoly on XCMD and XFCN creation: that happened over a year ago when CompileIt! mad HyperTalk a viable language for creating HyperCard externals.

I took the liberty to rewrite in HyperTalk the two HyperBasic benchmarks from February Kelly’s Corner. Note that the scripts are both shorter and more readable (no GOTOs); there is no concern with explicit type conversion nor call backs, as these are handled automatically by CompileIt! I tested both scripts in interpreted HyperCard, which is much easier than using MacsBug (though CompileIt! also generates procedure names for MacsBug and offers several other features to ease the pain of debugging). I then compiled the debugged scripts and immediately ran the resulting XCMDs, which were installed automatically in my designated target stack. MacTutor’s readers may be interested in the results:

--2

on SieveofEratosthenes
 put the ticks into time1
 repeat 10
 put 0 into count
 repeat with i=1 to 8191
 put 1 into char i of Flags
 end repeat
 repeat with i=1 to 8191
 if char i of Flags is not zero then
 put i*2+3 into Prime
 put i+Prime into k
 repeat while k<=8190
 put 0 into char k of Flags
 add Prime to k
 end repeat
 end if
 end repeat
 end repeat
 put the ticks into time2
 put count&&”primes in”&&(time2-time1)/60&&”seconds” into field 1
end SieveofEratosthenes

on accuracy
 put the ticks into time1
 put 0.0 into s
 put 0.0 into x
 put 0.00123 into del
 repeat 1000
 add x*x to s
 add del to x
 end repeat
 put the ticks into time2
 put “s=”&s&&”x=”&x&&”in”&&(time2-time1/60&&”seconds” into field 1
end accuracy

Although the sieve as written ran much slower than the published HyperBasic result, I was able to apply some of the code improvement techniques suggested in CompileIt! documentation to get the seive time down to 7.1 seconds on a Plus (compared to HyperBasic’s 7.48). The accuracy benchmark ran unmodified in 2.03 seconds, compared to HyperBasic’s published 2.12 seconds, and produced the correct result s=503.543802; I assume the incorrect result given in Kelly’s Corner is the publisher’d error, not HyperBasic’s. Both scripts were tested with CompileIt! version 1.5, which should have begun shipping in February.

CompileIt! is written entirely in HyperTalk, so it is not necessary to leave HyperCard to compile an XCMD. Although compile time in the current version is slower than HyperBasic, CompileIt! gives the programmer access to over 800 ROM routines (all the traps from all five Inside Macintosh volumes), all documented low-memory globals, and many defined data structures and constants. The list of built-in names is easily expanded to include new constants, data structures, traps, and callbacks, such as those for SuperCard and other programs that take HyperCard-style externals.

CompileIt! is available from Heizer Software (800) 888-7667 as well as several Mac retail outlets.

On the Arrival

Kirk Chase

A number of new items have been recently introduced into the market. On top of the list is the Mac IIfx. This one is sweet. Running at 40Mhz, it is 100% faster than the IIci. Add to this Apple’s new color card with the QuickDraw coprocessor, and you will see 1 bit performance at 24 bits.

Premtech Corporation has announced there Macnifier. This image enlager for the Mac’s 9 inch screen reduces eyestrain by enlarging the image. It also has an anit-glare filter on it. You can contact Premtech at 404-662-1533.