Available Application List

By Chris Yerga

A few weeks ago I was compiling a disk of my favorite games for a friend of mine. Disk space being as valuable as it is, the Finder’s use of close to 50K of disk space seemed a terrible waste on a disk containing files that would probably never be manipulated in any way. Armed with my copy of Inside Macintosh, I set out to correct this injustice. My goal was to write a short program that would present the user with a list of the available applications and allow him to execute the one of his choosing. As is usually the case when I set out to write a program, I found that what seems at first to be an arduous task (up to this point I had never tried to access the disk drive and the file directory) is actually quite simple when full advantage is taken of the Mac’s built in routines. This article will concern itself with two such routines: the Standard File routine and the Launch facility.

Working according to the flow of the program, our first concern is to list the available applications and allow the user to select the one he wants to execute. Anyone who has ever opened a document from an application should be familiar with the Standard Get File dialog box [See BASIC column for an introduction to Standard File dialog box]. This standard method of opening a file is quite simple to implement through the convenience of the Package Manager. The package manager allows an application to call one of several “packages” -- short specialized routines kept in the System file -- from its main code. This saves the programmer from having to write code to perform the tasks that are provided for by the Package Manager. There are packages for opening files, saving files, initializing disks, and performing Binary/Hex conversion among others.

The package that we are going to use is called the Standard Get File package. It lists all the files of a certain filetype that are on a disk and allows the user to choose one of them. As programmers, virtually all that we are required to do is tell the package manager what filetype(s) that we want listed and where to put the resulting information. The PM takes care of the rest: it creates the dialog box, reads the disk directory, handles events, and stores the input that it gets from the user. This is exactly what we want, so our task is simplified immensely by this routine. However, if we did need the PM to function a bit differently, it has provisions for designing custom dialog boxes and performing special event handling tasks.

Page 13 of the Package Manager Programmer’s Guide portion of Inside Macintosh describes the standard get file procedure’s PASCAL interface as follows:

Procedure SFGetFile  (where: Point;  prompt: Str255;  fileFilter:  ProcPtr; 
 numTypes: INTEGER;  typeList:  SFListPtr; dlgHook: ProcPtr;  VAR reply: 
SFReply);

From assembly language, the first value that we need to push is where, which describes the top lefthand point at which the dialog box will be drawn. A bit of experimentation convinced me that (80,86) would serve our purpose well. The next variable, prompt, is not used by the current PM; however, older versions did require it to be passed, and so the PM accepts it to insure compatability with older programs. FileFilter is used by applications that want to determine for themselves which files to display in the dialog box. We will pass NIL for this variable, because we would rather have the PM do it for us. NumTypes tells the PM how many different filetypes we want displayed. In our case this value is 1, since we only want applications displayed. Next, we push typeList, a pointer to the list of filetypes to be displayed. DlgHook is used by applications that need to draw a custom dialog box. Again, since the standard dialog box suits our needs, we will pass NIL. Finally, VAR SFReply points to the standard file reply record, a data structure through which the PM communicates with the calling application. The assembly language implementation looks like this:

SFGetFile From Assembly

MOVE.W  #86,-(SP);Y coord. of where
MOVE.W  #80,-(SP);X coord. of where
PEA‘Prompt’ ;prompt: unused, but 
 ;we need to pass a  ;string to keep the 
 ;Package Manager  ;happy
CLR.L -(SP) ;fileFilter:  unused,  
 ;so we pass NIL
MOVE.W  #1,-(SP) ;numTypes:  there is 
 ;only 1 filetype in 
 ;our list
PEATypeList ;typeList:  points to 
 ;our list of filetypes
CLR.L -(SP) ;dlgHook:  unused,  so 
 ;we pass NIL
PEASFReply;SFReply:  points to 
 ;the Reply Record

The reply record contains information such as the filename, filetype, the volume where the file can be found, etc. Its structure, as described in Inside Macintosh is shown in figure 1.

The first variable, good, tells whether or not valid data is in the reply record. If it is FALSE, then the user hit the cancel button or for some other reason, the data should be ignored. If TRUE, then the call was successful and the calling application can process the data. Copy is unused; Inside Macintosh gives no explaination. The next variable is fType, the 4 character filetype of the file selected. We do not need to look at this, because it will always be ‘APPL’ -- the filetype for applications. VRefNum is the volume reference number of the volume that contains the selected file. This is needed in many file manager calls. Version is the version number of the selected file. Perhaps the most useful piece of information is fName, the filename of the selected file.

After everything has been set up, we are ready to invoke the standard get file package as follows:

