May 90 Letters
Volume Number: 6
Issue Number: 5
Column Tag: Letters
THINK Pascal 3.0 with MacApp 
By Kirk Chase, Editor, MacTutor
THINK Pascal 3.0 Has MacApp Support
Kirk Chase
Anaheim, CA
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
Dutch Macintosh Developer
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
Wichita, Kansas
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):
40860646 LEA *+$0010, A0
4086064A MOVEQ #$18, D1
4086064C MOVE.L (A0)+, A1
4086064E ADDA.W D0, A1
40860650 DBF D1, *-$0004
40860654 BRA.S *+$0000
Tom Pittman
San Jose, CA
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
Anaheim, CA
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.