TweetFollow Us on Twitter

OpenDoc vs OLE
Volume Number:10
Issue Number:8
Column Tag:New Technologies

OpenDoc vs. OLE

When elephants fight, only the ants get hurt

By Jeff Alger, Consulting Methodologist

A monolith of American industry threatens to unilaterally impose a standard by virtue of its sheer size and dominance of the market. Quickly a consortium develops to counter the move; a rival standard is proposed, the hype wars begin. The lumbering giant points to the fait accompli: its technology is already in use throughout the world and will soon be a standard part of its operating systems on millions of machines. The upstarts point to technical advantages of their proposal and darkly hint at the threat to democracy and family values that will loom if the industry titan is allowed to further consolidate its grip. The press eats it up, sensing a David vs. Goliath story in the making. The battleground: component object-oriented software. The industry titan: Microsoft. The upstart consortium: Apple and IBM? Wait a minute. Am I the only one that sees something weird about this alignment? Age-old IBM a frightened upstart? Entrepreneurial Microsoft the lumbering giant? What’s going on here?

Unless you’ve been hiding underground the past few months - not a bad idea, actually - you’ve been ducking blows in the OLE (“Object Linking and Embedding”) vs. OpenDoc slugfest. Both address roughly the same issues: how to combine object-oriented software components into heterogenous documents, how to exchange data between programs, how to store and retrieve objects, how to distribute them across a network, how to allow objects to interoperate across programming languages and machines. Given these stakes, the battle may well be what both sides are claiming: the key to computing in the second half of the 90’s. But sorting out which is better and for what purposes is like trying to get directions to the nearest town from two people who are rolling on the ground trading rabbit punches. Let’s step back to a safe distance and take a dispassionate look at what’s really going on.

Of Objects and Markets

The basic technology at issue can be divided into basic four tiers of standards.

1. A standard for the binary representation of objects.

2. A standard mechanism for storing and retrieving documents containing arbitrary collections of objects.

3. A standard for how to allow users to combine arbitrary user-visible objects in their documents.

4. A standard mechanism for distributing and sharing objects between applications and over a network of dissimilar machines.

The first issue has to do with how objects are stored in memory. Microsoft’s standard is known as the Common Object Model (COM). The standard adopted for OpenDoc is IBM’s System Object Model (SOM). There is more than simple storage at issue. How do we allow different programming languages to create and access common objects? For that matter, just what is an object, anyway, and where should the line be drawn between an object at run time and the program source code used to create it? These are fundamental issues and the winner, if there is a single winner, of the current object wars will have a huge influence on object-oriented language designers for many years to come.

Older concepts of file systems and databases just can’t cope with the storage problems we face today. Both OLE and OpenDoc contain new standards, along with libraries that implement them, for storing and retrieving what are known as “compound documents,” files that contain nested collections of diverse sorts of objects. This, too, is likely to give the winner - if there is a single winner - a lot of throw weight in battles over other issues in the next generation of object systems.

Ah, yes, let’s not forget the users. They don’t directly see binary objects or compound document files or programming languages. To them an object is something they can point to on the screen or on hard copy and give a name. They rightly expect objects to be consistent and well-behaved no matter where they appear. They get frustrated at the arbitrary distinctions we’ve traditionally drawn between data that belongs in one sort of application and data that belongs somewhere else. “Wouldn’t it be nice,” Joe User might well say, “if I could simply copy or drag anything I can select into any other document in any other program and have it still work?” Indeed. That is the stuff of the user interface and portions of OLE and OpenDoc.

Finally, the arcane world of distributed objects. Neither side really has them yet, but in the struggle for control of tomorrow’s operating systems this is shaping up as potentially the most important part of the war. In a world of multiple machines and multiple virtual memory spaces, how do we tell one object from another? How are they created and destroyed? Do we store objects in their own little mini programs with separate address spaces, or combine them into a single memory pool? Can an object be shared between multiple documents or simply copied? Can one document contain objects that live on multiple machines? How do you handle failures, of networks, machines and users? Must a programmer write code having already decided which objects are to be distributed, or can those decisions be deferred?

With stakes like these, little wonder that the opposing sides are weighing in so heavily and so early. This is at once the next generations of object-oriented software technology, graphical user interfaces, and network operating systems. Waiting on the sidelines are the anxious software developers whose products must interoperate using one standard or the other; corporate developers hungry to lower their costs; retailers wondering what this means to the ways we package, price and distribute software; and programmers everywhere trembling at the thought that everything they once knew about writing applications might have to be relearned and knowing that they’d better pick the right horse or be left behind.

This issue contains more detailed descriptions of OpenDoc and OLE elsewhere, so I won’t go into a great deal of technical detail here. Instead, I’ll focus on comparing and evaluating the two products.