MOVE.W  #2,-(SP) ;Call SFGetFile through 
_Pack3  ;the package manager

After checking good and determining that a successful call has occurred, the only remaining task is running the selected application.

The routine responsible for running an application is located in the Segment Loader and is called Launch. The launch routine is unique in the method used to call it. Unlike the toolbox traps, in which values are passed on the stack, launch is a routine whose values must be pointed to by an address register. Register based routines such as this are common in the low level system portion of the Macintosh ROM.

In calling the launch routine, the programmer passes a pointer to the Launch Pointer Record in A0 [Fig 2]. The first 4 bytes of the LP record (no pun intended...) consist of a pointer to the filename of the application we want to run. As all Macintosh programmers must quickly learn, the assembly language equivalent of a pointer is an Effective Address. In order to get a pointer to the filename, we load its effective address into address register A1 by the instruction LEA FileName,A1. When we have the effective address (or pointer) in a register, we are free to store it in the proper location of the LP record. The last 2 bytes compose a word of data that tells the launch routine how we want memory allocated to the application. A value of NIL in this location gives standard memory allocation (as the Finder would), so we do not need to change it.

After the LP record has been set up and A0 is pointing to it, the trap _Launch is called and we are finished.

The balance of the program consists of initialization calls to the various managers and a few QuickDraw traps to display the title of the program. The program as I have implemented it is functional, but rather spartan in its lack of features and appearance. No resources were included and there is no use of menus or windows. The purpose of this article was to describe some interesting parts of the toolbox, not to reiterate the material that David has described in his column. However, I encourage you to liven your own versions up by putting some graphics or a description of the program somewhere on the screen. At least put your name in it and impress your friends!

;    MicroFinder      
;   
;     A startup program that allows   
;  the user to select the  
;     the application that he wants 
;  to run of those on the disk.     
;  June 1985.     
;   
;    © MacTutor by Chris Yerga        
;      Contributing Editor            

;     ToolBox & System Traps        

.TRAP   _InitCursor$A850
.TRAP   _InitGraf$A86E
.TRAP   _SetPort $A873
.TRAP   _BackPat $A87C
.TRAP   _DrawString$A884
.TRAP   _TextFont$A887
.TRAP   _TextSize$A88A
.TRAP   _MoveTo  $A893
.TRAP   _PenPat  $A89D
.TRAP   _FrameRect $A8A1
.TRAP   _PaintRect $A8A2
.TRAP   _EraseRect $A8A3
.TRAP   _InitFonts $A8FE
.TRAP   _GetWMgrPort $A910
.TRAP   _InitWindows $A912
.TRAP   _InitMenus $A930
.TRAP   _InitDialogs $A97B
.TRAP   _TEInit  $A9CC
.TRAP   _FlushEvents $A050
.TRAP   _InitPack$A9E5
.TRAP   _Pack3   $A9EA
.TRAP   _Launch  $A9F2

;    Declaration of external labels     

XDEF  START ;For the  linker

;        Local Constants     

AllEvents equ  $0000FFFF
Athens  equ 7    ;Our text values
AthenSize equ  18

;      Start of Main Program   

START:

MOVEM.L D0-D7/A0-A6,-(SP) 
LEASAVEREGS,A0
MOVE.L  A6,(A0)
MOVE.L  A7,4(A0)
 
;      Initialize the ROM routines  

 PEA  -4(A5);QD Global ptr
 _InitGraf;Init QD global
 _InitFonts ;Init font manager
 _InitWindows  ;Init Window Mgr
 _InitMenus ;Init menu manager 

 CLR.L  -(SP)  ;Get standard  ;failsafe procedure 
 _InitDialogs    ;Init Dialog Manger
 _TEInit;Init Text edit for ;the heck of it
 
 MOVE.W #2,-(SP)
 _InitPack;Init Package Mgr
 
 MOVE.L #AllEvents,D0;And flush 
 _FlushEvents    ;events
 _InitCursor;Get the arrow
 
;       Start of the Main Code      

PEAGptr ;Get Handle to WMgrPort
_GetWmgrPort

LEAGptr,A0
MOVE.L  (A0),-(SP) ;Push address of  ;the ptr to the port
_SetPort;And open the port
 
PEAGrayPat;Set the Backround  ;Pat’rn to 50% Gray
_BackPat
PEAScreen ;And clear the screen
_EraseRect
 
;  Display the Title of the program   

 
PEAWhitePat ;white rectangle text
_PenPat ;Set the pattern to white
PEATitleRect;Point to our rectangle
_PaintRect;and fill it with the Pen Pat.
PEABlackPat ;draw a thin Black border
_PenPat ;Set the pattern to black
PEATitleRect;Point to our rectangle 
_FrameRect;and draw the frame of it

