Letters

The Great French Cracker Scandal

Special to MacTutor

The French developer community is up in arms over the arrest and trial of one of their own, for hacking and cracking several copy protected programs distributed in France. Two years ago, a French hacker by the name of Nourallah Goulamhoussen, who operated under the pseudonym of Faraglace (maybe it means something in French!), pulled a “Simon Jester” move by cracking a pre-release of Silver Surfer, alias 4th Dimension, and Excel. He also played around with the start-up screens and logos, leaving cute messages behind. Unfortunately, he got carried away and left his real name in there as well. ACI, the French makers of 4th Dimension, lead by their president, Marylene Delbourg-Delphis, known as Madame DD, brought suit, joined by Microsoft Corp. and Apple Computer. The three heavy weights claimed damages of $390,000 for “copying the brand name and damaging the brand image.” Yesterday the verdict came in: Nourallah was fined $3,300 for the criminal offense and ordered to pay $83,000 in damages to the three “injured” parties. Since Nourallah is a student in Pharmacy, it is not clear how the three corporations plan to collect from him. Since 4th Dimension is now being distributed in this country unprotected, and Excel has been unprotected and cracked for years, the whole thing sounds like a tale from Alice in Wonderland. Unless you happen to be a Pharmacy student by the name of Nourallah Goulamhoussen.

Look What I Found!

The problem for Nourallah seems to be that he did this hacking and cracking a long time ago, back when we all knew very little about the Mac and it’s operation. What did him in, is that his cracked copies of 4th Dimension and Excel were picked up by three legitimate crooks, who collected pirated software, published a catalog of them and sold them for profit. Nourallah had no idea they were using copies he had cracked. The pirate catalog included MacWrite, MacPaint, and a lot of other protected software besides the two that carried Nourallah’s handywork in them. ACI and Microsoft went after Nourallah because “he made it possible for the other three to copy the programs”; in other words, as an example to other would be software crackers who break protected programs. Gee, if they tried to go after people like that here, they’d have to arrest half the country! (How many times have you used Copy II Mac or Hard Disk Utility lately?)

Everyone seems to agree the three bad guys deserved to be prosecuted, but what the French Macintosh community can’t understand is why they went after Nourallah? He had nothing to do with the three software pirates and certainly never profited from any of their activities.

French Software Madam

This “Madame DD” of ACI is apparently quite a character in this whole charade. At the trial, she summed up her feelings by saying “ from my point of view, those people are nothing but flunked-out developers, evil individuals , any turkey who spends enough of his time will eventually deprotect a product!”

Her opinion of the need for backup copies was expressed in another remark: “Oh, sure, some would like a backup of the key disk just in case Only the probability that the user destroys his key disk is almost zero and, in 9 out of 10 times, such demands come from dishonest people who want two disks for the price of one.”

The Madam also has a few words to say about a software company’s responsibility to replace defective media: “Nothing forces us to replace a program. If you crash your car or your Mac, the manufacturer won’t replace it, even if they are absolutely necessary for your work. You spill coffee on a book, you’re not going to ask the publisher to send you a new one, but you do it if it’s been a program. Why should software be treated separately?”

Get the idea that Madame DD is a bit behind the times? Rumor has it that ACI developed a list of people who had the ability to crack software protection in France so they could send them threatening letters. The fact that Apple and Microsoft were party to the “de-frocking” of Nourallah, who certainly did not have the means to adequately defend himself against such mammoth corporate power, has to send a chill down the back of every freedom loving programmer. Will some teenage software hacking come back to haunt you some day to the tune of $100,000? Simon Jester, you ever get back all the copies of your bootleg SJ disk #1?

What’s All the Fuss?

The final irony of this is the fact that the French version of 4th Dimension is a heavily protected piece of buggy software that crashes regularly. Nourallah’s copy was a very early pre-release version of this thing. Apple, and now ACIUS, has spent a year working to get the thing debugged here in the US and the product is so close to final release (shipping began the day this issue went to the printers) that one has to wonder “what’s all the fuss about?” There is talk in France of taking up a collection to help Nourallah pay his $83,000 debt, and hire a decent lawyer for an appeal. Certainly, Microsoft has to look pretty ridiculous in this thing, since Excel is not even copy protected over here. The idea that this poor student is going to make Bill Gates a little bit richer than his six billion dollars makes him now is a little unnerving. Bill, why don’t you make a charitable contribution, and forgive this guy his debt?