Back To School

Of all that has been said and written about OLE and OpenDoc, the only uncontestable claim is that both are complicated pieces of technology.

The OLE documentation numbers in the hundreds of pages, but if you really want to know what’s going on you have to read Kraig Brockschmidt’s 900+ page book Inside OLE 2.0, along with numerous more recent papers from Microsoft. Come to think of it, Brockschmidt’s book doesn’t even begin to talk about OLE Automation, the substrate upon which scripting is built in OLE. It wouldn’t hurt to attend a few conferences to get a sneak preview of the upcoming Chicago and Cairo operating systems. Since OLE is best used from within the Microsoft Foundation Classes (MFC) class library, allocate a few mental cycles to become familiar with that set of documents as well.

As to OpenDoc, I haven’t even been able to estimate the page count of the documentation yet. You can get a quick tour by pouring through a couple hundred pages of OpenDoc preliminary - very preliminary - documentation, then wade into the 500+ page System Object Model (SOM) documentation from IBM. Oh, and if you haven’t yet had the pleasure, take the opportunity to read up on the Drag and Drop Manager and the Code Fragment Manager (CFM), because they, too, are connected.

If you are trying to compare the two, be prepared to be inundated with all manner of position papers from both sides. The level of sniping in these “black papers” is exceeded only by the casual attention to the real facts.

Egad! Don’t these people know that we all have jobs and families? Learning either of these technologies well enough to write a simple component takes a few days. Learning enough to design a major project looks to me more like weeks of reading and training backed by a at least a few months of hacking. Learning enough to intelligently make a long-term strategic choice is nearly impossible, especially since one of them doesn’t even exist yet.

Ghosts Of Objects Past, Present and Future

One of the surreal aspects of the debate is that it isn’t always clear what’s been there for a long time, what’s new and what is still vaporware. The OpenDoc consortium has done a brilliant job of positioning OpenDoc,tomorrow’s concept, against OLE 2.0, today’s product. Microsoft plays into their hands by claiming OLE is better because it’s already shipping, then in the same breath turning around and claiming that their vaporware will be better than OpenDoc’s vaporware. This stuff gives me a headache. Let’s start the comparison by defining our terms. The following is the situation as of this writing in mid-June.

The Past

On the Microsoft side, OLE 1.0 shipped in 1990 and OLE 2.0, a major enhancement, shipped early last year. It is available today in final form on all Windows and Windows NT platforms and on the Macintosh. Microsoft, lover of big numbers, claims there are about 1.5 million customers using OLE-aware applications and that most of the major software vendors are already committed to supporting OLE, most of them already pretty far down along the learning curve.

On the OpenDoc side, there are a couple of precursor technologies such as the Drag and Drop Manager but that’s about it. In short, Microsoft is right, as of today OLE is shipping and OpenDoc isn’t.

The Present

As you read this, there are various alpha and beta versions zooming around both worlds, making it horribly confusing to keep score. OpenDoc is in release A6 on the Macintosh as of the Apple World Wide Developers Conference in May. This includes a very early release of the IBM System Object Model implementation for the Macintosh. OpenDoc has not made its way to any other platforms as of this writing, although one piece of the underlying technology, SOM, is supported by IBM on AIX and OS/2.

Meanwhile, Microsoft has seeded a “select” group of 5000 developers with a prerelease version of the distributed version of OLE. They have also begun beta testing of OLE Controls, a small-component extension to OLE that is both a close analogy to OpenDoc parts and to Windows VBX controls.

The Future

Microsoft is busy implementing their “Windows API Everywhere” strategy. They have licensed the source code to the Windows operating system to at least two other vendors who have demonstrated partial ports to Unix. They have committed to licensing the Windows and OLE source more broadly, although the terms have not been made public. Where Windows goes, so goes OLE. In addition, Microsoft is working with DEC to refine COM somewhat to go from the “Component Object Model” to the “Common Object Model.” In addition to driving everyone nuts keeping the two identical acronyms straight, this will enable DEC to port OLE to other operating systems including OSF/1. Microsoft claims that a port to MVS on IBM mainframes is also under way. It should be made clear what this means: The OLE standard, including the objects themselves, will interoperate across both Windows and non-Windows operating systems.

One of the worst-kept secrets in the computing world is the work Microsoft is doing on their next generations of the Windows and Windows NT operating systems. Daytona, the successor to Windows NT and already in beta testing, will include native support for OLE 2.0 built into the operating system. Chicago, the successor to the Windows operating system and a major enhancement of the user interface, blurs whatever line is left between where the operating system ends and OLE begins. Cairo is an object-oriented operating system built on OLE from the ground up. Another technology Microsoft already has well into the pipeline is an integration of OLE with ODBC database support. All, with the possible exception of Cairo, are scheduled for release within roughly the same time frame as a final release of OpenDoc, so it is fair game to project them into the equation. (I consider anything within six months to be “roughly the same time frame.”)