MOVE.W  #135,-(SP) ;position Pen 
MOVE.W  #60,-(SP);Screen (60,135)
_MoveTo ;Position pen...
MOVE.W  #Athens,-(SP);Choose font 
_TextFont ;(Athens = 7)
MOVE.W  #AthenSize,-(SP) ;size of text
_TextSize ;(AthenSize = 18)

PEA‘LaunchAp 1.0 by Chris Yerga’ 
_DrawString ;And draw it... 
PEAWhitePat ;Background Pat. to  white
_BackPat;So the dialog box looks   ;normal...
 
 
MainLoop: 
 
;        SFGETFILE ROUTINE   

MOVE.W  #86,-(SP);Y Coordinate
MOVE.W  #80,-(SP);X Coordinate
PEA‘PROMPT’ ;Prompt (Unused)
CLR.L -(SP) ;NIL for FileFilter
MOVE.W  #1,-(SP) ;We only want 1 file  ;type listed
PEATypeList ;Point to the Type     ;List
CLR.L -(SP) ;NIL for dlgHook
PEASFReply;Point to the Reply ;Record
MOVE.W  #2,-(SP) ;Routine Selector ;for SFGetFile
_Pack3  
LEASFReply,A0    ;Get the result   ;from the Package           
 ;Manager
CMP.B #0,(A0)    ;was it successful  ;(good = TRUE) ?
BEQMainLoop ;Nope, user hit the    ;cancel button, try
 ;again till he  ;figures it out 
PEABlackPat ;Clear the screen ;to Black
_PenPat
PEAScreen
_PaintRect
 
;       Launch Routine     

