HFS Issues and Answers

By Mark McBride, Miami University, Oxford, Ohio, MacTutor Contributing Editor

This month's columns covers a variety of topics and issues, some of which I have come across and some which readers of MacTutor have sent in. Readers can contribute easily by sending suggestions for future column topics, bug finds, or general questions about programming the Mac in Fortran. Send all inquiries to me care of MacTutor. Now, on to the topics.

Version 2.1 and the Mac+

A more correct title for this section is Version 2.1 and HFS. As reported in MacTutor (Vol. 2 No. 5 May 86), Microsoft Version 2.1 does not work with HFS. [See Microsoft's reply in the box at the end of this article. -Ed] The compiler eventually gets lost in locating its files, even when all files are on the desktop and no folders reside on the disk. But do not completely despair, because you can run V2.1 on the Mac+ and on a rom upgraded 512k Mac if you use MFS under Finder 4.1.

To convince myself of this, I conducted a test of V2.1 on several machine configurations. I used four different machine configurations. Table 1 summarizes the results. In the following configurations, MFS system refers to MFS formatted diskettes with the old system (pre-Version 3.0) and Finder 4.1, while HFS system refers to HFS formatted diskettes with the new system (Version 3.1.1) and Finder 5.2. All tests were conducted with MS Fortran Version 2.1.

Configuration A was a 512k Mac with the rom upgrade and a two disk (400k each) MFS system. Configuration B was a 512k Mac with the rom upgrade and a one disk (800k) MFS system. Configuration C was a Mac+ with a one disk (800k) MFS system. Finally, configuration D was a 512K Mac with the rom upgrade and a one disk (800k) HFS system.

In case the reader was wondering how an 800k MFS system was created, here are the steps necessary (This tip was passed to me by Absoft tech support. Absoft tech support hadn't tried this, but it was suggested to them by another user):

800k MFS Diskette

1. Initialize an 800k diskette with the new system (3.1.1) under Finder 5.2.

2. Boot a system disk with the old system and Finder 4.1.

3. Eject the old system disk and insert the initialized 800k diskette in the 800k internal drive.

4. Choose 'Erase' from the 'Special' menu of Finder 4.1.

5. Move the old system, Finder 4.1, MS Fortran, and all other files onto the 800k MFS diskette, then reboot. You now have an 800k MFS system for use on a 512k Mac with the rom upgrade or on a Mac+.

In addition to trying four different machine configurations, I also tried three different types of programs. The first program was the Shell program presented in MacTutor (Vol. 1 No. 12, November 1985). This program uses several toolbox routines and has an event loop structure. The second program was an old Probit regression program I transferred down from the mainframe. The code structure is sequential from start to stop. The reason for picking this program was that the program opens a data file on a disk using a hard-coded 'diskname:filename' in the source, i.e.,

open(25,status="KEEP",file="Probit.Data")

[Note: The standard JCL used on mainframes to link a Fortran file number with a physical device does not exist on the Mac. Instead, that association is done directly in the Fortran code with an open statement. -Ed]

The third program was the Probit regression program modified to use the 'stdfil' subroutine (see MacTutor Vol. 2 No. 2, Feb. 86) to get the data file name to open on the disk, i.e.,

ok=stdfil(1,'',fname,1,'TEXT')
if (ok) then
  open(25,status="KEEP",file=fname)
else 
  goto 13
endif

The reason for doing this was to check for the ability to run the resulting compiled and linked application under MFS or HFS using the standard getfile and putfile routines as used by 'stdfil', with the new ROMS!

As shown in Table 1, each combination of program and machine configuration is tested for compiling/linking, running under MFS, and running under HFS. The 'running under HFS' category meant that the fully compiled and linked program was moved over to an 800k HFS system and run under System 3.1.1 and Finder 5.2

As can be seen from Table 1, Version 2.1 will run under MFS, even on a Mac+ or rom upgraded 512k Mac as long as you stay with MFS. The major exception to this statement is that unmodified use of the MS Fortran supplied subroutine 'stdfil' will not work under MFS with the new roms. If the program requires a datafile name during execution, you can either prompt the user for the name using an input routine of your own design or attempt to modify 'stdfil' so it works with the new roms. Hopefully, all of this will be history by the end of summer with the release of Version 2.2, which has HFS compability. [Other apparent problems are you can't have more than three files opened at once or more than two files if you use the default printer file. This can be corrected by setting the linker z option for more heap space, or declaring a large array in a dummy subroutine. Also, the full listing option inserts a funny page control character that causes the imagewriter to go beserk ejecting pages, and hangs the Mac, when printing from Edit. So you can't print the full listing file, except from the compiler print option. -Ed.]

Debugging Event Loops

The source code debugger is one of the most useful features of MS Fortran. On many occasions, this debugger has saved me considerable time in locating a program bug. Eventually, as you develop Fortran programs using the Mac user interface, you will need to debug an event loop. If you try single stepping through the program, however, you will find that you cannot debug the event loop. This happens because the debugger has its own event loop and is processing all events. There is a simple and easy way around this 'apparent' problem.

The debugger has two types of breakpoints: soft and hard. A soft break point is set by moving the cursor (the left pointing arrow) to the source statement where you want to set the soft breakpoint. Once you set the soft breakpoint, then you can hit 'return' which executes all statements from the current statement (indicated by the rectangle box) up to and including the soft break point statement; or you can type 'command-g' which executes all statements from the current statement up to and not including the soft break point. A hard break point is set by clicking the number of the statement to be stopped at. Generally, in the process of locating the statement for which a hard breakpoint is to be set the soft breakpoint cursor also moves. Issuing the home cursor command (command-h) returns the soft breakpoint to the current statement. After setting the hard breakpoint(s), the proceed to breakpoint command (command-x) executes the program up to but not including the hard breakpoint statement. If you wish to stop at that same breakpoint again, always single step through the statement for which the breakpoint is set. This is necessary because the debugger clears any breakpoint set on the current statement when command-x is pressed.

Whenever you set a soft or hard breakpoint the debugger executes a send-behind on all its windows and effectively 'hides' itself until the breakpoint is encountered. Thus, by setting a hard break point at the call to the routine you are interested inside the event loop, you can get full processing of your event loop until you get to the breakpoint. When the breakpoint is encountered, the debugger issues a bring to front for the source code window and you are back in the full debugger.

By using soft and hard breakpoints, you can achieve several goals from within the debugger. Figure 1 illustrates the setting of a soft breakpoint near the start of the program to remove the default window MS Fortran creates. By setting the soft breakpoint after the call to FRONTWINDOW and CLOSEWINDOW and then pressing 'return' the default window is removed without bombing the debugger. Figure 2 shows the result of this process.

Figure 3 illustrates setting a hard break point within the menus subroutine of a typical event loop. Notice that the hard breakpoint is set after the call to MENUSELECT. If the hard breakpoint had been set for MENUSELECT statement, then you would be unable to track the mouse within the menus. Figure 4 shows the program running, with the debugger in the background, after issuing the execute to breakpoint command. Finally, Figure 5 illustrates the return of the debugger when the hard break point is encountered with the variable window showing which menu item had been selected. The variable window indicates that the second menu item of the Options menu (ID=32) had been selected, leading to the breakpoint.

Is handling of menu related events during debugging altered by the presence of the debugger menu? Surprisingly, and convienently, no. When the debugger is in the background and your menus have ID's different than 5, then there will be no problem. Judicious use of hard and soft breakpoints, particularly within event loops, can speed program development considerably.

Reader's Questions and Tips

Q: A letter from Edward Groth of Scottsdale, AZ arrived the other day. The two listings he included are reprinted as Listing 1 and 2. As can be seen, both concern problems with large arrays (approx. 90,000 elements). As Mr. Groth correctly states in the listings, the programs don't work on the 512k Mac with version 2.1, but do work under Absoft version 2.0b (the predecessor to version 2.1).

A: After conversations with Absoft technical support (who have always been helpful), the reason for the two programs not working was found: a serious bug in the compiled code which could potentially affect any array which takes up more than 32k of space. The bug does not always show up. For example, if Listing 1 is run under Version 2.1 on the Mac+, it works fine; as will Listing 2 if all integer declarations are integer*4 instead of integer*2. Again, however, Absoft tech support stated that the bug could occur for any array (real or integer) which occupies more than 32k of space. So if you are using large arrays, watch out.

I inquired about a work around or patch. There is no work around for this bug. Absoft said a patch would not be forthcoming unless the release of Version 2.2 is significantly delayed since 2.2 does not contain this bug (my beta-test copy of Version 2.2 ran both programs properly! ). As to why version 2.0b correctly handles Listings 1 and 2, but 2.1 does not, the core compiler routines which deal with arrays were completely rewritten between the two versions to improve performance [In other words, it's a new product! -Ed.]

Q: Mr. Groth asked a second question relating to the sequence of compile, link, Rmaker. The bottom of page 2 of the Rmaker manual supplied with MS Fortran states that Rmaker only works with resource sizes of 32k or less. Well, if you have to link the runtime before you add the resources with Rmaker (since the MS Fortran linker only understands output from the compiler), then it appears that only applications of size 32k or smaller can be created as a standalone application with resources added.

A: The limitation on Rmaker is due to a bug in the 64k roms (not the new 128k roms). Apple Tech Note #63 contains the full details (the Apple Tech Notes can be found on Compuserve's Mac Developer Maug, DL8). Evidently, bit 15 in the size of the resource is handled improperly causing any resource whose size has bit 15 set would be written by WriteResource as having size 0. Thus resources of size 0-32k can be written, 32k-64k can't, 64k-96k can, etc. If your application uses the toolbox routines WriteResource or GetHandleSize, you may want to look at Apple Tech Note #64 which gives a work around for the problem.

Tech Note #64 solves the problem for an application that uses WriteResource with the 64k roms, but does not solve the problem for using Rmaker and a compiled, linked Fortran application. However, a solution is straight forward. Instead of including the compiled, linked code using the include statement, append the new resources to the compiled, linked application. For example:

instead of:

Hilbert
APPLFORT

include: hilbert apl

.... (your resources)

use:

!hilbert apl
APPLFORT

.... (your resources)

This second approach also can be used to add resources to an unlinked application you are still debugging. By setting the 'APPLFORT' tags, the debugger will still recognize the compiled code.

Tip: Mr. Bob Andris of Saratoga CA writes in with a tip for attaching assembly language to your Fortran programs. If the assembly subroutine is compiled under the MDS, there is a simple and elegant way of getting the subroutine into the form that the Fortran linker wants. In the MDS Linker file, make the Output file name 'abcdef.sub' and then add a line you wouldn't normally have in an application's Linker File, namely '/Data'. The Linking and Mapping then produce a 'psuedo' application that is just the compressed DATA application you need. Just link it in with the Fortran linker. For example:

f YourProg
f abcdef.sub
l f77.rl
o YourProg

Thanks, Bob.

Q: Mr. Jim Bishara of Metairie, LA inquires as to whether there is an equivalent statement to the basic command FRE(-1).

A: The basic FRE(-1) command returns the number of bytes of available space on the Macintosh heap with MS Basic. The following code compacts the current heap zone, purges all purgeable blocks from the zone, then returns the number of available bytes in the largest contiguous free block in the zone. Be forewarned though, that all the space is unlikely to be available since some resources may be read back into memory the next time they are needed.

include memory.inc
integer*4 Grow

Grow=100

Grow=toolbx(MAXMEM,Grow)

After execution of the toolbox routine, Grow will contain the number of available bytes in the large contiguous free block. This probably is preferable to using FREEMEM, since FREEMEM counts all available bytes, whether contiguous or not. If the are any non-relocateable blocks in the heap, then not all the memory returned by FREEMEM will be available.

Other letters have inlcuded more tips, questions, and suggestions for future topics. Please keep the letters coming and I'll try to cover as many of the topics/issues as I can in future columns. Next month's column will cover using the print manager, pictures, and the deskscrap all in one graphing application! Till then, happy computing.

Listing 1

 program MEMTEST
 
 implicit none
 integer z,zsize,i,j
 virtual z(0:300,0:300)
 
 type "Array Size?  ";accept zsize
 
 do (j=0,zsize)
   do (i=0,zsize)
     z(i,j)=i*(zsize+1)+j
   repeat
 repeat
 
 write(9,*) 'Upper Left Corner  ',z(0,0)
 write(9,*) 'Upper Right Corner ',z(zsize,0)
 write(9,*) 'Lower Left Corner  ',z(0,zsize)
 write(9,*) 'Lower Right Corner ',z(zsize,zsize)
 write(9,*) 'Finished'
 
 pause
 end

*  This works right in Absoft V2.0b but gives incorrect values 
*  in MS V2.1 for the upper left and lower left corners when 
*  zsize is 219 or greater.

Listing 2

 program MEMTEST
 
 implicit none
 
 integer*2 z,zsize,i,j
 dimension z(0:400,0:400)
 
 type "Array Size?  ";accept zsize
 
 do (i=0,zsize)
   do (j=0,zsize)
     z(i,j)=i+j
   repeat
 repeat
 write(9,*) 'Finished'
 
 pause
 end
 
*  Listing 2 works OK with zsize of 218 or less.  With zsize 
*  (array size) of 219 or larger up to and including 300, the 
*  system crashes with the dreaded black bomb or worse yet, it
*  completely hangs after trying to destroy the machine. Try 
*  about 280.  This works fine in Absoft V2.0b for all values of
*  zsize<=300.  Obviously it should work on a 512k Mac but
*  does not do so under the official 2.1 MS Fortran.

Table 1

Machine Configuration

A B C D

Shell Program

compile/link yes yes yes no

run under MFS yes yes yes n/a

run under HFS yes yes yes n/a

Probit Version 1

compile/link yes yes yes no

run under MFS yes yes yes n/a

run under HFS no no no n/a

Probit Version (stdfil)

compile/link yes yes yes no

run under MFS no no no n/a

run under HFS no no no n/a

Configuration A: A 512k Mac, with rom upgrade, using two 400k disks with the MFS system.

Configuration B: A 512k Mac, with rom upgrade, using one 800k disk with the MFS system.

Configuration C: A Mac+ using one 800k disk with the MFS system.

Configuration D: A 512k Mac, with rom upgrade, using one 800k disk with the HFS system.

Microsoft Responds

This is in response to the May issue's complaint about Microsoft Fortran for the Macintosh. Microsoft is committed to making Fortran, as is the case with all our products, the best it can be. We appreciate MacTutor's criticisms, and are taking to heart all suggestions for improving the product.

Microsoft has received the first installment of the next version of Fortran from Absoft. Since then, we have been putting it through extensive internal and outside testing, and Absoft has characteristically been doing an excellent job of fixing bugs and implementing changes recommended by the testers. What will result from our thorough quality control process is another version of Macintosh Fortran that will best meet the user's needs.

We wish we could announce a release date, but that would be a disservice. Our philosophy is to work hard and release great products. One cannot accurately predict what changes will be necessary until after the testing is complete, and we will not release a product that is anything but the best quality. This next release and its timeliness, however, are a top priority. When available, it will have additional useful features as well as making full use of your new machines.

We want to straighten out one inaccuracy in the May Fortran column; Version 2.1 does work on the Mac Plus. You must use the old versions of System and Finder 4.1 on the Fortran disk. You cannot be using HFS folders.

- Ray Bily, Product Manager, Apple Languages, Microsoft Corp.