French Reaction

The French reaction was summed up on the CalvaCom bulletin board by Jean-Benedict de Saussure, who said, “That Apple helps to pursue those crooks who sell illegal copies, or those who use software which they didn’t buy, makes full sense. But that the consequence of this would be to crack down on a guy whose main fault is to have been intelligent enough to arrive at a level which others had never reached, that is hard to swallow.”

And finally, this remark from our Editorial Board member, Jörg Langowski: “Microsoft, Apple and ACI seem to have chosen to constitute an example of an individual who didn’t have the resources to defend himself. He played around with some software, trying to understand how it worked. His ‘handywork’ got in the hands of others, who without his knowing, made money from it. He was not tried for stealing software, but for making it possible for others to steal it. We are paying a ‘shareware lawyer’ and collecting for an appeal meanwhile, quite a few of us have decided to give up using the software of certain companies, especially since there are often cheaper, unprotected programs that do a better job.”

Have an opinion? Send it to:

Update on Lightspeed C & Pascal

Special to MacTutor

Let me take this opportunity to bring all of our MacTutor fans up to date on Lightspeed C and Pascal relative to the Macintosh II. We have been working very hard to get both products up to speed with both the new Macs and the new operating system.

Surprise! Everything you knew is now wrong, again!

What many people may not realize is that Apple really pulled a fast one on the developers when they released system 4.1. This system was completely different from the beta version system 4.0 that we were working with on the early beta Macintosh II machines, seeded to developers so they could port their software over. And what made matters worse, the production Mac II units turned out to be very much different from the pre-production seed models, and nothing at all like Inside Macintosh Volume 5 described. (I’m sure David Wilson can sympathize with this as he attempts to prepare his Mac II programming seminar!)

Last Minute Changes by Apple

We found that things that worked fine on the seed machines under system 4.0, now crashed on the production units under 4.1, especially in the area of the menu manager. Another problem has been the late shipping of a final version of the traps and equates files. As a result, we found ourselves calling Apple and saying, “Did you know the new system does such and such?”, to which they would reply, “Oh, really? Let me get back to you on that ” so obviously, even the people inside Apple were having trouble finding out just what changes had been made to the operating system in the new version.

Hurry up and wait

Apple figured those developers who had seed machines didn’t need the production machines as quickly as those without, so we got moved down the pecking order. We finally just went out to a local dealer and bought one off the shelf to speed up the conversion process. This wouldn’t have been a problem if the production machine hadn’t been so much different from the seed machine.

It didn’t help matters much either when Apple released system 4.1 to the public without any warning to developers as to the impact they could expect from the new system. At the same time we found things breaking under 4.1, we started getting calls from our customers that their software wasn’t working. It would have been nice if Apple had given the developer community some time to adjust to version 4.1 before making it public. It would have been even nicer if Apple had released documentation alerting us to the impact of changes under 4.1. But even Apple itself does not seem to have fully documented anywhere, the system changes we are uncovering in our development work.

Lightspeed C

The current version of Lightspeed C, 2.01, runs under system 4.1 on the Mac II but has some problems with the glue routines for the new system features. We have received the beta glue routines from Apple, the same as those being shipped with MPW and we are preparing interfaces to them for LS C. A new beta version of LS C with the new library interfaces will ship within a week. This upgrade utility will make LS C 100% Mac II compatible. The upgrade will be posted on Compu-Serve (it was posted the day this issue went to press) and will be available through our dealers, including MacTutor. Incidentally, these new routines have very little resemblance with Inside Mac Volume 5, so beware. Apple really needs to upgrade Volume 5 so that it reflects reality!

No Switcher With 4.1

One thing that is not supported by the new system is switcher. Apple has made extensive changes to the system dependent portions of the Mac so that switcher no longer works. Unfortunately we can’t do anything about that. Apple has made the decision to abandon switcher for now until their own future Finder upgrades are ready. This was probably to be expected.

