In a recent interview, Sun's chief engineer Rob Gingell re-emphasized what many Sun officials right up to Scott McNealy have often told me: binary compatibility (I'll call it BC for short) is a priority for Sun and should be for everybody. Sun has made BC one of the chief selling points of its Sparc-based solutions and, going forward, it will again be the driving force behind Sparc's successor as the heart and soul of Sun--Java. What is BC? Sun will tell you it's investment protection that no IT shop can do without.
BC refers to the compatibility between successive generations of hardware or software and the extent to which software that runs on top of that hardware or software must be recompiled into new "binaries" in order to execute properly.
Over three decades, we've witnessed some high-profile case studies in BC--or the lack thereof. We watched Microsoft navigate (rather brilliantly) the treacherous waters of BC (often stirred by changes in Intel's architecture). We watched MS-DOS manage the not-so-painful switch from the 8-bit 808x architecture to the 16-bit 80286. For the most part, BC was not lost. Even if it was, we would have put up with it. That switch was accompanied by such a significant performance boost that few people would have stuck by the sloth-like 808x-based machines.
But the subsequent switch to 32-bit computing was a bit more challenging. Microsoft did a rather masterful job of getting Windows to juggle 16- and 32-bit applications and device drivers (both DOS and Windows-based) in a way that didn't leave a bunch of its customers and their 16-bit hardware (or drivers) and applications out in the cold.
As a member of the press at that time, I remember those days well. We sniffed out every break in BC (often after being tipped off by our readers) and clamped on like pit bulls as though each break was "the one" that would cause the growing Microsoft empire to unravel. It never happened. The case study is even more remarkable considering that Microsoft had to deal with competitors like OS/2 and DR-DOS, both of which arguably had better BC with Microsoft's legacy operating systems than Microsoft did with its own OS.
Twenty years later, the entirely 32-bit Windows XP runs quite nicely on Intel's 32-bit architectures, the 8- and 16-bit legacy stuff is for the most part history, and Microsoft is little if any worse for the wear because its customers have managed despite binary incompatibilities from one generation of OS to the next.
While Microsoft's operating systems (and Intel's processors) have forgone BC at times during the last two decades, the other case study --- Sun --- has been building a franchise around binary compatibility as though it were the Holy Grail. Almost every time I've seen Sun CEO Scott McNealy in a public forum, he rehashes BC as a fundamental selling proposition of Sun. He will take any opportunity to remind us that, regardless of whether software was written to run on the Solaris/Sparc combination 20 years ago, or yesterday, it will run on any Sparc-based system without recompilation. For emphasis, he uses dollar signs, saying "the same binaries that run on the systems we sell for millions of dollars will run on the system we sell for under a $1,000." Theoretically, this may be true. In reality, we all know that the million-dollar system has the resources needed to run applications that would choke the $1,000 system.
Even so, McNealy has been staking out this position more frequently now that Sun's Sparc processors are getting some heat from Intel's 64-bit architecture (IA-64). Sun officials will never let you forget that recompilation is a fact of life as you move up the Wintel food chain.
A little known fact: For performance reasons (but not binary incompatibilities), Intel suggests recompilation when moving from Itanium I to Itanium II. But in the case of applications, it's not always necessary. Intel may also have more to thank Microsoft for than most people realize. Where various generations of Intel's processors have lacked binary compatibility with their predecessors, Microsoft usually steps in at the OS level to ameliorate those binary incompatibilities with a translation process that programmers call thunking. As a result, many applications were able to run without recompilation, albeit with the traditional performance penalty that any system pays when some form of real-time translation is necessary.
Big Java, little Java
McNealy likes to talk about BC as though Microsoft and Intel have committed some great crime on humanity. Is binary compatibility all it's cracked up to be? Only you can answer that question. (Write to me at david.berlind@cnet.com.) But one thing is certain: As Sun transitions itself from the company that bet the farm on Sparc to betting the farm on Java, it's not going to ditch the binary compatibility pitch any time soon. Like Sparc, binary compatibility is a major part of Java's write-once, run-anywhere ethos and promise. Now, Sun officials like to talk about "big Java" (aka J2EE and J2SE) and "little Java" (aka J2ME and Personal Java) and how they are binary compatible right down to the security model.
But in the same way that binary compatibility may not be able to overcome resource issues that differentiate a $1,000 server from a $1M server, similar challenges await Java. J2SE has GUI capabilities that J2ME does not. If a programmer accesses the GUI facilities in J2SE, that same program won't run in J2ME because those facilities don't exist.
Other insidious problems exist too. Recently, the CEO of a well-known software company that's diversifying into mobile applications explained how his developers are having difficulties with the write-once, run-anywhere promise of Java. After writing an application that should supposedly run on any J2ME-based MIDP-compliant (Mobile Information Device Profile) device, his developers discovered that all such devices are not created equal. One device, (Motorola's i85s phone) allowed up to eight characters for labeling the functionality of the device's buttons. A newer device (Motorola's i95cl Color Java phone) only allowed for seven. As a result, the program that worked fine on one device had its button labels truncated on the other.
Sure, the problem sounds rather esoteric. But it's exactly such problems that are often cited by those who dismiss BC as bunk while attempting to provide customers with their own bunk. Not that Microsoft won't have similar problems as versions of its mobile operating system show up in all sorts of devices.
Speaking of Microsoft, it has been bitten by the BC bug as well. Surely, one of the chief selling points of the .Net framework will be binary compatibility of the applications that run on it. As it turns out, BC is, for the most part endemic to anything that can be considered middleware (i.e., Java or .Net).
Is BC the key to your IT decision making, or is it just a red herring? Let me (and the vendors) know by talking back below. Or, write to me at david.berlind@cnet.com.