The OpenDoc consortium has committed publicly to making the source code to OpenDoc available and to port it to a variety of platforms. They point to “support” from systems software vendors Apple, IBM, SunSoft, Taligent, Novell, and Xerox “with many, many others expected to follow” according to one white paper. (italics added) It is unclear from their white papers and documentation exactly what is being supported by all these vendors, OpenDoc or only pieces such as SOM. The phraseology cryptically lapses into support for “CILabs technologies,” CILabs being Component Integration Laboratories, the formal entity behind OpenDoc.

Recently the OpenDoc crowd has announced that OpenDoc will be written in such a way that it can interoperate with OLE. Details to follow.

Binary Object Models

Both products allow you to create objects in such a way that they can be accessed from programs written in other languages. This is the stuff of so-called “binary standards” for objects, a subject that has kept lots of folks busy over at the Object Management Group for quite a while. The two approaches are Microsoft’s COM and IBM’s SOM and they couldn’t be more different.

The Component Object Model

COM embodies a sharp separation between binary objects and the object-oriented programming languages used to create them. The COM model is based on delegation, not inheritance. Rather than have one class derive from another, in COM you would likely form what is known as an aggregate of two objects. The container object would delegate to the component object in much the same way that a derived class would pass along messages to its base class. Aggregation can also be used to implement the equivalent of complex data members.

COM represents a C++ way of thinking of objects at run time. Methods are dispatched using something that you would swear was a vtable if you didn’t know better. In fact, you can use C++ derivation to create your aggregates, as long as you add the interfaces to direct a client to the right base class or data member. Yet, the model is not exactly C++. While servers may be written in terms of derivation, clients see a flat object space. There is more mathematical consistency than in straight C++; if you do the equivalent of typecast from derived to base, you are guaranteed to be able to typecast back to the derived class in a typesafe way. This reflexivity is one of several rules of consistency imposed by COM to maintain type safety.

Speaking of type safety, COM is safe very. The way you access an object is through an interface. Each interface is uniquely identified by an interface ID (IID). The way you obtain an interface from an object is, you ask it. The specific way one would typecast from “derived” to “base,” for example, would be something like this:

Derived* d = (Derived*)object->QueryInterface(kDerivedID);

This returns either a valid pointer or NULL to signify that the object doesn’t support that interface. That is, in order to typecast any object you have to go through the object, which can verify that the interface is valid for that object. This is all done in either C or C++. It is easy to wrap existing classes with COM-style interface wrappers.

Normally, you will use interfaces that represent standard C++ class interfaces. COM also provides a special interface called IDispatch that essentially allows you to query an object about its capabilities at run time and dynamically dispatch to it using symbols, not precompiled function calls. This provide low-level support for scripting and high-level development tools that need a dynamic environment. Because of the delegation model, an object can change its interface and implementation at run time, within certain limitations to insure consistency.

What is involved in using COM? Basically, you just write the interfaces and the code. If you are using C++, it’s no more complicated than writing any other C++ program, but with a couple of extra member functions to write such as QueryInterface and perhaps support for OLE Automation. If you are a C programmer, there are some nifty macros that reduce the problem to about the same level of complexity as using C++, although I have a hard time understanding why anyone would want to use C rather than C++ for this particular purpose. If you are using other languages, you have to check with the language vendor. Many are being adapted to work with COM but it’s not a universal standard yet. As they are adapted, however, the objects you create using, say, C++ code will be accessible and manipulable from, say, Smalltalk and vice versa. Learning to use COM involves perhaps a few dozen pages of manuals and less than a day of effort.

The System Object Model

SOM frightens me. It really does. It’s as if a bunch of people with the software equivalent of bazookas sat around one day and said, “Hey, let’s see if we can solve a problem nobody cares about by taking all the major object-oriented languages and blasting them into smithereens.” Brrrr. What’s even more frightening is that no one seems to be taking IBM to task for this unbelievable act of engineering hubris - except Microsoft, and that is written off as competitive snarling. The rest of OpenDoc is a reasonably good piece of engineering, but if SOM comes within a hundred yards, duck.

The stated objective behind SOM is to provide “language-neutral” access to objects. It is based for the most part on the Object Management Group’s (OMG) efforts to standardize the binary representation of objects. The run-time model is dynamic, supporting run-time inheritance and polymorphism. Thus, you could use all the features of a Smalltalk or Common Lisp Object System (CLOS), such as creating classes or changing their derivation on the fly.