We are also working on a major new release of LS C, beyond this Macintosh II correction, which will add significant new features. We don’t think that will be ready for the Boston MacWorld Expo, but are hoping to release it as soon as it is ready. Meanwhile, we will have a major new software tool for developer’s to show at Boston.

Lightspeed Editor’s to be Released

We are announcing the release of a new product calld capps’, which makes the Editor technology of the Lightspeed C and Pascal products available to developer’s both as a stand-alone library and as commented source code. capps´ is based on a software library called “PE” (Program Edit) that we created because the Macintosh Toolbox’s TE (Text Edit) package didn’t provide the performance or the functionality that we wanted for the integrated editors in THINK’s LightspeedC and Lightspeed Pascal. capps’ will also include a library called “grep” (who knows what the acronym means) that implements the fancy pattern-based search and replace features in LightspeedC. As you can well imagine, both libraries have been carefully crafted to deliver exceptional performance. Our languages depend on them!!

capps´ consists of the same PE and grep libraries actually used in THINK’s Lightspeed language products, complete documentation for those libraries, and two complete, ready-to-use standalone editors implemented using them. The first, PEdit, is a fully featured program editing application similar to the editor in LightspeedC. The second, “Apple Edit”, is a handy desk accessory style program editor. Machine-readable source code, extensively commented, is supplied for both editors. Versions will be available for both LightspeedC and Lightspeed Pascal users. The price has not been fixed yet but it will certainly be under $100.

LS Pascal

Lightspeed Pascal, version 1.0, does not work under the new system. However, we have been shipping a beta version 1.01 to all our customers who call and ask for it. This version runs on the Mac II if you use it as a traditional compiler; build the application first, then run and debug it externally from the LS shell. If you try to run your application under the LS debugger shell, our context switching from your application to the Lightspeed application causes the Mac II problems because we are not resetting all of the new system dependent globals that are context sensitive. The problem is, Apple won’t (or may not know themselves!) tell us all the system parameters that are context sensitive, and so we have had to dig them out by hand.

Context Switch is OS Dependent

Lightspeed Pascal works by doing something similar, but more sophisticated, than switcher. This is how your application can run while under control of the LS shell, giving it the wonderful source level debugging we’ve all come to know and love. But this developer friendliness comes with a price. Take for example the problem of the menu bar. For a context switch, you need to display one menu bar for the application, then revert back to the compiler’s menu bar. Normally you would do a GetMenuBar followed by a ClearMenuBar, but if you do that, you won’t be able to get your previous menu bar back correctly. The semantics of these operations have changed, partly because of the color additions to the menu manager. Apple has not documented these effects, and they really only apply to applications like ours that are trying to manipulate and control the system environment. We’ve had to disassemble the new ROMS to find out what the Mac is doing to us. If you are having problems in your own software development, look to the menu manager as one possible source, as that has been radically altered. Many of the changes are very subtle, and while Apple has been very cooperative when we call, we’ve had to do all the research to find those subtleties. A lot of reverse engineering has been done to make sure we have identified all of the context sensitive system parameters that must be reset when switching from the application environment back to the Lightspeed environment. MacTutor has asked us to identify some of the things we’ve found which may be of interest to other developers, and we will try to get an article out on what we’ve found.

New Pascal Beta for Mac II

The bottom line is that we have succeeded and are happy to be able to say that Lightspeed Pascal is just a few weeks away from a new beta release that will be completely 100% compatible with the Mac II and will support the new libraries. Like our LS C, we will have an upgrade utility that will convert Pascal to the new version.

We also are working on a major new release of Lightspeed Pascal with some exciting enhancements to our already user friendly debugging environment. There has been a lively debate in MacTutor about the various 32K limitations that the Mac segment loader imposes on development systems. Last month it was incorrectly implied that LS C cannot index arrays declared on the heap with NewHandle, greater than 32K. This is not true. LS C will work correctly in the same manner as was described last month for MPW C. The current version of LS Pascal, however, does not allow you to index a NewHandle array greater than 32K, but this is being fixed and will be available in the new major release of Pascal we are working on. That version will support indexing large arrays created on the heap just as C does.

Apple Needs to Do Their Homework

