Letters

Bugs to Watch Out For

David Smith, Editor

One of our readers brought to our attention, a glitch in Pagemaker that caused a line to disappear at the top of a column in the September issue of MacTutor in the "Pop-Up Window Scroller" article by Scott Boyd. At the top of page 51, left side column, the following line vanished on the LaserWriter output:

baseAddr:= QDPtr(NewPtr(sizeOfOff));

The following lines are "rowbytes:=offRowBytes" and "bounds:=bitRect;", which are ok as printed. Also, in the same column and page, watch out for another Pagemaker goof; the minus sign is printed way to the right of the column on the variable "-underRect.top" in the procedure OV_RestoreBits and might be easy to miss. Neither of these two problems show up on the screen; only on the Pagemaker output. We regret that we did not catch these problems. We assumed that Pagemaker knew how to print correctly, an assumption we are finding is not always correct.

Random System Crashes: SCSI Drives or Mac OS?

We recently purchased a Data Frame SCSI hard disk here at MacTutor and have been very happy with it so far except we have had a large number of random system crashes. Our system file is running about 550K and the disk is full to 17 Megs, with a Max2 2 meg memory upgrade. We can't tell if this is a problem with the Data Frame, the memory upgrade or the Mac. The crashes run two or three a day, in the middle of MacWrite or when trying to do a SAVE, and seem to have no pattern. We consulted with John Theurich at Coast Computer in Costa Mesa, CA. He is of the opinion that the random system crashes, which he has also observed in his system with a number of SCSI hard disk products, are due to a large system file with many fonts and DAs. He has found that reducing the number of fonts and DAs in the system file eliminates the random system crashes. This has been confirmed by some of his customers as well. If this is so, then it would appear that Apple's own software can't keep track of itself, and one of the main reasons for having a hard disk, for extra fonts, is unavailable! We find this very disturbing! If any MacTutor readers have any ideas or experience along these lines, please communicate them to us by phone or in writing so we can get a survey of how widespread this problem is and who is the culprit behind the problem. We have reduced the fonts and DAs, but the system crashes continue. We are now trying other Macs without the memory upgrade.

Another possibility is the menu snapshot fix for the cmd-shift-3 function key. The fix published in MacTutor in the August issue of MacTutor seems to foul up the menu manager because it calls GetNextEvent. The event loop and the menu manager are very closely tied together. We have observed some unusual font changes in dialog boxes after printing that seems related to this fkey fix. We recommend not using the fix we published. Instead, we have tried the Apple installer script that also fixes the menu snapshot problem but without the menu manager problems. We have since removed that init function also while we track down the cause of the random system crashes.

Apple - DEC Link

Kinetics Inc. has come up with hardware to link Apple and DEC networks. Their $2500 FastPath / Standalone is a programmable gateway between AppleTalk and Ethernet, letting computers share common applications. The $1800 FastPath / Q-bus is an AppleTalk controller board for Q-Bus backplanes, dual-height, allowing DEC's MicroVAX to use Apple's LaserWriter and other peripherals over AppleTalk.

Some software support for VMS, UNIX and Ultrix operating systems is already available.