However laudable these aims, the result is an over-engineered mess. To use it, you have to first describe your objects using yet another language, the SOM Interface Description Language (IDL). This isn’t just a minor detail, but another programming language to master. The syntax is sort-of-Smalltalk, sort-of-C, sort-of-C++ but in the end it is IDL. It is chock full of macros, modifiers, conventions, and isms.

SOM isn’t language-neutral; I would call it C++ -hostile and sort of Smalltalk-friendly. The role of C++ is reduced to implementing and calling specific member functions. The C++ notions of class, derivation, constructors, destructors, operators, overloading, etc., are all subsumed by the IDL model. SOM does not support private, protected and public member specifications, unless you consider surrounding a member function with “#ifdef __PRIVATE__/#endif” to be “support.” In fact, it is hardly worth bothering to use C++ with SOM, since C does just about as well with what’s left. SOM is a slap in the face of the C++ community.

OK, so you don’t like C++. If what you really want is dynamic binding and such, Smalltalk or CLOS will do better than IDL at those tasks. Garbage collection is based primarily on reference counting. While this is also true of COM, COM doesn’t pretend to provide language neutrality. It is difficult to envision true Smalltalk- or CLOS-style programming using a reference-counted garbage collection scheme. SOM doesn’t have anything resembling code blocks from Smalltalk and Objective-C or macros from CLOS. There obviously aren’t anywhere near the diversity of libraries for SOM that there are for Smalltalk, Object-C or CLOS. It isn’t worth going further, because I wouldn’t stop for several days. To paraphrase the former candidate for Vice President and current Treasury Secretary, “I worked with Smalltalk. Smalltalk was my friend. Sir, you are no Smalltalk.”

Interoperability? COM is living proof that you can provide an equivalent level of language interoperability without first tossing conventional languages into a Cuisinart. Whether you like COM or not is not the issue; the issue is that SOM is to interoperating what a flamethrower is to mowing the lawn. Yes, the lawn won’t grow back for a while, but haven’t we forgotten something important about lawns?

The development lifecycle is bizarre. First, decide which objects should be treated as SOM objects and which as normal, local objects. If you later change your mind, it’s bad news unless you’re paid by the hour because you’ll have to pretty much start over. Next, write a description of your objects in IDL, then compile them using an IDL compiler. This funnels your description through an “emitter” which spits out template C or C++ or Smalltalk or whatever code. Fill in the blanks. Compile again, this time using your language compiler. On the client side, emit stuff to include with your program. Write your program. Compile. In short, take all your worst nightmares about software management and play them at fast forward with the color knob twisted all the way to green.

The funny thing is, there isn’t even a significant problem solved by SOM. Other than the vendors who forked over big bucks to participate in the Object Management Group, I haven’t noticed a particular groundswell of opinion that language interoperability is a big issue. Language vendors have managed to do a creditable job at that without having to toss everyone’s salad. A binary standard for how C++ objects are represented in memory would achieve 90% of what SOM does with about 5% of the hassle, because then C++ itself could also serve as the object interface description language. Extensions to C++ to handle intermixed dynamic and static binding of methods - permitted by the language spec, by the way, which does not require the use of vtables - would solve the rest. Even without that, as COM demonstrates, idioms for using C++ more intelligently can solve just about any problem a developer will encounter in real life. That’s what James Coplien’s book Advanced C++ Programming Styles and Idioms is all about.

It is telling that in OpenDoc one is only expected to use SOM for a small subset of objects that have to be accessed externally. The rest is conventional C++, including almost all of the OpenDoc Parts Framework class library.

Documents and Storage

Both products allow you to store arbitrary, nested, versioned objects in compound document files. Both use streaming as the primary means of turning an object into bits and back. Both provide a way to browse through a compound document file and extract only those pieces you care about. Both provide a way to maintain multiple versions of a document or specific objects within it. There are differences in the area of document storage, but not compelling ones in either direction.

The one major difference coming up is that the Structured Storage model of OLE is being built into the file system of upcoming Microsoft file systems. This will provide a higher level of protection and performance than one can expect from Bento, the underlying storage technology of OpenDoc. This will also fix a nagging problem with the current version, which uses file path names to locate things. If the user moves the file, OLE might not be able to find it when needed. SOM also uses path names, but OpenDoc apparently will stick to the Macintosh model of file references, which stay the same as a file is moved around.

Structured Storage has slightly better features for recovering from a crash, including a very good feature called “Transacted” mode, in which all changes are considered temporary until all are committed together. Under OpenDoc, changes are written incrementally, possibly leaving a file in an inconsistent state following a crash, at least as far as the user might be concerned. Structured Storage also makes it a little easier to implement a “Revert” command without having to duplicate the entire file, only the parts that change; OLE keeps track of which is which.