One thing that is needed from Apple is a statement about where the segment manager will go. Global variables are referenced relative to A5. While we could allow local variables to be declared greater than 32K, getting global variables and segments greater than 32K requires changes to the Mac operating system that only Apple can make, if we are to continue using the segment loader, which is our intention. We hope that Apple will be more communicative about how they plan to modify the segment loader and memory manager to move the Mac into the 32 bit world. If you have any questions, drop us a line on Apple Link or give us a call. We are fully committed to making our LS C and Pascal as powerful, friendly and compatible as possible with all present and future Apple products. As was reported last month, our phone and address have changed:

Apple Releases New Upgrades

Apple Press Release

Apple has released a new version of MacDraw (1.9.5), MacTerminal (2.2) and MacProject (1.2). They are available free from Apple dealers to customers who have an original disk with an original label. They have also said MacWrite (4.6) will be available sometime in August. No mention was made of MacPaint. The new versions have been fixed to work with the Macintosh II and SE. A few other additions were also included including the ability of MacDraw to use 54 fonts! In addition, the products are said to be AppleShare compatible. Draw, Write and Project are being turned over to Claris, the new Apple Software company (not to be confused with Acius with is marketing 4th Dimension). MacTerminal has been judged to be “system software” or something close to it and will remain within Apple along with AppleShare. A lively debate is also going on over HyperCard, the new Bill Atkinson data base product. Some say it should remain with Apple, others say it should go to Claris. The introduction of two powerful data base products (HyperCard and 4th Dimension), initially promoted by Apple Computer should heat up the software market in coming months.

MacTerminal Patch Update

Monty Solomon

The MacTerminal patch published last month incorrectly said you should change four instances of 02B6 to 0A78 to fix the BasicGlobs global parameter conflict. Actually, only the last instance, 0000 02B6, should be changed to 0000 0A78. The other references are not to the global variable location and may cause erratic behavior. [Get version 2.2 now. -Ed]

BlockMove versus CopyBits

Larry Rosenstein

I recently received the July 1987 MacTutor, and wanted to comment on a letter from Fernando Salazar on page 11.

His code, which uses BlockMove instead of CopyBits to manipulate bitmaps, is a good example of why programs do not work on new machines or new System versions. The reason MacPaint, FullPaint, etc. don’t work on a color screen is that they draw directly to the screen and bypass Quickdraw.

The code in the letter does not take into account the width of the bitmap bounds (which may be different from the rowBytes), the depth of the screen, the clipping, etc. He also does not shield the cursor, which is necessary if you draw directly on to the screen. (The result of this will be duplicate cursor images.)

I was able to get more than adequate performance out of CopyBits in my MacApp Paint program. It is interesting to note that this program works fine on a Mac II with any screen depth (although it works much faster with a 1-bit deep screen). On a MacPlus (and especially a Mac SE, which is 20% faster), the standard CopyBits can refresh the entire screen very quickly, if you take advantage of Quickdraw’s optimizations. In particular, you should use srcCopy mode, a NIL maskRgn, and ensure that the source and destination bitmaps are aligned at the same boundary.

The letter also talked about the 3K limit mentioned in Inside Macintosh. There are 2 things to consider here. First, is what Fernando Salazar alluded to. If you call DrawPicture of a picture containing a CopyBits call, QuickDraw normally will allocate a heap block to contain the bitmap. The reason is that bitmaps are stored compressed in the picture, and QuickDraw uncompresses the bitmap before moving it into the destination.

Because of this, a courteous application will generate a picture containing small CopyBits calls. If you break up a large CopyBits into a series of smaller ones, then the drawer of the picture will not need as much heap space to draw the picture. Applications that do this, should insert picture comments to indicate that the small CopyBits are really parts of one large bitmap. This is discussed in Technical Note #27, which deals with the picture comments understood by MacDraw.

The other question is whether CopyBits itself uses any stack space. My experience with MacApp Paint is that in some cases the answer is NO. My program calls CopyBits with large (55K) bitmaps and no problems. (I also do not reserve 27K of stack space.) Similarly, the Window Manager in the ROM uses a single CopyBits calls when you move a window on the screen, regardless of the size of the window.

In both cases, however, these calls to CopyBits use srcCopy mode and a NIL mask. Other uses of CopyBits, for example one with a non-NIL mask or one that requires stretching or shrinking of the bitmap, could conceivably require stack space. I am not familiar enough with the internals of QuickDraw to know the answer. Chris Derossi of Apple Technical Support, however, would know the answer. I would like to see him answer that question in one of his MacTutor columns.

