Dialog Box

By Scott T Boyd, Editor

Concerned By The Rising Tide

I have developed several large programs for use in my engineering classes during the past six years. Although I am not a professional programmer, I believe my programs to be of commercial quality and at least one has been fairly widely distributed among universities. My programs have all been developed in Pascal with separate versions to operate within the Macintosh, DOS and Windows environments. I use Borland’s Pascal on the PC and Think Pascal on the Macintosh. I use objects extensively for both operating system needs and for my own applications.

I have been watching with some concern as the popularity of Pascal has declined in favor of C/C++. I decided to learn C/C++ so that I could see for myself why it is gaining in popularity. The basic concepts and constructs of Pascal and C++ are quite similar and, after getting used to the syntax, it was not difficult to translate code from Pascal to C/C++.

Having now translated several small programs and one large application, I thought that you might be interested in a summary of my assessment of the two languages.

One feature provided by Pascal that I sorely miss in C/C++ is nested procedures. In Pascal, a function or procedure can be placed within another function or procedure so that it visible only to the external routine. Variables declared within the nested routine are local to that routine and not accessible to the external routine whereas variables declared in the external routine are accessible to the nested routine. I find this nesting capability to be very helpful and I often nest my routines four or five levels deep. I find the nesting parallels my thinking and aid programming. As with objects, nested routines tends to encapsulate code and data and make the overall function of a routine more clear. Nested routines are not allowed in C++. I was forced to de-nest all of my routines in translating from Pascal to C++ resulting in a large number of routines all at the same level. The difference in variable scoping complicated this process.

A serious disadvantage of C++ that I encountered is that the time required to compile and link was much greater than in Pascal. Because I program in a manner in which I make a change and then test it, I found the speed difference to be irritating. The difference exists on both the Macintosh and the PC even though the Pascal and C++ compilers were from the same vendors. I understand that pre-compiled headers can be used to speed the compile/link process and I experimented with them, but I never approached the compile and link speed of Pascal. Why is it that Pascal does not require pre-compiled headers? I truly don’t understand why this difference exists. Does it reflect poor compiler design or an innate problem with C++?

I also noted that small programs compiled as code resources were much larger when compiled in C++ than in Pascal. This size difference is probably due to C++ including some libraries but I was unsuccessful in finding a way to reduce the size. In any case, I did not observe significant execution speed differences between programs compiled in Pascal and C++.

In summary, I have not found any capabilities in C++ that I need and do not already have in Pascal. I find the Pascal environment preferable, and I found the auto-formatting and integrated debugging provided by Think Pascal on the Macintosh to be much more friendly than the C/C++ environment. I’m curious to know if I am missing something or whether others have had similar experiences.

- S.A. Klein, University of Wisconsin Madison
klein@engr.wisc.edu

OpenDoc Draws Some Fire

I read the OpenDoc and SOM articles in the January MacTech. I have some comments, mostly skeptical ones.

It seems to me, OpenDoc was born as a succession of ideas:

• Bundle MacApp into the MacOS ROM and System 7.5, and

• change this class library into robust objects for everyone.

• Emphasize document mobility among apps using these objects.

• Call it “Documents On-top-of Classes”, or DOC.

Now, the Apple budget guys come into the picture.

• No more free lunch, so it doesn’t go into the ROMs.

• No more funding either, so spin it off to a 3rd party: CIL.ORG.

• IBM wants a kickback for PowerPC, so push SOM.

The Apple Evangelists have a field day!

• Model all users as “document fiddlers”: readers, writers, editors.

• Model all data processing as “document processing”.

• Model all software vendors (eg, Microsoft) as “editor vendors”.

• Hook up with other popular hype floating around:

- Cobra Objects Really Biting Applications (CORBA)

- Subtle Object Mangler (SOM)

• Rename the project OpenDoc, reflecting the open question of “Who pays for all of this?”

Now we are faced with some questions. What is Apple’s strategic perspective on this; e.g., will they push OpenDoc as a replacement for MacApp?

Will OpenDoc be an optional, extra-cost item (like System 7 Pro), or a developer giveaway on the ETO disk? Or perhaps just a standard for other developers since Apple doesn’t manufacture any “editors” except TeachText and ResEdit?