The User’s Perspective

OpenDoc looks very good at the user level compared to OLE. Apple has done a very good job of thinking through how a user will interact with parts that have different commands and different user interfaces for those commands; i.e., menus. In OpenDoc, the integration of the parts into a single user-visible document is pretty close to seamless. Click on an object and the user interface changes state as appropriate to that object. New menus show up, old ones go away, windoids come and go as they should. The standards for borders and other user feedback seem thoughtfully designed.

Comparing OpenDoc’s user interface directly to OLE’s is difficult because there are several levels of OLE support possible. Where OpenDoc has essentially one interface and architecture, OLE can potentially support several. This is not so much because the user will appreciate this as that OLE presents a graduated scale of options to the developer, depending on the degree of integration you want or how OLE-capable you are.

A minimal treatment is to turn a normal Windows application into an OLE-aware application, capable of being an OLE “server.” That is, the application’s document becomes a component in some other application’s - a container’s - document. When the user “activates” the embedded object, the originating application is fired up and the actual editing takes place in a separate, temporary window. This is a slight extension to the user’s concept of using two separate applications: There are still two apps, but now the data is combined. It is not necessary to have the original app around if all you want to do is draw and print, since the PICT or metafile needed to do those is er, embedded into each OLE server object. (By the way, OLE automatically turns PICTs into Windows metafiles and back when objects migrate between Macs and Windows machines.) Only if the user needs to edit or you want to do something fancy like animation or sound do you need the original application installed. Most of the work involved in becoming an OLE server is in supporting a stream interface for the clipboard and drag and drop to use in moving the data around.

On the receiving end is the OLE container, an application whose documents can contain OLE components. Like becoming a server, turning an arbitrary application into an OLE container is relatively easy although more involved than writing servers. A container-server is simply a combination of the two techniques. At this level one gets the use of drag and drop and OLE-style clipboard use.

It is also possible to create OLE servers that edit in place, rather than opening a separate window. These modify the user interface environment around them in much the same way that OpenDoc parts do: menus and toolbars swap to reflect the currently active server. This is known as in-place activation.

The next and most common treatment is an in-process server. This is a dynamic linked library (DLL) that runs as part of the client application, though it is loaded at run time. This allows lightweight display or editing code to go with the object without having to bring along the entire originating application.

Finally, there is the future: OLE Controls. These are direct analogies to OpenDoc parts. They are scriptable, they activate with single clicks, not double, even on deeply nested objects, and they run as part of the client process. In the long run they look a good bet to replace VBX controls in the Windows world.

So, which user interface is better? Unfortunately, the comparisons by the combatants aren’t always fair or accurate. More than in any other arena, one has to ask, “What version are you comparing to, today’s or tomorrow’s?” If you compare the user experience with OpenDoc parts to OLE 2.0’s out-of-place servers in OLE, OpenDoc wins, hands down, from the user experience. Users will appreciate not having to remember when to use a single click and when to use a double click to get the job done and not having to understand much about the underlying nested structure of their objects.

If you compare OpenDoc parts to OLE Controls, the differences become pretty minor both ways. Both activate in exactly the same way, with a single click, even on nested components. Both activate in-place. Both run in the same task space as the client application, although an OLEcontrol can run in its own space if written that way. OpenDoc still maintains a small edge because of its support for arbitrarily shaped borders around objects; as of today, OLE is limited to rectangular borders. However, Microsoft has stated publicly that they, too, are considering supporting funny-shaped embedded objects, so that distinction may not last for long.

So which user interface is better? Today, OLE 2.0 because OpenDoc isn’t here yet; this is one of those issues that has gotten clouded by comparing OLE today to OpenDoc tomorrow. Tomorrow, when OLE Controls and Cairo have come along, I suspect OpenDoc will still have the edge, though both will be excellent treatments.

Distributing the Objects

Finally, let’s talk about what happens when we stop looking at individual applications and start looking at entire networks. COM becomes a network-wide distributed object system by simply installing the Networked OLE DLL in place of the OLE 2.0 DLL. That’s it. No recompilation, no changes to source. OpenDoc requires the use of the Distributed System Object Model, or DSOM, the distributed extensions to SOM. DSOM is certainly a creditable implementation of distributed objects and the techniques used are very well-established. However, under straight DSOM, you have to decide up front what you want to distribute and what you don’t. The interfaces for creating, destroying and in some cases using objects under DSOM are quite different from those under straight SOM. The programming needed to implement DSOM servers adds even more complexity. This is not a trivial retrofit to existing code. Plus, it’s SOM++ and all that it implies.

Apple states that OPF will hide the differences between SOMand DSOM, and between local and remote objects. The A6 release code and documentation do not indicate how that will be done. [By the time you see this, Apple may have made this clear through a subsequent release - Ed stb]