For VMS: AlisaTalk from Alisa Systems (Pasadena CA) lets VMS/VAX systems provide transparent file services and LaserWriter print spooling for Macs, connecting VAX-based apps to the LaserWriter for printing of PostScript docs. [Note: This is Bob Denny's company and is the result of work he has been doing for Apple for the last year. -Ed] Helix/VMX data-based applications environment from Odesta (Northbrook IL) gives multiple Macs network access to VAX-based info processing and storage.

For UNIX and Ultrix: TOPS from Centram Systems West (Berkeley CA), a distributed file server that also links IBM PC systems, provides client and server functions. Ultra-Office from LBA (Culver City CA) office productivity & info mgmt system has mail service, terminal emulation, file library, disk server and print spooler functions. Two from Kinetics: K-TALK software implements AppleTalk protocols for Ultrix and UNIX including programmers' libraries, and K-Term, a multi-window terminal emulator gives Macs VT100-like terminal access via AppleTalk.

C Here

Jason De Mont

I recently acquired a June '86 copy of MacTutor and found it to be very worthwhile. I have a Mac+ and Lightspeed C, and especially enjoyed Bob Gordon's article. Please print tutorial articles on C, the toolbox interface and using utilities such as Resource Editor and FEdit. P.S. Keep up the good work!

Keyboard to Quickdraw

William Dellal

I am trying to use TML Pascal to write some utility programs but am having difficulty writing a procedure that allows keyboard input into a regular Quickdraw window. In other words, I want to create a "read" function for the keyboard that will operate in a regular window as opposed to the "plain vanilla" mode of TML Pascal. I know that I can intercept keystrokes using the Eventloop, but then I have trouble backspacing and echoing the characters properly. I believe that something can be worked out using Textedit procedures, but I have not been able to master them. [I suggest you see the Keyboard Slueth article in the August issue of MacTutor. And the multi-window text editor in this issue. -Ed.]

Programming Editors

The Midnight Hacker

Speaking of programming editors, I've tried Edit, QUED, Fast Eddie, and MEdit. Fast Eddie 2.1 is mostly weird, especially with the menus. QUED 1.5 has many useful features, including good window handling and split screens, but QUED cannot integrate with Mac C (it crashes!) MEdit 1.5, which is shareware for $25 is a great macro editor. It's a little weak in window handling, but the author Matthias Aebi, who lives in Switzerland, says he's going to improve that in the next version.

TML 2.0 Compiler Bug Workarounds

Michael T. Brand

Having just spent the last week updating my latest development effort (>5000 lines of Pascal) from TML Pascal v1.0 to v2.0, I thought a few of your readers might be interested in a few apparent compiler bugs and workarounds I discovered in the process.

1) The compiler sometimes reports an error indicating that a referenced subroutine was not completely defined. The error message is 'Forward declared subprogram "name" not completed in previous block'. The referenced subprogram is often one which is in a unit 'used' by the routine being compiled. This error seems to be sensitive to the calling order of subroutines defined within and outside the unit being compiled, or on the ordering of some lines. This appears to be a false error indication, and can be ignored. I've found that it's possible to configure the program to eliminate the problem, but it can take hours to find the lines the compiler finds offensive. I've included a sample program which exhibits the problem.

2) The case function has a problem if the selector expression is anything other than a simple variable or constant. If the selector is a function result or even a compound expression such as

var a,b : boolean;
  :
  :
case a and b of
  :

this line will cause a system level bomb, typically with system error ID+10, a divide by zero. To work around this problem, simply compute the complex expression to using the result in the case statement.

3) TML Pascal v2.0 introduces a new function which is intended to mimic the Toolbox function BitAnd (and unfortunately uses the same name), in a more efficient manner. This function does not work properly with a longint type of variable. In the following expression

var a,b : longint;
  :
  :
a :=BitAnd(b, $FFFFFF00);
  :

the upper half of a will always be zeroed, independent of the value of b. A simple way around this is to use the Toolbox function BitAnd. However, note that the InLine expression for this function (as well as BitOr, BitXor, and BitNot) is not in the MacIntf.pas source file. They must be added to this file (or your own file). Their associated trap addresses are $A858, $A85B, $A859, and $A85A, respectively. I renamed them BitAnd0, BitOr0, BitXor0, and BitNot0 in order to distinguish them from the Pascal versions. I have not tested the functions BitOr, BitXor or BitNot.

4) The compiler directive '{U<' is intended to allow libraries to be linked to a new segment, rather than the same segment, as with the '{U' directive. The compiler does not seem to distinguish between the two directives, however, interpreting '{U<' the same as '{U', and therefore it does not add the 'new segment' symbols to the link control file. A simple workaround for this is to replace each line of the form

{U< libraryname}

with the two lines
{U<}
{U libraryname}

This will add the appropriate symbols to the link control file.

I don't pretend to have done a thorough review of the version 2.0 update, but these modifications got my program humming along again. I've spoken with Darryl Lovato at TML about these problems and sent him a copy of this letter.

This one compiles ok:

unit unitA;
INTERFACE
 procedure routineA1;
IMPLEMENTATION
 procedure routineA1;
 begin
 end;
end.

This one compiles ok too:

unit unitB;
INTERFACE
uses unitA;
 procedure routineB1;
 procedure routineB2;
IMPLEMENTATION
{---------------------------------------------}
 procedure routineB1;
 begin
 end;
{---------------------------------------------}
 procedure routineB2;
 begin
 routineB1;
 routineA1;
 end;
end.

This one generates a compiler error:

unit unitC;
INTERFACE
uses unitA;
 procedure routineB1;
 procedure routineB2;
IMPLEMENTATION
{--------------------------------------------}
 procedure routineB1;
 begin
 end;
{--------------------------------------------}
 procedure routineB2;
 begin
 routineA1;
 routineB1;
 end;
end.

This is the error:

unit C.pas
 28 end.
   ^1

(1) Forward declared subprogram "routineA 1" not completed in previous block.

Stolen Update Events Returned

Peter J. McInerney

This is just a short note to clear up a fundamental misconception about the handling of updates that appears in Scott Boyd's "Pop-Up Window Scroller" (Vol 2 No 9). He says that he wants to prevent OverViewSelect being called if there are any pending Update events for the front window. He says this is accomplished "By doing a BeginUpdate and an EndUpdate for FrontWindow", and sure enough that is what appears in the program, commented as stealing the update events. It does nothing of the sort (in fact it does nothing at all, practically speaking). According to Inside Macintosh "BeginUpdate replaces the visRgn of the window's grafPort with the intersection of the visRgn and the update region and then sets the window's normal VisRgn". Disassembly of these routines in ROM reveals that this is exactly and only what these routines do. They do nothing to the event queue and do not even require that an update event has been previously posted. You could for example call your Update routine at any time to redraw your window, without passing throught the event loop, provided the update region had been altered to reflect the region required to be redrawn (there is no particular reason to do this, by the way). A further consequence is that if the window to be updated is genuinely the front window, then omitting the BeginUpdate and EndUpdate should have no visible effect when the window is redrawn (again this is not a suggestion).

Since Scott's program works, either his argument about updates for the frontwindow is wrong or he has been lucky so far. Assuming he has been lucky, how could he steal the update events as required? There are at least two methods that would work. One way is to call FlushEvents with a mask set just for Update events. In the circumstances of this program I don't think any problems should arise, but the possibility exists (because of their low priority) that update events for other windows might be erroneously discarded. Another method, which avoids this problem, is to InvalRect the portRect of the window and let the events take their course. In fact, it is almost certain that neither of these actions is necessary. Update events are primarily a mechanism for the window manager to handle overlapping windows, and unless you are moving windows around, you have to work hard (with InvalRect and InvalRgn) to generate them. I don't think there are any Quickdraw routines that by themselves generate updates or change the update region of a window (if anyone knows differently I would like to know). ScrollRect seems at first glance to be an exception, since one of its parameters is given as a region called updateRgn. But this is not the update region of a window (unless you say it is) and is merely the region you may wish to update (using InvalRgn) if you want. This last point seems to have confused more than one person. I recall seeing an example program (I think from Apple) in which the updateRgn which didn't need to be redrawn after a ScrollRect was operated on by a ValidRgn to "increase performance".

I hope the above clears up the mystery somewhat.

Mouse Droppings Editor

Phil Russell

Since I live in a small coastal town, I am the resident computer resource person - by default, I assure you. I often get calls from people with questions about computers. This morning a woman called saying she had just bought a Tandy, and she hated it already. What could I say? Right! "You should have bought a Macintosh."

In another instance, a local IBM true blue believer walked into The South Lincoln News after looking at the first edition [of Mouse Droppings] containing Macintosh/LaserWriter+ text.

"That's not done on a computer," he says. "I know printing, and that was typeset." I set ALL text for the paper on the Mac, and run all text and ads on my LaserWriter+. Ain't that a gas?

It's fun being a Macintosh fanatic.

Credit Where It's Due

Andrew Shebanow