What is Microsoft’s perspective on all this, given that they are probably the biggest producer of “commercial editors” (formerly known as “business software”)? The MacTech article says the OLE is just a subset of OLE - how is this enforced, and does Microsoft agree?

Before Apple pushes the hype of OpenDoc, shouldn’t it first come up with some systematic scheme about parts? What are standard “parts” anyway? If each developer whips up their own set of “parts”, how does this lead to interoperability?

Is Apple committed to supporting this technology in the future, or just committed to advertising and evangelizing the idea?

As an analogy, compare “handlers and parts” with the “Communications Toolbox and Tools”. Apple did OK with the first one, but skimped on the second, and the result is a less useful system. Certainly modem communication has not become easier as a result of the CommToolbox. What prevents this from happening with OpenDoc?

More brickbats - Compare the OpenDoc plan with the MIT X-Windows project, which also started out as a simple idea (a windowing system for Unix) but ended up so complex it rivals Vax/VMS. Problems include being the lowest common denominator to all types of hardware, too many toolkits but no standard of functionality within them, and implementation by student/researchers with little vested interest in simplicity. The result is a system which works well, but don’t try to program it directly without lots of available staff time. What will keep OpenDoc from becoming so complicated when it’s finished?

Compare the OpenDoc plan with Ada, the programming language of the future just ten years ago. Ada has all sorts of “necessary” features for dealing with interrupts, multi-tasking, events, and real-time structures. Too bad most operating systems can’t or don’t or won’t provide all the necessary support for these things, otherwise we’d be using it today. The OpenDoc plan appears to require standardized features across operating systems (eg: network clipboards) which just aren’t present today, at least, not in an “open” sense. Ask yourself again, what is Apple’s role in all of this, and what guarantees us that Apple won’t change its commitment like it did with Bedrock.

Compare the OpenDoc plan with OSI (Open Systems Interconnect), the new reference standard network protocol, which has made itself obsolete in just a few years. Why should we believe that OpenDoc will be any more of a universal standard than OSI ?

Compare the OpenDoc plan with Apple’s OpenTransport. Unlike OpenDoc, the OpenTransport plan has specific goals, a specific plan of implementation and timeframe, and a specific support commitment from Apple. The marketing side of OpenTransport exactly matches its technical specifications. On the other hand, the OpenDoc literature talks about “Apple’s approach towards reducing the complexity of computing today”, and “providing users with a new level of computer power, flexibility, and ease of use”. Sounds like they’re talking about the Mac itself, until you read the fine print about compound documents.

The OpenDoc blurb talks about user interfaces and standard user operations, yet from what I can see, these implicit issues lack any sort of formal model or standard definition. Just what does standard text editing mean anyway, and why should I switch away from MS-Word to some new editor?

So far, OpenDoc is a philosophy rather than a product. Example: consider a C++ program as a document. There are a variety of handlers available: editors: MPW, vi, emacs, Think Project, BBEdit; Lint’ers; parenthesis matchers; compilers for the code. Yet the “document” - source code for some program - is already “sharable” with the first set, and usually incompatible with the last set. That is, a large body of code typically cannot be sent to just any other compiler, certainly not cross-platform, without manual intervention, setting compilation flags, adjust the code a bit, etc. What value does OpenDoc add to this scenario?

I suppose I have the wrong idea - I’m not supposed to think of “source code” as a document. Instead, the main focus of my work should be writing letters with text processors, and this entitles me to subscribe to the OpenDoc hype. Unfortunately this isn’t true, and therefore I’m concerned that OpenDoc will just lead to a more complicated development environment with little added benefit.

Well, these are my observations. - John Buehrer, jdb@ecofin.ch

John Buehrer seems to have gotten a very mistaken impression of what OpenDoc is and what it aims to do; this is understandable, since it’s hard to describe a complex system in a short article.

The three major assumptions he makes are that OpenDoc is supposed to be a universal solution for all types of software; that it is a framework (like MacApp or PowerPlant); and that it is vaporware without an implementation. None of these is true.

• OpenDoc does not claim to “model all data processing as ‘document processing’” and we do not expect every type of software to become a part editor. However, most of what users do with their computers is document processing - text, spreadsheets, drawings, page layouts, et cetera - so focusing OpenDoc on documents doesn’t seem like much of a restriction. But there is certainly still room for traditional apps and other types of software in the world.

