Letters

Using Mac for CAD

Bob Murphy

I agree with Paul Zarchan (“Workstation Potential of the New Macs”, March 1987) that the Macintosh II and similar 68020/68881 Macs can be used effectively for many CAD problems. However, the article uses the results from specific language implementations applied to a specific problem using a specific algorithm to make generalizations about the applicability of entire languages to CAD problems. One unjustified generalization is that FORTRAN and BASIC are fundamentally faster languages for simulations than C or Pascal.

It’s also important to consider all relevant factors in solving a CAD problem. For example, many cases the use of slower, higher-precision math lets you use a very efficient algorithm which can’t be used with faster, lower-precision math because round-off error would propagate to unacceptable levels. Generally, the speed increase due to the better algorithm more than offsets the slower math, so that the “slower” language implementation is actually faster for that particular problem.

Some languages have features which will improve the efficiency of simulations if they’re used properly. For example, sequential access of array values will usually be faster in C, if incremented pointers are used, than in FORTRAN using array indices.

When comparing two language implementations, one which uses SANE, and the other which does not, it’s important to recognize that hardware can play a big role in SANE’s efficiency. I did a very naive implementation of the benchmark in Lightspeed C 2.0 on a Prodigy 4, using none of C’s special features, and got a running time of 49 seconds, versus the articles 75. This may be due to the fact that I have the most recent Prodigy PROM revision, and Mr. Zarchan perhaps did not. Similar differences will be seen between the 64K and 128K ROM Macs due to changes in SANE. [And especially between the 128K ROMs and the 256K ROMs which have extensive SANE improvements. -Ed]

Still Need Word Processors

Anthony J. Oresteen

With all the recent interest and talk on the new wave of word processors for the Mac, I have yet to find a SINGLE word processor that can perform the following very simple task. What I need is a word processor that can create simple text files with lines not exceeding 68 characters and smart enough to remember to insert a carriage return when it auto wraps a line. Do you know of any out there?

Many of us have to talk to IBM mainframes that have archaic electronic mail and text editors. When I send documents to my mainframe, I am restricted to lines of 68 characters or less and each line must have a single carriage return. I write all of my reports on my Mac Plus and then send them out using SmartCommII. Many word processors let you set the line width. The problem is that when the line auto wraps, it does not insert a carriage return at the end of the line. Thus when I send the file, I cause a line overflow error with the host system with lines that auto wrapped.

Note that the MacWrite solution of inserting a carriage return at the end of every line if you tell it to when you save it as ASCII then ends up putting two carriage returns for lines separating paragraphs, which is unacceptable. The best solution I have found is to use QUED 1.53, setting the font to Monoco 12, line width to 68 and use show invisibles to find lines without the needed carriage returns. I have to insert the carriage returns manually. It’s a pain. I can have 24 point fonts, paste in graphics and print on a LaserWriter, but I can’t create simple ASCII files. Why?

[Your problem brings up an interesting philosophical debate. What you have discovered is that what you see is what you get is not always what you want! There are good reasons why traditional word processing was done the way it was; to provide maximum flexibility in the specification of how lines of text are to be constructed. Nearly all the Mac word processors make assumptions about the text and paragraph construction in an effort to get maximum flexibility while retaining the WYSIWYG philosophy of the Macintosh. Perhaps placing formatting information into the text stream is not such a bad idea after all! As for me, I like a quick and dirty bang the words in kind of word processor that doesn’t let the features get in the way of the typing. Which is why I’m writing my own version of MacWrite! I think the page layout features should remain in the layout program, not in the word processor. -Ed]

Goodbye Kiss

Michael Casteel

With the perspective of a professional programmer, I was a little disappointed in the Tech Note by Dan Weston in your February issue, correcting the bug involving a “goodbye Kiss” received by his published desk accessory code. Mr. Weston’s desk accessory crashed when receiving a goodbye kiss because he used a jump table which assumed that CSCode would always be between 64 and 73, but the goodbye kiss CSCode is -1. The Tech Note published a corrected listing which includes a special check for -1. The new code assumes that CSCode will always be either -1 or between 64 and 73.

I wish you would have taken the opportunity to teach good (defensive) programming techniques. There is absolutely no need for a program to assume the range of inputs to a jump table, when it is so easy to ensure it. Before using a jump table, a good programmer should range check the input and if it is not in the expected range, DON’T JUMP!

Just think, if Mr. Weston had applied this principle in the first place, the goodbye kiss still wouldn’t work, but at least his DA wouldn’t have bombed the whole Macintosh! Who knows what new CSCode values the Macintosh II might bring?

APDA Problems

Tim Cuthbertson