As Microsoft is apt to point out, this relative simplicity of COM does not mean that the COM implementation is less robust; the opposite seems to be the case. For example, DSOM does not have any built-in capability to detect and resolve deadlocks while COM handles them properly. Programmers must manually design for support of multithreaded object servers under DSOM; not so under COM because of the operating system-level infrastructure underneath.

White Noise

There is a recurring problem with comparisons of the two technologies emanating from both camps. Both approaches are fundamentally sound and many of the “problems” can be fixed with little or no effort. For example, one of the most vocal criticisms of OpenDoc from Microsoft is that OpenDoc parts must be accompanied by the corresponding part handler code or they can’t be displayed or printed. In other words, if you don’t have the right part handlers installed on the user’s machine, she will just see big gray boxes where her objects should be. However, the OpenDoc folks could solve that at a stroke by requiring that all OpenDoc parts store a PICT image as a property, thereby allowing displaying and printing with or without the right part handler code.

There are outright distortions that show just how sloppy the discussion has become. For example, one supposed knock against OLE is that to activate a nested object one has to double click on the outermost object, then keep activating inward one object at a time. There are two problems with this: It is within the OLE spec to implement activation outside-in or inside-out a la OpenDoc and it is also within the OLE spec to use a single click rather than a double click to activate an object. OLE Controls illustrate these two facts by implementing an OpenDoc-style activation model - inside-out, single-click - while staying within the OLE specification. Apple also claims that the way that OLE finds server code, using file pathnames that a user can easily screw up, is a serious flaw in OLE. What Apple doesn’t point out is that Cairo, which is supposed to ship not too far from OpenDoc final, fixes all that. Granting equal time, Microsoft has decried OpenDoc’s requirement for part viewers on all the machines in a network that might need to access parts. This, it is claimed, requires engineering the software separately for each platform, neglecting to mention that the OpenDoc Parts Framework (OPF) class library is designed to provide source code compatibility across platforms and that only on machines supporting the Windows API is similar source compatibility assured for OLE. Both sides cite the supposedly extraordinary difficulty in using the other guy’s product, forgetting to mention that each has class libraries, OPF on the one hand and the Microsoft Foundation Classes on the other, that dramatically simplify things. Excuse me, my headache is back.

To Market, To Market, Lickety Split

Both OpenDoc and OLE present acceptable user interfaces. There are differences, and as of today’s specifications OpenDoc gets the nod. How much of a nod depends on your particular priorities, for while OpenDoc does, in fact, do a better job of improving the user experience, OLE is likely to get you into the component software market faster and is certainly not a bad user interface even today. In the time since Apple first started working on Taligent and later OpenDoc, Microsoft has released a steady stream of new, incrementally improving technologies, bringing the market and the industry along with them slowly but very surely. There are now hundreds of vendors of everything from DLLs to VBX controls to OLE objects that have experience in the marketplace for component software. It will take years for the Apple world to gain that level of experience with how to develop, package, price and support the sort of components needed to make OpenDoc a success.

Microsoft provides as seamless a growth path into OLE as OpenDoc presents a seamless user interface across parts. Companies that already know how to write Windows applications can start shipping OLE-aware applications with an absolute minimum of effort and with little or no rewriting or redesign of existing code. The ramp from there is gently sloped until one is shipping OLE Controls, the full-fledged equivalent of OpenDoc parts. Going from single-process COM to fully distributed objects involves no more than installing a new DLL. There are no new programming languages to learn, as there are with SOM. It is foolish to claim that all of these dollars and cents issues should be swallowed up by a single-minded quest for better user interfaces.

There are two different business models at work, Apple’s quantum leap approach to software and Microsoft’s continuous incremental refinement. I suspect there is room in the market for both, as long as the technological differences are narrow enough. Eventually, I expect this intense competition will reveal a case study in the way market economies are supposed to work: Both the OpenDoc consortium and Microsoft are being pushed to adopt the best features of each and this is improving the lot of consumers on both sides of the aisle.

The Mid-Term Report Card

OK, let’s cut through all this and reduce it to letter grades. To do this, I’m going to use a reasonable extrapolation of what will be available within twelve months; anything else gets too messy to do a direct comparison.

Subject OLE OpenDoc

Binary object standard B F

Compound document storage B B-

User interface A(1) A+

Distributed object support A+ B(2)

Ease of learning B C

Ease of adoption (3) A C

Overall grade A- B-

(1)Assumes OLE Controls and Cairo. Without these the grade would be C+ (no pun intended).

(2)This is purely for the DSOM extensions, since SOM itself is graded separately.

(3)Principally the smoothness of the growth path from existing development practices.

