Standards Needed in Development Systems

By Paul F. Snively, MacTutor Contributing Editor

TML Pascal Has The Right Approach

I had a nice long chat with Tom Leonard the other day. Tom, for those of you who don't know his name yet, is the person behind TML Systems, Inc. who by the time you read this should be quite famous for something that I have a copy of: The MacLanguage Series Pascal compiler.

TML Pascal is a native code compiler that, in its release form, will support compile to assembler source, compile to object code, or compile for syntax check options. It will also support the easy construction of desk accessories, thanks in large part to the efforts of MacTutor's own Alan Wootton.

TML Pascal includes licensed copies of the MDS Edit, Link, and RMaker utilities, allowing easy combination of code generated by any language system that supports the Consulair file formats. Tom is, as of this writing, negotiating to license Consulair's new smart linker for distribution with his system. That would be a much appreciated addition!

Tom has a copy of TMON, which I reviewed in the September issue of MacTutor. I mentioned Darin Adler's user area to Tom and he was excited about TMON's obvious power and expandability.

We discussed the possibility of Tom's writing his own user area for TMON, to be distributed with TML Pascal, which would allow the displaying of the values of all active local variables, as well as having the ability to refer to the object code by function or procedure name as opposed to by address (TML Pascal and TMON will support each other in this anyway; Tom has already, at my urging, implemented a code labeling feature nearly identical to Lisa Pascal's, which is what TMON's label recognition capability was intended to support).

There are a number of points to this. The first is that Tom Leonard is a straight man with a good, solid product that is sorely needed, and he has it at a reasonable price (the native code compiler, source/object generation, easy desk accessory generation, real and potential debugger support, and Tom's listening ear all come for a mere $99.95). The other is a bit more subtle, but at least as important.

Supporting Standards

Tom's product is a classic example of a third-party product that is relying heavily on standards set by other people (in this case, Consulair). In order for his system to be functional, let alone flexible, he has to rely on the shifting sands of "what the developers are using."

Right at the moment, if you want code flexibility, you have to have compatibility with Consulair's Linker, at least the MDS linker, if not the new smart linker. Now what about Apple's new heirarchial file structure on the Hard Disk 20? Don't get me wrong - the Hard Disk 20 and smart linker are both very good, very necessary things, but they do tend to make life a bit unpredictable for people like Tom Leonard. Worse, however, would be if no one else adhered to the standard means of generating Macintosh code.

For non-native-code systems, the standards really don't matter. What Consulair does with the linker doesn't make a bit of difference to MacFORTH users, for example. For others, however, it is crucial.

Tom has made a supreme effort to provide a system that will enable you to write Pascal programs quickly, compile, resource compile, link, and go, and if you want, include code from other systems, such as MDS. At this point, it looks like he'll succeed, and greatly.

Give Us Standard File Formats!

So here's the challenge to all of those people who are doing Macintosh native code development systems: go with the flow, huh? It's nice to think that you have a radically new, innovative system or what have you, but if you want to maintain flexibility and portability, give us programmers using your system the ability to link our code with code from other languages and compile resources that may have been created (at the source level, anyway) by another system. In the end, we will all benefit.

And to the folks at Consulair: you guys have set a standard, for which you are to be commended. Now, once you have the major wish lists taken care of - the smart linker and so forth - how about not making any surprise changes of a drastic nature? Too often compatibility is lost in this way, and in development tools this can be disastrous. Please help to keep things on an even keel.

If all developers would just use these standard tools - compiler, assembler, Consulair smart linker, RMaker (and/or ResEdit), and TMON with customized user areas for your environment, Mac software development could reach the level of being a science, which would greatly facilitate speedy Mac applications development.

So, for the moment, a good place to start is with TML Systems, Inc. Pascal compiler and TMON. For $190.00 (more or less) you will have bought the only native code Pascal compiler available for the Mac (it does require 512K, by the way) and simply the best monitor/debugger available for the Mac, bar none. Add Darin Adler's user area and call Tom Leonard and let him know that you support his efforts to integrate TML Pascal with TMON's debugging capabilites and that you would be very interested in a TML Pascal oriented user area.

Well, I'll get off of my soapbox now. Thanks for listening, and let's keep development tools standard and, hopefully, working together, rather than working at cross-purposes.

Enjoy,

Apple, Are You Listening?

May I add that we wish Apple would also support what in reality is their own creation; i.e., the ".REL" file format standard they helped to create! We encourage Apple to make their new development system compatibile with the currently accepted object code format, rather than once again force everyone to chose between the MDS/Consulair format and whatever new format Apple is rumored to be coming up with. Macintosh software has proven that well defined tools compatibile with each other are much more flexibile and desirable than one giant integrated tool with many built-in functions, but incompatibile with anyone. We simply want this fact to be accepted in the world of development tools also. We encourage the support of a standard ".REL" file format so that all development languages may be linked together under one linker. We look for the day when this goal is achieved.

Editor

Networking

Blake Miller

As with many of your readers, I too am terribly impressed by your publication. I recently subscribed in October. It was not two weeks after I sent in the check that I got my first issue! Many thanks. I am still waiting on the other publications, who received checks at the same time as you.

I very much liked the October 1985's C workshop article on Networking. I am interested in writing an AppleTalk-implementing game of some sort. Besides the excellent in depth coverage, what caught my attention were the subtopic headings. The very first one said "What Apple Doesn't tell you!" Myself, through experience, have found it more aptly put "What Apple Won't Tell You!

As different compiler products are used for any given language, I would appreciate it if your editorials would, at the beginning of each article, write which company's compiler is being used for the current discussion. Case in point (no, I'm not a lawyer): I was reading the FORTRAN articles and was not aware that Microsoft had bought out Absoft. [Actually, they are only distributing the Absoft Product -Ed.] I was confused for some time as to which FORTRAN development system was being addressed!