Your February issue contained a couple of favorable references to the Apple Programmer’s and Developer’s Association. I have had nothing but trouble in my dealings with them. I responded to their Ad in MacTutor last August, sending a $20 check to pay for membership. In September, I received only an invoice noting a credit of $20 to my “non-member” account. I waited a while to see if they would send me anything else, expecting membership materials or offers of products, but nothing. Finally I wrote a letter of complaint, but again, no response. I finally broke down and made the long distance phone call only to be told I had to call before 3:00, not ten minutes after.

I have stuck with my original 512K Mac for two years but the recent LS C upgrade seems to have rendered it obsolete. My 400K drives just don’t cut it. The local Apple dealer wants $798 to upgrade the machine they sold me for $2600 to a machine level that currently markets for $1900! That really hurts.

Professionally I am a Systems Analyst with IBM mainframe experience. But, I have become very frustrated trying to learn to program this [*darn*] machine. Your magazine and Scott Kanaster’s book How to Write [Debug] Macintosh Software are the only lights at the end of the tunnel. Keep up the good work.

[We have received several complaints about the slow response of APDA. Whenever you create a monopoly, as Apple has done with APDA, you create problems. APDA has simply been undermanned for the response it has received. It is easy for Apple to absolve itself of all responsibility for developer support and place it onto APDA’s shoulders, but quite another thing for APDA to try and cope with the problem. This may be a continuing problem for APDA as it sits between hordes of hungry developers and the fickle whims of Apple marketing.

Toolbox Tricks in C

R.J. Hall

I agree with M. Decombe’s letter in the February issue. A Trick Corner would be a most useful addition to your excellent magazine. In fact, here’s one of my favorite non-toolbox routines. Call it after dealing with a mouse down event when you want to check for a double-click. If the mouse is pressed again inside ‘inRect’ and during the double-click interval, the routine returns ‘TRUE’.

Check_Double(inRect)
Rect  *inRect;
{
 long   end_Time;
 Point  eventPoint;
 EventRecorddcEvent;

 end_Time = TickCount() + GetDblTime();
 while (!EventAvail( ~mUpMask, & dcEvent))
 if (TickCount() > end_Time)
 return(FALSE);  // OUT OF TIME

 if (dcEvent.what equals mouseDown)
 { 
 BlockMove(&dcEvent.where, &eventPoint,                  sizeof(Point));
 GlobalToLocal(&eventPoint);
 if (PtInRect(&eventPoint,inRect))
 {
 FlushEvents(mDownMask);  //Note!
 return(TRUE);  //DOUBLE-CLICKED
 }
 {
 return(false);
}

The routine ‘GetBdlTime()’ is defined in ‘Using the Macintosh Toolbox with C’ on page 201. By the way, there are several RMaker DITL items undocumented in the LS C manual. Try using the following: iconItem, picItem, userItem and resCltem! [There are several sources for RMaker documentation including the LS manuals, back issues of Mactutor on resource formats, Consulair C’s new manuals, and I believe Apple tech notes. -Ed]

Microsoft Explains MS DOS Limitations

Microsoft released a press kit today that explains the features of both its MS DOS 3.3 product and the new MS OS/2 product for the new IBM System /2 computers. As reported in the press, this new IBM operating system for the Intel 386 family processors is not expected to be ready until 1988! Why are we mentioning it here in Mactutor? Because it is instructive to understand the differences between the IBM System/2 model 80, a 386 machine, and the Macintosh II, a 68020 machine. These two computers are going to be going head to head with each other and a better appreciation of the Apple design can be obtained if you understand the background of the IBM machine. Apparently Microsoft has taken a lot of flack over MS DOS 3.x and has included some interesting product history on the Intel chip family that clears up many mysteries of the IBM personal computer while at the same time, brings a greater appreciation for the design of the Mac II.

MS OS/2 provides for up to 16 megs of real memory and 1 gigabyte of virtual memory. It provides for a priority-based pre-emptive multi-tasking scheme with inter-task communication. It supports both “real” and “protected” mode of the 286 and 386 chips, to help software compatibility, but multi-tasking requires applications be able to run in protected mode.

Now compare this with the Mac II OS which is available now. The Mac II supports 8 megabytes in 24-bit mode while the IBM family is generally limited to 640K up and down the line. In 32 bit mode, the Mac II will support up to 1 gigabyte although chip technology will probably make 128 megs a practical limit for real memory using 16 megabyte memory chips. And of course, we haven’t even mentioned the NuBus slots, which can support an additional 256 megabytes per slot in “super slot” mode. The next Finder will support a practical implementation of quasi multi-tasking that works up and down the Mac product line and does not require the PMMU memory management chip. And this will be released far before OS/2 is out. Finally, once the Mac world switches to 32 bit mode, a full priority based multi-tasking Finder could be provided using the PMMU in probably the same time frame as the release of OS/2. It is my guess that Apple is working to that end. The following history on the 8086 family is taken from the Microsoft press release.

The 8086 is Intel’s original 16-bit microcomputer. It included a number of features for backward compatibility with the 8-bit Intel 8080 that in many ways constrained its design. One of these is the use of a segment register from which 4 bits are added to the 16 bit offset to provide a 20 bit address. This limits the 8086 to 1 megabyte of memory, which is addressed not directly, but by manipulation of this segment register. Contrast this with the 68000 which has 24 bit address registers that can directly address 16 megabytes.

With their PC, IBM made certain fundamental decisions as to the memory architecture of the machine: they took the available one megabyte of address space and decided to reserve all the memory above 640Kb for use by the system. Within the 640Kb to 1Mb range lie such things as the ROM BIOS, the video display memory and other reserved areas. This is where the often discussed, and often misunderstood 640Kb limit arises: the DOS and all the applications software has to reside and operate in the 0 to 640 Kb address range: anyone who decides to use areas of memory above the 640Kb limit runs the risk of being incompatible with any future release of hardware or software products by IBM for the PC.

The 8086 has no memory or device protection inherent to the processor architecture. And the PC design does not provide any. This makes it very difficult to implement a multi-tasking operating system because many applications will directly reprogram hardware devices such as the system timer and floppy disk controller, and write directly to the video screen for better video performance. The operating system thus is unable to control the situation of two or more applications writing to the screen at the same time. Hence MS DOS 3.x is limited to 640Kb of memory and single-tasking operation.

The Intel 286 chip adds protection capabilities lacking in the 8086 and increases the memory it can address to 16Mb, same as the 68000. Unfortunately, Intel did not do a very good job with the 286: the additional capabilities are only available to programs which execute in so called ‘protected mode’ as opposed to ‘real’ mode which emulates the 8086 (including the 1Mb address limitation and no protection). Now the kicker! The real and protected modes of the 80286 are incompatible: software written to run in one mode will generally not work if the chip is executing in the other mode! In particular, MS DOS itself runs in real mode and thus cannot make use of either protected mode nor additional memory beyond the 640K barrier! If it had been made compatible with the protected mode features, then all the software base on the PC AT, and PC XT would not have run in that mode due to the incompatibility between real and protect modes. Thus the decision was made to defer support of protected mode until a later release of DOS. Contrast this “painted in a corner” situation with the 68000 family which is fully compatible up and down the line. But the situation gets worse.

One of the major incompatibilities between real and protect mode is that the memory addressing model changes! In protect mode, the segment register is interpreted in an entirely different way. Thus any application program which manipulates segment registers on an 8086 (and many of them do) will have to be rewritten to conform with the segment register usage rules of 286 protect mode. Hence an incompatibility problem exists trying to write software that both runs on PC’s and 286 based machines.

This brings us to the Intel 386 chip. This chip adds yet another mode of operation while also emulating both the 8086 ‘real’ mode and the 286 ‘protect’ mode architecture. The chip provides the foundations for building yet another operating system that could solve all the compatibility problems, but this is a significant development effort and the problems are certainly not solved by the chip alone. The modes of the 386 are real mode (emulates the 8086 exactly, 1 Mb address limit and segment registers and is the default mode of the chip), 8086 virtual mode (another 8086 emulation mode, but with a few protection features for supporting several applications each with their own virtual machine), 286 virtual mode (emulates the 286 protect mode) and finally, the only one of real interest, 386 virtual mode (allows full 32-bit linear addressing similar to the architecture of the Motorola 68000. )

The new OS/2 operating system will support 80286 and 80386 protected mode, virtual memory, multi-tasking and will solve compatibility differences across all machines running OS/2. And of course it includes a version of windows that uses overlapping windows instead of tiled windows. The IBM version of OS/2 is rumored to also include some mainframe communications support. Clearly, one of the reasons for the delay is they had to re-write the entire operating system! This should give Apple plenty of opportunity to continue to upgrade the Finder to provide the same capabilities, especially in the area of multi-tasking and virtual memory addressing independent of the applications running under it. Lets hope Apple takes advantage of the next six months to do just that.

Say That Again?

Phil Barnard

I hate your magazine.

I want you to know that MacTutor has been responsible for untold numbers of long and sleepless nights typing in published programs.

• I have had fights with the wife and kids for my continuous reading at the dinner table.

• I have had arguments at work with people trying to keep my MacTutors for themselves.

• I am reduced to programming in Forth to the exclusion of everything but eating and drinking.

Today I even had hassles wit the bank clerk rusing to convert Australian to US dollars for the enclosed subscription renewal! It really is all your and Jörg Langowski’s fault!

P.S. Well done!