• OpenDoc is not a framework in the traditional sense. The developer does not assemble classes provided by OpenDoc to produce a piece of software; rather, OpenDoc assembles the developer’s editors at runtime to produce a document. In other words, OpenDoc lives in the spaces between editors, not within them. It’s more like that Macintosh Toolbox in that regard.

Frameworks can certainly take advantage of OpenDoc (and MacApp 3.5 and the OpenDoc Parts Framework will do so, as may PowerPlant) but the tasks they perform are orthogonal. OpenDoc itself does the minimum it can do to guarantee smooth operation of multiple components in a document; everything beyond that is a job for the developer or for a framework.

(The history of OpenDoc really had nothing to do with the MacApp project; instead, it grew out of an investigation of how to extend technologies like Apple Events, the Edition Manager and Bento into a true compound document architecture.)

• Mr. Buehrer also seems concerned whether OpenDoc really exists and whether Apple is truly committed to it. OpenDoc has an large engineering effort, of which I’m a part, and a public delivery schedule. We’ve done a lot more than just “advertising and evangelizing the idea”; we’ve been working on the implementation since 1992. The software on the CD should attest to this. Moreover, Apple executives from Spindler on down are committed to OpenDoc; they rightly see it as an absolute necessity if Apple is to maintain its technological leadership and its control of its platform. From my position in the engineering trenches I see every indication that OpenDoc is one of the most high-priority projects at Apple.

He then asks what will keep OpenDoc from becoming unusably complex. Some complexity is inevitable, but what developers who’ve used it tell us is that the architecture makes sense and that it’s much cleaner than OLE. Take a look for yourself; the APIs on the CD are pretty close to final (in the next release they truly will be frozen.)

He sums it up by saying that “So far, OpenDoc is a philosophy rather than a product.” One might get this impression by reading just the (admittedly rather marketing-oriented) article in the magazine. But if you go beyond that and examine the more technical documentation provided on the CD or on the Internet (by FTP from cilabs.org) we hope you’ll see that OpenDoc is solid, implemented, and well on its way to completion. - Jens Alfke, OpenDoc Engineering Team

An Interesting Design Philosophy

Here’s a Word 6 “glitch” I thought you might find interesting. Go into Word and try to type control-Q or control-T (in Chicago font, the command key symbol and the apple symbol, respectively). Of course, nothing happens. Someone at Microsoft decided that the control keys shouldn’t be typeable! So I got onto the MSWord forum and asked for help. These folks are great. To their credit, every question I’ve posed them has been answered promptly and accurately, if not necessarily to my satisfaction. However, below is their response to my query. As Dave Barry would say, “I’m not making this up!”

- Dave Mark

Word 6 now inserts special characters with the Symbol dialog. To access the dialog, choose Symbol from the Insert menu and click on the Symbols tab. The drawback to using the Symbol pallet is that special characters below the value of 32 (check Appendix A to determine what value is associated with a character) in the Macintosh character set are not available. Unfortunately, for characters 0 through 31, you’ll need to go through a couple extra steps to insert them with a keystroke.

To get around this problem, insert the Command character and the Apple characters in Word 6.0 using fields, and then for convenience, make the character into a glossary entry, and assign your own keystroke to them.

To use the symbol field, Choose Field from the Insert menu, click on “Equations and Formulas” under Categories, then click on “Symbol” under Field Names. Place the cursor in the text box next to the word “SYMBOL”, type in the value for the character and a space (see Appendix A: you’ll see the Command character has a value of 17), then click on the Options button and add the \f switch. Then click in the text box after the \f switch and type in the name of the font you want, in your case, “Chicago” without quotes. Click OK. Then click OK again. You should see the Command character at this point. If you do not see it, place the cursor on the field (It might look like {SYMBOL 17 \f Chicago \*MERGEFORMAT}) and then press SHIFT F9. This keystroke changes the view of the field to the Command character.

To make the process more convenient for future use, select the symbol, choose AutoText from the Edit menu, type a name in the Name box; for example, “command”, and click the Add button. Then, to assign the keystroke, choose Customize from the Tools menu, on the Categories side select AutoText (it’s near the bottom of the list), select the AutoText entry on the right side, place the cursor in the “Press New Shortcut Key” box, press the keystroke CONTROL Q and click the Assign button. The next time you need to use the character, just press CONTROL Q.