Moreover, include the version number, as significant changes can be incorporated into later versions (ergo Consulair C). I think that this relevant information would fit nicely into the article's main header.

I cast my vote for a standard ".REL" file format. I have recently read that Apple plans to market a "new" development system which will incorporate Pascal, C, and Assembler. In my case, they are a 'Day late and going to be dollars short', for I have already purchased the Consulair Mac C 4.0 and the TML Systems Pascal to do just this kind of development. While Apple may provide it all in one coherent package, I feel they will be making a mistake if it does not conform to this "standard".

[We comletely agree, and thank you for the suggestions. We are looking into them. -Ed]

One Year Anniversary!

David Tilley

Thanks for a year full of news and essential technical info! Also congrats on your 1-year anniversary! I'm writing to renew my subscription (it dies soon, sniff.) Since you guys don't have subscription-date-deaths printed on your labels, I hope everyone remembers to re-subscribe! Anyhow, sign me up for another year!

[We don't use a subscription service. Instead, we use the Macintosh! We hope to implement "death-date" stamping as soon as we convert our subscription lists from the perfectly awful Mail Manager to the perfectly wonderful File Maker. We do send out a renew notice however. -Ed]

What I Like

Bill Murray

You have a great publication. Keep up the good work. Keep up the assembler, Pascal and Advanced Mac'ing. I'd like to see even more here. How about adding a quickdraw section (tricks...). Oh, yes, I'd like to subscribe! [We are starting coverage of Postscript, which has wonderful graphics capability far exceeding quickdraw. -Ed.]

Steve Brecher Fan

Denis Stanton

Your letters, Ask Prof Mac and in particular the Mousehole Report columns are a vital source of news (and rumor) to me as Apple UK is very slow to announce anything to users ehre. Steve Brecher's Preview of HFS was fascinating and very timely with Apple at last joining in the hard disk market. I'm having an arguement with a friend here about whether the Macintosh HD-20 is actually a MacBottom as was predicted some time ago. Do you know? [Yes I know and no it is not! -Ed]

In the August Mousehole Don L advised how to get hold of a Journal driver from a guided tour disk using ResEdit. Is this the same as REdit? [No, REdit 1.0 is the European resource editor that made it out of Apple via their European Sales office. ResEdit is the original resource editor that has remained in it's "engineering release" state while continuing to undergo slow development through various pre-release versions. It is available on source code disk #6. -Ed.]

Still no sign of Chris Derossi in the Pascal column? Alan Wootton continues to write about interesting things, but I've gotten a bit frustrated with keying them in only to be greeted with "Sorry, out of memory". There are still some of us out here who can't afford the 128K to 512K upgrade until the machine starts earning, and can't earn until they upgrade! I envy you some of the prices I see. I hear Apple has cut the US price of a LaserWriter from $6995 to $5995. Here in England it's recently been cut by £1000 to £5995 ($8,812!)

[ I'm afraid very little will be possible on 128K Macs shortly, if not already. Better bite the bullet and upgrade. We're already talking Mac+ upgrades over here to 1Meg! -Ed.]

Lisp and AI Please!

Bill Brayman

Your mag is great. Keep it up. Particularly, keep the Lisp articles (I have Exper Lisp). Even more on Lisp or other artificial Intelligence topics would be appreciated.

Also I'd like to see more expert opinion on the 1-2 meg memory upgrades; which ones are good, Mac+ problems, and Apple warranty.

[Thank You. Andy Cohen will be greatly encouraged. On memory upgrades, I personally use The MAX 1.5 Meg upgrade as a RAM disk and it works great. However, there is a rumor that none of the odd size upgrades will work under HFS and the new ROMS so I advise you not to purchase anything until the situation clears. -Ed]