It would be nice if you could mention sometime that IMLib [FinderParams.c, the parameter ram asm routines used in Frank Alviani's "Bath Document Spooler" in the September issue of MacTutor. ] is now being distributed, in a highly improved form, as an integral part of Consulair's Mac C product.

Also please be aware that the information about the IMLib library you published in Mousehole Report was incorrect: the library was written almost entirely by me, not by "a bunch of guys from the BMUG Developers Group." Although I am a member of that group, IMLib was not a BMUG Developers Group project. It was just something I did on my own which grew out of my own needs, and became a complete library out of some strange desire for completeness on my part.

Good luck with your magazine.

Crash Avoidance

Jim Matthews

I enjoyed meeting the MacTutor crew at the Honolulu Computerland show - so nice to see people from the Mac Community this far out in the ocean. I wanted to follow up on a programming tip I mentioned to Dave: passing the address of a resume procedure to the InitDialogs call. In every programming example I've ever seen, and in most commercial software, the programmer passes NIL to InitDialogs. Thus, when the program inevitably crashes, the Resume button in the SysAlert is dimmed. This is discouraging to both users and developers, since there is no recourse but a time-consuming and ramdisk-destroying reset. For developers, however, the solution is very simple. Set up a procedure that does nothing but call ExitToShell, and pass its address to InitDialogs (c example follows):

void resume()
{
 ExitToShell();
}

And, instead of

 InitDialogs(OL);

write

 InitDialogs(resume);

More often than not, this simple step will let you exit from crashes gracefully, restarting the Finder, Switcher, the Aztec shell, the LightSpeed system, or whatever shell you are working under. It also tells end users that their misfortune was not so great as to require a total reboot - they can just start the program again. It's a shame that MacWrite, MacPaint, etc., do not take this precaution, but at least future programs can take advantage of it.

User Warning About MacUnderground

Craig A. Shelley

I feel a personal obligation to warn the community of Mac users to use extreme caution in dealing with MacUnderground, also known as Online Publishing Incorporated. I sent them an order for a 20 MB SCSI disk drive in May. They spent the money without shipping us a drive. They claim they don't even have enough funds to give us a full refund. I encourage other Mac users that have had such dealings with MacUnderground to call their local Postmaster so that they can receive the form to file a report with the criminal investigation section of the U.S. Post Office in Chicago. [NOTE: We followed up on this. Mr. Shelley did order a Peak 20-meg SCSI hard drive for $827.92 from MacUnderground in May of this year. The facts above are correct. After numerous calls, a registered letter and initiation of court proceedings, MacUnderground has agreed to reimburse Shelley $100 a week, including about $25 extra for his calls and trouble. He is owed $552.92 as of this writing, and has since purchased a drive from Mirror Technologies. We also called MacUnderground (Fairfield Iowa) several times but received only busy signals.- LGM]

Wanna Write An Editor?

James G. Haberly

I think MacTutor is in a position to perform a large service for the users, and it is one that no other magazine or group is likely to be able to do even if they had the inclination.

All programmers, whether they work on a mainframe or a micro, have a favorite editor. They always cast aspersions on all other other editors (even while secretly admiring some of the features), proclaiming that theirs is the only one that can really do the job.

What I would propose is something along the following lines. I can supply a module that supports all of the common text editing features: multiple windows, the cut/paste group, scrolling, opening and saving files, and then add one more thing. A command line. Anything typed on that command line would be assumed to be in the form of "command name" followed (optionally) by some number of arguments.

An article some time back talked about something that the author called "function resources". That has definite advantages. They are easy to make and do not require linking.

Each "external" command could be given a particular signature that would identify it as a command. I have been linking .Rel files and producing "code" - lowercase intentional - files. The main module would look through the various folders to find anything that matched the command name. (Thanks to MacTutor's articles, this is now a trivial task). If it found something, it could lock it in memory and pass the parameters on the command line to it. If not, then an "unknown command" alert would be generated. The external command would also be given information about the current window state and a TEHandle.

Why would anybody want to do this? Because they can then add their favorite commands to an existing editor! It will not matter what (compiled) language they prefer to write in. What single person has time to write a full-featured editor and then give it away? A group, however, is a different story.

Where does your magazine come in? Coordination. With your circulation, there will be people sending in the commands that they find useful. (If necessary, contributions can be directed to me for sorting and testing). Have you ever met a programmer who didn't think that his method of working was the best possible? Most of the ones that I know are quite willing to show me how to do things their way, even when my interest level is negative.

Why would your magazine want to do this? The primary purpose would be to help the Mac programming community. An editor which 6000 people have an opportunity to participate in building should have features galore. (Of course if you happen to make a little bit of money sending out source code disks with the latest and greatest commands, nobody is likely to complain).

In any case, please take a little bit of time and think about the idea. Who knows what your readers could come up with if they were given a little bit of encouragement and leadership?

Fix For Reminder Program

John McMullen

In MacTutor's August '86 Mousehole Report, a reader signing themself "The Toolsmith" wrote of problems experienced with a reminder program downloaded from a BBS. Although the name of the program was not given, it is possible that it is an early demo version of one of our products - Smart Alarms.

The problem described is probably due to the way Smart Alarms, at least in that early version, searched the HFS directory for its Reminder file. The search was made by using a _OpenWD call before searching each directory and a _CloseWD call when through with that directory.

Versions of the Finder released shortly after this version of Smart Alarms became confused because their working directories were being closed behind their backs. Of course later versions of Smart Alarms and its Demo do not have this problem.

The only possible solution is to replace the system file. Possibly the Installer terminated with an error after partially installing. The latest version of the program is 2.1 Enquires should be made through the U.S. publisher and distributor: Imagine Software, 2000 Centre Street, Ste. 1260, Berkeley CA, 415-841-0278.

Copy of Letter to Apple

Kim Hunter

Apple has announced version 2.1 of Macintosh Pascal, as a free upgrade to previous owners of the original Macintosh Pascal. A call to the most competent Apple dealer in my area indicated they [the dealers] knew nothing of this product update.

This occurred at the same time Think Technologies has released Lightspeed Pascal. You are probably not even aware that Lightspeed IS Macintosh Pascal, vastly upgraded to a highly perfected programming environment. I just received my copy and it is an excellent, well-supported product.

Also at this same time, TML Systems has released version 2.0 of the TML MacLanguage Series Pascal programming system. The original TML version was the first real Pascal programming environment for the Macintosh. I have the original version and have ordered TML version 2. TML supports their products.

Also at this time, Borland International has finally announced TurboPascal for the Macintosh. I have ordered TurboPascal and expect to get the same excellent support I had with Apple II Turbo, and PC version.

Rumor has it that Apple intends to release MPW (Macintosh Programmer's Workshop) and beta copies are circulating. I have copies of code written for MPW, but do not have the compiler, and don't intend to get it.

I urge Apple to discontinue sales under its own label, and to release the products back to the original writers if they wish to sell them. Apple doesn't do a good job in supporting software, and Apple does a disservice both to its hardware customers by perpetuating products with no technical support, and to third-party software developers who are offering competent products. Naive computer buyers are lead astray by tending to think that products with "Apple's blessed label" may be superior because they are the first available, a noble gesture, but they hang around too long. Of course, MPW doesn't fall in this category, and therefore seems to have no purpose in Apple's strategy.

A company that wants to climb to the top has to stop shooting itself in the foot. [Funny you should put it that way didn't I see an editorial about that very thing somewhere? We agree with this sentiment and are not even sure MPW is really necessary Ed.]

No-Stick Label Printer

Charlie Jackson

I enjoyed your Viewpoint (MacTutor, May 1986) about the shortcomings of the Macintosh as a business computer. Much of what you said was right on target. But in response to your detailed exposé of problems with printing labels, I would like to call your attention to our program, Silicon Press. It is an extremely flexible label printing utility that addresses all the problems you mentioned and much more.

Silicon Press can print any size label, as many across as you want, allows you to mix graphics and text freely, merge-prints from a text data file or directly from an OverVUE file and prints in color on an ImageWriterII. It never rolls the platen backwards, avoiding almost all problems of getting labels stuck inside an ImageWriter. It allows you to manually set the page size or it sets it automatically to the label size if you chose "Continuous" forms.

More on MacFORTH

William Hole

Thank you for your response to my previous letter concerning the lack of MacForth coverage in your otherwise wonderful magazine. It was a pleasant surprise to find an editor willing to take the time to respond to one of his readers personally.

Your letter happened to arrive the same day as the September issue of MacTutor. I was very pleased to find MacFORTH addressed in Jörg Langowski's column in that issue. His description of MacFORTH Plus was especially interesting: our company is a beta site for this product, and it is a significant step forward. One feature not mentioned in the article is the fact that MacFORTH Plus shares a common kernel with other CSI 68000 FORTH kernels including Multi-FORTH for the Amiga, the Atari ST, and OS-9 68K and Unix systems. This provides a level of portability not normally found in Forth systems without sacrificing the Mac-specific features we've come to depend on.

In regards to your comparison of MacFORTH and Mach 1: I am always glad to see quality software, especially development systems, become available at reasonable prices. We were very excited here to obtain a copy of Mach 1 for that reason. We evaluated it carefully and decided to stay with MacFORTH.

I don't want to get into all the reasons we were unimpressed with Mach 1, because bad-mouthing contributes nothing and I have no reason to try to get anyone to switch from an environment they find useful. Mach 1 is a good product and is unquestionably a bargain, but we find MacFORTH to be a more mature and usable system. When you're spending hundreds of man-hours developing software products, the difference in price between Mach 1 and MacFORTH is insignificant compared to the savings to be realized by using a truly professional development package.

Lightspeed Not .Rel Compatible

Dave Roberts

Okay, guys. I just don't understand it. A few months ago, everybody and their brother is jumping all over Microsoft's back for not having their Fortran be MDS .Rel compatible. Then, starting a few months back, everybody had begun to tout Lightspeed's stuff. Although it sound great (read fast), it isn't .Rel file compatible. There is a convertor, but... Anyway, far be it from me to stand in the way of progress, but I think it would be good to start getting a consistent, if not united, front. I personally thought it was a great idea to have a .Rel standard so you could link different languages. Being able to write in MacC and use TML for filter procs and so forth would be nice to avoid glue (but with MacC 5.0 and its "pascal" function definition, I guess that also became irrelevant).

If the reason that everybody is switching is speed, I can somewhat agree, but if it's for the HFS issue, as David Smith suggested in the September issue, I think it would be nice to standardize on a single system.

As a solution to the HFS problem, I suggest the idea of being able to specify a path name (as in the MacC path manager) or, if no path is given, having the appropriate program do a complete downward tree search, starting from the folder that the searching program resides in. Though I don't have HFS or a hard disk, it seems to me that most people would probably have their sources, includes and libraries in folders that were subordinate to their programming system files folder (the one that contains Edit, C, Link, the Exec, or whatever). In fact that is the way Consulair hints at in the Path Manager documentation. Just thought I'd throw in my two cents.

[Okay, here is my two cents. The Fortran compatibility is needed because of limitations of MS Fortran that make creating an ASM source file and assembling it under MDS or Consulair C, a highly desirable feature, but it can't be done because the run time subroutine is not linkable under MDS and MDS routines are not linkable under Fortran. A catch-22 situation. The LightSpeed Pascal system is complete. It can produce any type of code, and so there is no reason to go from LS back to MDS. As long as MDS routines can be moved into a project, you have everything you need. I've tried to hold to the MDS ".Rel" file standard, but Apple has effectively killed that with the design of MPW, so now we have no standard and that is unfortunate. It's every compiler maker for himself now. -Ed]

Serial Port Help

Glen Leatherman

1) The book "Assembly Language Primer for the Mac", by Keith Mathews for The Waite Group, although simplistic and thorough as stated in your review in the May issue, sometimes takes things for granted, as if they were just reviewing what should have already been known. Also, the lack of appendices and even a glossary make it difficult to find out something you are unclear on. A great remedy for this lack of reference material is the second volume of Macintosh Revealed, by Chernicoff.

2) I know many programmers struggling with the serial ports, trying to get the darn modem working with their programs. So, in keeping with the trend to base the monthly issues on a particular theme, how about a Special Telecommunications Issue? Or is it just too long to fit on the cover?

3) A friend has the new Lightspeed Pascal package and says it is really fantastic. Any plans to base some articles on it? [The Intermediate Mac'ing column uses LS Pascal. -Ed]