32K Heap Arrays

George A. Nelson

I have followed with some interest the thread in the Letters column about 32K limit on static data. I have a solution to this problem that has helped others; it not only completely bypasses this limit, but shrinks affected programs by up to 32K, as well!

The Macintosh, unlike past personal computers, includes a Memory Manager that manages a large “heap” of free memory. The preferred way to make a large array is to request that storage from the Memory Manager, placing it in the heap, rather than on or above the stack. Thus , a program that currently has a problem with a 32K limit on static arrays can be fixed by changing:

 static int myArray[16000]; /* wanted 100000 */
 to:

 static int *myArray;
 main()
 {
 my Array = NewPtr( 100000 * sizeof(int) );
 if ( !myArray )
 error( “not enough memory” );
 ...
 x = myArray[27];/* e.g. */
 ...
 }

Note that (in C) although the declaration of my Array has been changed, none of the references to it are affected. The situation in Pascal is similar, provided the compiler does the correct address calculations. The situation in FORTRAN is (I think) a little harder; I know that it will work to pass the array as a parameter to the procedure that needs it.

NewPtr is the appropriate call to replace a static array. If there are several such arrays, or if their size changes during execution, NewHandle should be used instead (but know how, first).

How does this save 32K? All Macintosh compilers with which I am familiar, with the sole exception of Consulair’s Mac C, store an image of the declared static data in the application. (Consulair stores a compressed image.) By allocating the storage for the array in the heap at run time, we no longer need to store 32K of zeros in the application! The technique is worth exploiting even for smaller arrays, as long as they are not initialized to more interesting values.

ZBasic Woes

Ronald Lowrance

I have had so much trouble with ZBASIC, I feel I need to warn other Mac Developers. I have already gone through 4 very bugy upgrades and 1000 work arounds. I give up! Can anybody out there even get (v3.03+)

