Letters

Startup Disk

David Dunham

I'd be willing to submit a DA that changes the default drive, but you should know that the default drive has absolutely nothing to do with the start-up disk [MacTutor, June 1985, p. 24]. To change the start-up disk, you'd need to close the open system file and open a new one. This could present problems, since the application may have handles to purged resources from the system file. I don't know what happens if the file's closed from under it. What are your writer's guidelines and how much do you pay? Nothing for tips in letters, I know from experience...

[Typical pay is $100 for a column. Another $50 if you become a regular contributing editor. We hope that some things (like letter tips) people will donate for the good of the cause; we only have so much $$ to go around...-Ed.]

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 Manager paramBlock
01190          LEA     vRefNum(PC),A1          ;Volume Reference Number
01200          MOVE.W  (A1),22(A0)             ;Move to paramBlock
01210          OST     SetVol                  ;Make the default volume
01220          LEA     SFileName(PC),A1        ;Get address of file name
01230          LEA     LaunchPtr(PC),A0        ;Get address of launch 
ptr
01240          MOVE.L  A1,(A0)                 ;Move pointer to name
01250          TBX     Launch                  ;And call Launch...

Don't Like Glossy Look

Warren Michelsen

I may as well comment on your new glossy look. In a word, YUCK! The gloss degrades the readability. The older stock could be viewed at any angle without glare. The older stock holds up better too; (they receive very heavy use as I refer back to them constantly). [We agree; how do you like this look? -Ed.]

Need Pascal Detective on this Bug!

Jack Cassidy

Put a MacPascal detective on this one! The program below causes a system error (ID=02). Needless to say, I discovered this bug in a much longer program and was very confused.

program SystemBomb;
type
   count = (one, two, three, four, five);
var
   simple:array[count] of integer;

begin
    simple[five]:=31;
end.

[We'll ask our resident guru, Steve Brecher to research out this one!]

Mental Starvation of MacWorld

Rick Barrett

AH! EUREKA,

This is the publication that I've been looking for. It's not glossy [well...-Ed.], slick, or condescending. It's meat, fact, it's wonderful! Keep up the good work...I've been rescued from the mental starvation of MacWorld.

Desperately Seeking Chief Wizard

James Muirhead

I was dissappointed to see Chris Derossi's Pascal Procedures column missing from the last issue. I was all psyched for learning window dynamics and then there was a no-show. His column is a must. Please let him know that he is sorely needed and most appreciated.

[Chris has stopped writing for reasons known only to him; perhaps your plea will awaken him...-Ed.]

MacTutor leaves me Codeless

R. Onzo

I have just recieved your complimentary issue of MacTutor and I must admit that it was an immediate sale. Your "Journal" is certainly unique compared to anything I've ever seen and the anticipation of finally being able to associate myself with a first rate tech journal leaves me almost "codeless". You've honestly made me feel like I've been trapped inside my Mac. You seemd to have just peeked inside, found me there tangled in the chips and guided me to the nearest exit showing me in the interum, the vast highways leading outward (and subsequently, inward). [Wow! we did all that? Thanks for those kind words...-Ed.]

Changing Basic Poke Codes

Terry Bartelmey

My print routines are set up with pokes to change PRINT to LPRINT and back. I have inquired with Microsoft as to the poke locations required for the Mac, but to no avail. Could you help? [YES! See Mike Steiner's column on the structure of a Basic Program. It has all the info you need to change PRINT to LPRINT under program control.-Ed.]

Imagewrite Cutesy, but...

David Haupt

It is cutesy to have the magazine printed out on an imagewriter but unprofessional in appearance. It is not as easy to read as a typset style woulld be. One would think that any magazine would be able to at least afford 7 grand for the Apple laser printer, wouldn't one? That would drastically increase the readability and the perceived professional level of MacTutor simultaneously.

[MacTutor is run by individuals, who, like any of us, are poor! Seven grand is seven grand, no matter if you publish a magazine or not! However, we have sacrificed the baby's milk money and now have the laser, after a three month delivery delay from Apple! How do you like it now?-Ed.]

Untested Code?

Inexcuseable is the only word for publishing untested code. Just plain sloth. Yet that is exactly what Robert Denny confesses to print [in the May issue]. I like his column on C, but I am startled at his lack of professional pride.

[ I think your letter was a little hard on us; Bob's code was taken from a much longer program that is running, but the code fragments were not re-assembled into a program just to test them specifically, hence the warning. -Ed.]