Overall grades are weighted evenly across all subjects. I won’t quibble with anyone that wanted to assign the user interface more weight, which would improve OpenDoc’s grade but not lower OLE’s. Were OpenDoc to use COM rather than SOM, the overall OpenDoc score would climb dramatically. Well, I can dream, can’t I?

 

Community Search:
MacTech Search:

Software Updates via MacUpdate

Google Chrome 96.0.4664.55 - Modern and...
Google Chrome is a Web browser by Google, created to be a modern platform for Web pages and applications. It utilizes very fast loading of Web pages and has a V8 engine, which is a custom built... Read more
Bartender 4.1.21 - Organize your menu-ba...
Bartender lets you organize your menu-bar apps by hiding them, rearranging them, or moving them to Bartender's Bar. You can display the full menu bar, set options to have menu-bar items show in the... Read more
CleanMyMac X 4.9.3 - Delete files that w...
CleanMyMac makes space for the things you love. Sporting a range of ingenious new features, CleanMyMac lets you safely and intelligently scan and clean your entire system, delete large, unused files... Read more
ffWorks 2.6.4 - Convert multimedia files...
ffWorks, focused on simplicity, brings a fresh approach to the use of FFmpeg, allowing you to create ultra-high-quality movies without the need to write a single line of code on the command-line.... Read more
Thunderbird 91.3.2 - Email client from M...
As of July 2012, Thunderbird has transitioned to a new governance model, with new features being developed by the broader free software and open source community, and security fixes and improvements... Read more
Adobe Photoshop 23.0.2 - Professional im...
You can download Photoshop for Mac as a part of Creative Cloud for only $20.99/month (or $9.99/month if you have purchased an earlier software version). Adobe Photoshop is a recognized classic of... Read more
VirtualBox 6.1.30 - x86 virtualization s...
VirtualBox is a family of powerful x86 virtualization products for enterprise as well as home use. Not only is VirtualBox an extremely feature rich, high performance product for enterprise customers... Read more
Merlin Project 8.0.2 - Project managemen...
Merlin Project is the leading professional project management software for OS X. If you plan complex projects on your Mac, you won’t get far with a simple list of tasks. Good planning raises... Read more
XMind 11.1.2 - Mind mapping and project...
XMind is a mind-mapping tool based off of the same open-source project as XMind Pro. It supports the same map structures and 100% compatible with XMind. It has new themes, some with more muted tones... Read more
WiFiSpoof 3.7 - Change your WiFi MAC add...
WiFiSpoof quickly and easily allows you to change your WiFi MAC address via hot-key or the system menu bar. Version 3.7: Fixed a potential issue with displaying current network on macOS Monterey... Read more

Latest Forum Discussions

See All

5 futuristic games like PUBG New State
The biggest flex of PUBG New State is its futuristic background. The new battle royale game is set in 2051. It has a new map, Troi, and also has a future version of Erangel. The weapon customization, drones, and other new features make it a new-... | Read more »
TouchArcade Game of the Week: ‘Jump Jerb...
I love games that don’t mess around. No frills or fluff, just “Here’s what I am and here’s what you get." That’s the vibe I get from Jump Jerboa from self-described “mostly solo" developer Chinykian. This is a minimalist one-button platformer that... | Read more »
SwitchArcade Round-Up: ‘Date Night Bowli...
Hello gentle readers, and welcome to the SwitchArcade Round-Up for November 26th, 2021. In today’s article, we look at the rest of the releases for the week. There are a couple of good games in today’s batch, and we’ve got summaries of the whole lot... | Read more »
Musical 2D Platformer ‘One Hand Clapping...
Bad Dream Games’ One Hand Clapping was originally a project demo at the University of Southern California and it has evolved into a full game that blends music with 2D platforming. It was previously revealed for PC and consoles and it is also now... | Read more »
Best Black Friday 2021 iPhone and iPad G...
Just like last year, many retailers have been discounting and price matching games and hardware well before Black Friday. The App Store has some great deals on iOS games that are available right now and more that will likely start showing up in the... | Read more »
SwitchArcade Round-Up: ‘DoDonPachi Resur...
Hello gentle readers, and welcome to the SwitchArcade Round-Up for November 25th, 2021. Today is Thanksgiving in America, so many of you will be off work or school. In Japan, it is just Thursday, so I must work as usual. In spite of the holiday,... | Read more »
The Best Black Friday Nintendo Switch eS...
Hello, friends. It’s that time of the year again. The most magical of times, when over a thousand Nintendo Switch games get discounts on the eShop that make them very hard to resist. Unless you’re enormously wealthy, you’re going to have to make... | Read more »
Lineage2M: 4 Reasons to Be Excited About...
With staggeringly beautiful visuals and fast-paced gameplay, Lineage2M is high on everyone’s list of most anticipated mobile games before the end of the year. The upcoming Lineage title is set to land for PC and mobile devices on December 2nd so,... | Read more »
New ‘My Time at Portia’ Update Adds Supp...
Last week, a new content update for My Time at Portia ($7.99) from Pathea Games was announced. The game released on mobile a few months ago thanks to Pixmain and it is a pretty great conversion. | Read more »
Out Now: ‘Super String’, ‘Ghostbusters A...
Each and every day new mobile games are hitting the App Store, and so each week we put together a big old list of all the best new releases of the past seven days. Back in the day the App Store would showcase the same games for a week, and then... | Read more »