INDEX$D(element#[,index#])

to be recognized by the compiler? Jeff at Zedcor couldn’t help. After 3 phone calls, he finally told me he didn’t have a Mac to try it out; and could I mail them a example program. Have you ever called a company up about their product and had that feeling you knew more about their product than they did? The only answer I ever get is ‘get the next upgrade’. Well, I’m not going to. They can keep v 4.0. Forget ZBasic! I wish I never left MDS! [Dave Kelly likes 4.0! -Ed]

MS Basic Woes

Steve Meuse

Here is a compilation of the letters I’ve sent to Microsoft regarding problems with the Macintosh Basic Compiler 1.0:

* Files created by the compiler default to “Edit” as their creator. The interpreter by default creates files with no defined creator.

* The FILES(1) statement, with filespec omitted (or a null string) is documented as displaying all files on a drive, and the interpreter does this. Sometimes compiled code displays only text files under these conditions, and sometimes it works as it should. It appears to be a compile-time error, as a given compiled program behaves consistently: it either always works or always fails.

* When a program is running on the non-startup drive, the interpreter will find LIBRARY files in the root directory of the startup volume. Compiled code will not.

* I’m using a library called MIDIBASIC. The statement MIDIout X% AND F% works under the interpreter, but generates a type mismatch with the compiler. It seems the compiler isn’t passing an integer to MIDIout. The alternate statement, I% = X% AND F% : MIDIout I%, executes properly however.

* Run this test program:

********************
FOR i% = 1 TO 6
 j% =(i%-1)*20
 WINDOW i%,,(2+j%,41+j%)-(259+j%,179+j%),1
 BUTTON 1,1,”Test Button”,(20,20)-(239,40)
 NEXT

 LOOP:
 i%=DIALOG(0)
 IF i%=3 THEN WINDOW DIALOG(3)
 GOTO LOOP
********************

Under the interpreter, all is fine. When compiled, click on some windows to bring them to the front. Then click on windows 5 or 6 (the two rightmost windows). The compiler-generated program doesn’t redraw the buttons contained in these windows. The same goes for edit fields placed in windows 5 or 6. Also, windows 5 and 6 can’t be dragged.

* I’m using SaveArray to save user preferences into the resource fork between prgram uses. For some reason, repeated use of the SaveArray saves multiple resources with the same ID number. I worked around it using GetRes, RemoveRes, etc., but is this the way it should be?

* Using the CLEAR,xxx statement under the interpreter allows me to create a larger system heap, so I can process some medium sized bitmaps (Apple ][ bitmaps , actually). For some reason, this isn’t true in the compiler. I read the addendum note about only having 3500 bytes available for the clipboard- surely there’s a way to enlarge that, but it sure doesn’t seem to be CLEAR. Any suggestions?

* You might want to mention in the docs never to use CloseResFile if an application stores is resources in its own resource fork. This cuts off the program’s path to the quit code, and it hangs after the menus revert to File and Edit.

* I’m using System 5.3 with the appropriate Imagewriter system file. If I type Command-period while a printing job is executing, the Print Manager should simply close up shop and return to the application. This works well under the interpreter, but the compiled code often fails with an error #57. This happens with break trapping on or off.

A few observations:

* The string-to-numeric conversions are substantially slower when compiled. This test program:

********************
 DEFINT I-J
 START=TIMER
 A$=SPACE$(10000)
 FOR I=1 TO LEN(A$)
 J=ASC(MID$(A$,I,1))
 NEXT
 PRINT TIMER-START;” Seconds”
 WHILE MOUSE(0)=0 : WEND
********************

executes in 29 seconds interpreted, 224 seconds compiled. Instead of being 2-3 times faster, the compiled code here is 7-8 times slower!

* A smarter linker would be a boon. The math pack is linked regardless of whether math is actually used in a program. Naturally, nearly all programs use some of the common operators, but a good first step would be to link in the trancendentals only if one is used. I believe this could substantially reduce the final size of many compiled programs.

Microsoft employees have been polite in replying to these points, though there’s little they can say besides “Thank you”, and “We have no workaround at this time”. Anyway, there are some problems here I haven’t seen mentioned in MacTutor, so I wanted you to know.

LS Pascal & MemError

Mark S. Jennings

Users of Lightspeed Pascal (V1.0) should be careful of LSP’s tendency to reset the memory manager’s MemError variable behind the application’s back. For example, the following program (which attempts to allocate a gigantic block in the heap), correctly writes then memFullErr (-108) error number:

program LSPprob;
var
 h : handle;
begin
 Showtext;
 h := NewHandle (MaxLongInt);  {should always fail}
 writeln(MemError);  {should always write -108}
end.

However, the following functionally equivalent program when comp[iled with the debug option on indicates that no memory error occurred:

program LSMemProb;
 procedure WriteMemErr;
 begin
 writeln(MemError);  {writes 0 if debug off}
 end;
var
 h : handle;
begin
 ShowText;
 h := NewHandle(MaxLongInt);  {should always fail}
 WriteMemErr;   (should always write -108}
end.

If you turn the debug option off, it works as it should. Apparently when you have the debug option on, LSP calls the memory manager on entry to any procedure or function. This causes the MemError variable to be reset to zero and you lose the ability to check for memory allocation errors. If the code which checks MemError resides in a seperate module, you need to turn the debug option off in the called module only; the caller can still set debugging on.

LSP needs to preserve the application’s value of MemError (and possibly other error variables like ResError) and restore them before and after it gets done screwing around with the system.

Mac Programming a Mystery

Lon Byrne

I have been reading your mag. for a couple of years now and figure its time to pay for my own way. Thanks for the information you have included in your past issues.

I am still in the dark about the “Big Picture” of the Mac software even after reading both Macintosh revealed books and ‘How to write Macintosh software’. I have had previous knowledge of Apple ][ stuff down to the assembly level and solve most peoples problems on both the Apple ][ and Mac, but I have the uneasy feeling on the Mac of flying blind most of the time. Like walking donw a dark alley and waiting for something to jump out and zap you.

Anyway thanks again. If you can think of a solution to my lack of scope in the above problem please tell me. Help...........if not I’ll struggle along and hope that someday there will be a bright flash of light and the great god of ROM will smile on me.

[Sit down and type in the text edit program in the January 1987 issue of MacTutor, then modify one of the menu items in the program. After doing that, you’ll either get the big picture or decide to take up golfing! -Ed]

Power Supply Comments

Terry Gritton

The articles by Loy Spurlock and Chuck Rusch on the analog board/upgrade situation were interesting. I have been using a Max2 upgrade for 16 months and couldn’t live without it, but the screen has a tendency to skew to the left in the lower left corner, especially as the Mac warms up. Also I can’t get the 5 volt adjustment above 4.9 volts. Maybe replacing the CR17 diode will solve both problems. I wish there had been more information on balancing the 5 and 12 volt supplies.

With the price of 1 megabit DRAM’s starting to drop, I am tempted to populate the remainder of the Max2 board (for 4 Mbyte memory) but wonder if the power supply is up to it. Certainly more cooling will be needed. Along those lines I mention that Edmund Scientific offers those piezo electric fans for $12.00 apiece or 3 for $33.75. Just add $7.00 for postage and handling and the cost of some micro-hooks to connect to the 110vac at the power switch, and one could coolout the Mac for less than $50.00.

[I don’t think those piezo fans are worth anything. -Ed]

Window Detail

Clifford Story

Here’s an obscure little incompatability I’ve just found. If you set up a window with a zoom box, and then run your program on an old-ROM machine, using System 2.0, the grow box doesn’t work! (Why would you want to do that? Well, it might not be you; it might be someone else using your program. And maybe the machine is a 128 - Apple recommends System 2.0 with a 128.) What apparently happens: the WDEF doesn’t recognize the window type (8) and uses the next one on its list instead (4: nogrowdocproc). “Findwindow” returns “incontent” if you click in the grow box. My work-around is to include two window resources in the program. Then I check $28E before opening a window, and use the standard document window instead of the zoom window if I’m running on an old-ROM machine.

I’ve had Mac C Jr. for several weeks, and I think my long search for a good C compiler is over (I also think C is the wrong language for programming the Mac, but I want to write one major program in C, just so I can say I did it). A week after I got the new compiler, I gave Lightspeed C away. The most interesting point of comparison between the two: Mac C is a lot faster. Anyway, other Mac C Jr users may want to know that while there is no “list.h” file, the library includes list manager glue. Just write your own include file. I discovered this by writing my own glue and getting link errors. Also, the manual does not mention that a “pascal” function passes points by value.

Icon Reader Needs Work

John Holder

I just wanted to point out a couple of things about the article “Icon Reader Utility” in your June 1987 issue. Number one, there are a few instances that the stack pointer is not incremented after a Trap call has been made (in the IconDraw MACRO after _GetIndResource, in the Miscellaneous initialization section after _GetResource, after _OpenResFile in the SearchIcon routine, & after _CountResources in the ValidName routine).

Also, there is something I’d like to point out to assembly langauge programmers. You shouldn’t be using “Define Constant” (DC) as a way to store variables (only use this to hold Constant values!), instead, use “Define Storage” (DS) when the value is going to be changed in the course of your program. Programs that try to modify locations in their own code will not work on the new Macs and it’s not a good idea to do anyway....

Life in the Font Factory

Michael Mace

A few gripes on the new Pagemaker: much of my time now is being devoted to getting all our fonts to work again with PageMaker 2.0 and the new driver. It is clear that PM’s line layout algorithms have changed. Wonderful! In addition, it downloads fonts inconsistently, and will not italicize anything downloadable (try it with Saratoga). It doesn’t help any that the guy who wrote the driver for them took a five-week vacation as soon as 2.0 shipped. Did he know something?

You might ask how these major bugs managed to slip through, when we are an Aldus beta tester. Let’s just say that we would have caught all of them, if Aldus had ever sent us a working copy of the program to test. All the ones we got were so bug-ridden that they could not print at all. Clearly, they rushed the product at the end. I don’t blame them (they were running late), but I am beginning to believe that the Mac operating environment has become so complex that it is almost impossible to ship a major product without bugs in the first release. Witness Word, PageMaker, Cricket Draw, Xpress, etc., etc. Maybe people who buy version 1.0 of a program should get a discount.

Well, they’ll straighten out PageMaker, but it sure is a problem for now. Thought about trying Xpress? I know that’s heresy in some circles, but it is competitive (please note that I am not taking sides).

On to the next gripe: PICT versus EPSF. I’ll go on record here as saying that the EPSF format is a waste of time, made necessary solely by shortcomings in Apple’s PICT format (and Apple’s failure to document clearly those features that exist). After all, what is the PICT format? The standard way to transfer pictures between applications. Why do we need another format? Isn’t this the sort of confusing foolishness we sneer at in the IBM world?

The Great PICT versus EPSF Debate

First, a little backround: EPSF was invented by Jim Von Ehr of Altsys (Fontographer) a long time ago. Jim is a very bright guy, and he perceived very early a need for a good way to transfer PostScript code between applications. His EPSF format calls for PostScript text to be stored in the data fork of the file in question, and a PICT (for display on the screen only) in the resource fork.

Jim was correct that there was no published format for PostScript transfers. However, Apple already had an internal working document describing how PostScript could be included in PICTs, primarily by putting the code into handles pointed to by comments. The format allows you to mix PostScript and QuickDraw, or to specify PostScript to be substituted for QuickDraw when necessary.

I know the documentation existed because I saw it more than a year ago. Tech Support was perfectly happy to send a photocopy to anyone who asked. The document has just recently been released in tech note format, finally. Why Apple waited so long, I don’t know, but the delay created an impression that there was no format for transferring PostScript, when in fact there was. Thus Adobe ended up endorsing EPSF as gospel, and now it is being pressed as a de facto standard for doing something awkwardly that we can already do easily.

Using the PICT format has several advantages over EPSF. First, most of the applications already out there can include PICTs in documents, at least pasted from the clipboard. Second, PICTs can be copied easily into and out of the Scrapbook (as long as they aren’t too large). Third, when you print a PICT you already have the drawing’s bounding box, but to get it out of an EPSF you need to parse the PostScript data (not too difficult, but an annoyance and waste of programming time). Finally, PICTs allow you to mix QuickDraw and PostScript, so that you can, for instance, use the built-in routines for text manipulation in QuickDraw, and then just do in PostScript whatever the Mac cannot handle.

I think these arguments are pretty convincing, but I’m not the last word on desktop publishing software. We need to have a discussion among developers, and pick a single format. When a format is picked, we need to pressure Apple to implement if fully. Here’s a list of some of the troubles with each format:

PICT: 1. It’s unclear how the PostScript code being included in the PICT can tell where it is on the page. The current point should be set to one corner of the bounding rectangle when control is passed to the code in the PICT. This way the code will be able to draw everything relative to that starting point. Or, better yet, move the coordinate origin to one of the corners. 2. Some application writers, in their infinite wisdom, wrote PICT-interpreting code which strips out PICT comments when they are pasted in. So if you paste PostScript PICTs into most of the major drawing programs, the programs will strip out the PostScript. Application writers should include both a Paste command which interprets the PICT, and a Place command which would just put a PICT onto the page, unaltered. This would make the applications compatible with future additions to the spec. 3. The Scrapbook and the Clipboard need to be modified to accept very large PICTs.

EPSF: 1. This may be unrealistic, but I would like to be able to mix PostScripe and QuickDraw. 2. We must be able to cut and paste EPSFs using the Clipboard. 3. The entire application base must be rewritten to accept EPSFs. 4. The format should be rewritten so that the application does not have to parse the PostScript to find out simple things like the bounding box. This should be put in a little resource where we can get it easily. I would love to hear what your readers think on PICT versus EPSF formats.

Fate of the Unloved Hardware

John K. Calhoun

Do you suppose readers would enjoy something out of the ordinary?

Recently I upgraded my 512 to an Enhanced and discovered to my chagrin that the Habadisk external single-sided disk drive no longer worked with the Mac. Worthless as hardware, I supposed that the Habadisk might be a fit subject for verse.

In the unlikely event that anyone is so moved by this as to inquire of the outcome, the unfortunate disk drive was rescued by a 512 owner (for $75 and a promise that I’d write no more poetry about it), who has since passed it along to yet another owner. The last I heard is that it still whirrs and grinds and stips out disks with as much character as ever.

Keep up the good work. MacTutor is a first class publication. [This should strike a familar cord among all Mac owners as we witness the passing of yet another system upgrade era of confusion. -Ed]

The Ballad of the Datakludge

John K. Calhoun