LEASFileName,A1  ;Get the address of ;the filename
LEALaunchPtr,A0  ;Get the address of ;the Launch Ptr in
 ;A0 (according to ;Register Based 
 ;conventions.
MOVE.L  A1,(A0)  ;Move the Ptr to the  ;address of the 
 ;filename (in A1) ;to the first word  ;of the Launch Ptr
_Launch ;And call Launch  ;...zoom!

;   
;      The Program’s Variables       
;   

SAVEREGS: DCB.L  2,0

GPTR:   DS.L1  ;Space for ;the GrafPtr
SCREEN: DC.W0,0,342,512   
 ;Rectangle describing the full
 ;Macintosh screen
TITLERECT:DC.W 41,127,69,381;Rectangle that contains the name
 ;of the program etc.
 
TYPELIST:  DC.L ‘APPL’  ;The list of file                      
 ;types we want
 ;displayed in the ;Standard File
 ;dialog box. In this     ;case, there is
 ;only 1 type

;                  
;      The Standard File Reply Record ;                 

SFREPLY:DC.B0,0  ;good, copy  (BOOLEAN)
 DC.B ‘TYPE’;fType (OSType)
 DC.W 0,0 ;vRefNum,version(INT)
SFILENAME:DCB.B  63,0;fName  (STRING[63])

;     The Launch Pointer Record     

LAUNCHPTR:DC.L 0 ;Ptr to the  ;FileName
 DC.W 0 ;Mode (0 = ;standard  ;memory
 ;allocation)

;       Pattern Definitions  

GRAYPAT:    DC.B  $55, $AA, $55, $AA, $55, $AA, $55, $AA
BLACKPAT:  DC.B  $FF, $FF, $FF, $FF, $FF, $FF, $FF, $FF
WHITEPAT:  DC.B    0,0,0,0,0,0,0,0
 
;End of Program Source Code

MicroFinder Bug Fix

Shawn Mikiten

MicroFinder [June MacTutor 1-7] works well as long as you do not select a file on the other disk drive. The bug appears in the way the _Launch trap runs the application. The filename is properly passed but not the volumne the file is on. The _Launch trap will automatically attempt to run the application on the disk the MicroFinder was started from because the filename did not have the volumne specifier before it. The solution lies in the _Pack3 reply record. The variable vRefNum contains the disk drive number of the file when it returns from a successful call. Using the vRefNum value obtained, it is put in a parameter block for the File Manager call _SetVol. The parameter used is ioDrvNum. The following are directions for patching the source code so that it will work (See File Manager /OS/FS.A.1, page 26 & 33 in the new “Inside Macintosh” phone book.)

Add _SetVol trap value:

.TRAP      _SetVol               $A015

The code following _PaintRect is to be added:

_PaintRect

;   Launch Routine here

LEA          PARMBLK, A0         ;get pointer
LEA           vRefNum, A1           ; get addr. of vRefNum
MOVE.W   (A1), 22(A0)           ; put vRefNum into the
                                                               ; ioDrvNum 
parameter.
_SetVol                                            ; set it. (note A0 
points to
                                                             ; the param. 
block!)

LEA        SFileName, A1          ; get addr. of filename

Next, add the data structures necessary for the Reply record and parameter block. Add vRefNum in the Reply record:

SFREPLY:         DC.B      0,0           ; good, copy 
                              DC.B      ‘TYPE’    ; FType     (ostype)
 vRefNum:         DC.W       0,0          ;  vRefNum, version 
SFILENAME:   DCB.B    63,0       ; fname (string[63]) 

And now the parameter block, to be added after the WHITEPAT definition (Note that the file name pointer must be nil to force invocation of vRefNum inserted into ioDrvNum.):

;  standard 8 field parameter block for setvol.

PARMBLK:           DC.L       0            ;ioLink ptr.
                                     DC.W      0           ; ioType
                                     DC.W      0           ; ioTrap
                                     DC.W      0          ; ioCmdAddr
                                    DC.L         0          ; ioCompletion 
ptr.
                                    DC.W        0          ; ioResult
                                    DC.L          0          ; ioFileName 
ptr.
                                    DC.W        0          ; ioDrvNum

I hope this bug fix will offset the cost of the MDS software I am about to purchase. I havebeen using a friends copy and find it the easiest assembler I have used in 7 years of Apple II’s, Digital 2065, IBM PC and VAX computers!

[Shawn wins the $50 for being first with his bug fix. Thank you to the four other people who submitted a fix: Loftus Becker Jr. of Hartford, CT, who submitted a similar solution to Shawn’s; Tom Taylor of Provo Utah and Neal Lebedin of Palm Bay, FL., both of whom submitted similar solutions but slightly different from Shawn’s; And Paul Snively of Columbus, IN. in MacAsm...-Ed.]

More Bug Fix Comments

Loftus E. Becker, Jr.

The bug in Chris Yerga’s microfinder program (ID=26) is “failure to launch”. This stems from the fact that the lanuch routine will look for the named file on the default volume unless it is told otherwise. Hence, when the microfinder program is run from the default volume (usually drive 1) and tries to launch a program on drive 2, Launch gets the filename, doesn’t know it’s on drive 2, and tries to launch from drive 1!

Two points may be of some interest. First this is a bomb that is not trapped by Macsbug. Second, a similar bug appears in the MDS development system: If you are developing a program with the .asm, .link, and other files on the external drive, but the program itsef on the internal drive, an attempt to run it from the TRANSFER menu in the linker will produce the same error.My compliments on a magzine that has gotten better with every issue.

Alternate Bug Fix

Tom Taylor

This is similar in function , but uses the stack for the parameter block...

ioVQElSize         EQU   $40     ;io param blk length
ioCompletion       EQU   $C       ;offset (ptr.)
ioVNPtr            EQU   $12     ;offset (ptr. or nil)
ioVRefNum          EQU   $16     ;offset (word)

SUB.L    #ioVQElSize, SP    ;allocate block on stack
MOVE.L  SP, A0                        ;block ptr. to A0
CLR.L     ioCompletion(A0)  ; I always clear this
LEA         SFReply, A1             ; reply record ptr to A0
MOVE.W 6(A1), ioVRefNum(A0)  
CLR.L      ioVNPtr(A0)             ;clear name ptr.

_SetVol                                           ; go for it...
ADD.L      #ioVQElSize, SP  ; dump block

MacAsm Version of Bug Fix

Paul Snively

Apparently the standard file package, even though it automatically senses the presence of a second disk drive and, if one is present, gives you the “Drive” button in the standard dialog box, does not automatically change the default volume if the “Drive” button is hit. Where I come from, features like this are called “bugs.” In other words, as far as I’m concerned, the bug is in the standard file package, not Chris’ code

.
01150 *--------------------------------
01160 *        Launch Routine (MacAsm)
01170 *--------------------------------
01180          LEA     ParamBlock(PC),A0 ;File Man. param Blk
01190          LEA     vRefNum(PC),A1       ;Volume Ref Number
01200          MOVE.W  (A1),22(A0)           ;Move to paramBlock
01210          OST     SetVol                  ;Make the default volume
01220          LEA     SFileName(PC),A1   ;Get addr of file name
01230          LEA     LaunchPtr(PC),A0    ;Get addr of launch ptr
01240          MOVE.L  A1,(A0)                    ;Move pointer to name
01250          TBX     Launch                         ;And call Launch...