Price Scanner via MacPrices.net

Black Friday Sale: Get an 11″ M1 2TB WiFi iPa...
Amazon has the 11″ M1 2TB WiFi iPad Pro, in Space Gray, on sale for $1648.99 shipped as part of their Black Friday/Cyber Monday 2021 sale. Amazon’s price is $250 off MSRP, and it’s the lowest price... Read more
The best Black Friday/Cyber Monday 2021 deal...
Apple has a full line of 2020 13″ M1 MacBook Airs available and in stock today, Certified Refurbished, starting at only $849 and up to $190 off original MSRP. These are the best deals on 13″ MacBook... Read more
Expercom offers $40 discount on AppleCare+ wi...
Take $40 off 3-year AppleCare+ Plans ($209, regularly $249) when purchased alongside new 13″ M1 MacBook Pros at Apple reseller Expercom. All models are in stock today: – 2020 13″ MacBook Pro M1 CPU/... Read more
Black Friday Clearance Deal: 21″ iMacs for on...
Amazon has recently-discontinued 2020 21″ 2.3GHz Intel-based dual-core i5 iMacs (8GB RAM/256GB SSD) on clearance sale for only $879 shipped. Their price is $220 off original MSRP, and it’s the lowest... Read more
These wireless carriers will give you a free...
Apple’s wireless partners are offering several deals on iPhone 13 orders right now. If you’re an existing customer or willing to switch carriers, you can get a free iPhone 13 this Black Friday/Cyber... Read more
This 10.2″ Apple iPad is on sale for $319 for...
Apple’s new 9th generation 10.2″ is in short supply this Black Friday 2021 weekend, largely due to global supply constraints. Of all the Apple resellers we track, only one is reporting stock of the... Read more
The best Black Friday 2021 Apple Pencil sales...
Apple resellers are offing Apple Pencil models for 20%-23% off MSRP as part of their Black Friday 2021 sales. These are the cheapest Apple Pencils for sale this weekend: 1 – Amazon has Apple Pencils... Read more
Black Friday 2021: Take $20 off Apple Watch S...
Amazon has Apple Watch Series 7 models on sale today for $20 off MSRP including free shipping. Their prices are the lowest currently available for Series 7 Watches for Black Friday 2021: – 41mm Apple... Read more
Black Friday Only! Get last year’s 4-core Mac...
B&H Photo has last year’s Intel-based 3.6GHz 4-core Mac mini on clearance sale for only $429 for Black Friday 2021 only. Their price is $370 off original MSRP for this mini, and it’s the lowest... Read more
Black Friday 2021: Get an M1 Mac mini for as...
Looking for the cheapest Mac with an Apple M1 processor this Black Friday 2021? Apple’s Mac mini starts at $699, and resellers are offering models on sale this weekend for as low as $589 and up to $... Read more

Jobs Board

*Apple* Mac IT Support Specialist - Randstad...
Apple Mac IT Support Specialist **job details:** + location:Worcester, MA + salary:$40 - $45 per hour + date posted:Thursday, November 11, 2021 + job type:Contract + Read more
Senior Software Developer - *Apple* (iOS/tv...
**SUMMARY** Hulu's Apple team is seeking an experienced Senior Software Engineer with a passion for mobile applications to join our team in Seattle. Our highly Read more
*Apple* Management Engineer | Information Te...
Job postings Apple Management Engineer | Information Technologist II Share this: + + + + + | More (http://www.addthis.com/bookmark.php?v=250&username=pageup) Back to Read more
Department Manager- Tech Store (Full-time, Ge...
…+ Provide on-site support for in-shop repair on a variety of Apple computers and peripherals using advanced computer and electronic repair techniques and Read more
*Apple* / Macintosh / Jamf / Adm Systems Adm...
…Administration **Duties and Responsibilities** + Configure and maintain the client's Apple Device Management (ADM) solution. The current solution is JAMF supporting Read more
All contents are Copyright 1984-2011 by Xplain Corporation. All rights reserved. Theme designed by Icreon.