Home > Hardware

Computerworld - Binary compatibility is an old idea that involves both hardware and software. Two computers can be considered binary compatible if they can run the same software without requiring that the application be recompiled. The computers can be different generations of machines from the same manufacturer, or they can be competing products from different vendors.

For example, an IBM ThinkPad laptop and a Hewlett-Packard Vectra desktop computer are binary compatible, even though the machines may use completely different components throughout—brands of processors, motherboards, types of memory chips, graphics hardware, disk drives and support chips.

What about an iMac from Apple Computer Inc. and a NetVista from IBM? The iMac can run emulation programs that in turn run Windows applications, such as Microsoft Word. But that's not binary compatibility. For all practical purposes, what an emulation program does amounts to retranslating the software—effectively (but not efficiently) recompiling it to run on a different hardware platform.

The truth is, the iMac can't run Windows applications in native mode, just as the NetVista can't run Macintosh applications.

Thunking

Perhaps the most telling examples of binary compatibility (and incompatibility) have been shown by Microsoft Corp., with its DOS and Windows operating systems and its Office applications suite.

As Intel changed its microchip architecture over the years, Microsoft transitioned MS-DOS from 8-bit to 16-bit machines with little loss of compatibility. Intel's subsequent switch to 32-bit processors was harder to manage, but Microsoft did get Windows to juggle 16-bit and 32-bit applications and device drivers (both DOS- and Windows-based) in a way that didn't leave behind a lot of customers and their 16-bit hardware and applications.

Now, with Intel's new Itanium 64-bit microprocessors, the chip manufacturer and Microsoft are suggesting that software be recompiled for performance, not compatibility issues.

Over the years, as many successive generations of Intel processors have lacked backward compatibility with their predecessors, Microsoft has stepped in at the operating-system level with a translation process called thunking. Thanks to thunking, many applications could run without recompilation, but they would take a performance hit, as with any real-time translation process.

Unix Flavors

While binary compatibility has been around for a while, it's taken on special importance within the Unix and Java worlds.

Unix was originally developed to simplify moving applications from one type of computer to another, but once it went commercial it almost immediately diverged into many competing products, including Solaris, Irix, HP-UX, AIX, SCO Unix and BSD Unix. These products were just different enough from one another to create major headaches for developers and IT departments.

As the biggest player in the Unix world for some time, Sun Microsystems Inc. has been trumpeting binary compatibility for most of its existence. Sun CEO Scott McNealy frequently notes that software written 20 years ago to run on the Solaris/SPARC combination will run on any current SPARC-based system without recompilation.

Of course, while it's theoretically possible for binaries running on a multimillion-dollar system to run on a server that costs less than $1,000, it's also true that the more expensive system has the resources needed to run software that would overload the small system.

In the mid '90s, Sun began to realize that Solaris' main competition wasn't the other Unixes, but Microsoft Windows—especially Windows NT and what's now called .Net. So Sun introduced Java as a platform-independent language whose programs would run on different architectures without change to the code. The company achieved this by having Java compile into an intermediate form of binary code, called byte code .

For each type of machine, all that was needed was an on-the-spot translator called a Java virtual machine. But how does this differ from emulation? The distinction is subtle but real: Because a Windows binary was designed to run natively on a particular architecture and instruction set, it's therefore optimized for that platform (and thus against others) in thousands of ways, large and small. But Java was never tied to a single platform and architecture, so it doesn't need to incorporate their quirks.

One final thought: Binary compatibility also implies interoperability with all the original's bugs and quirks—that all the shortcuts and work-arounds that people have been creating for years to accommodate those bugs will run correctly on the compatible machine.

Kay is a contributing writer and consultant in Worcester, Mass. You can reach him at russkay@charter.net.

How It Works This diagram shows one form of binary compatibility between two computer architectures. The one on the left uses a single Intel processor, while the one on the right uses dual processors made by Advanced Micro Devices Inc. in Sunnyvale, Calif. Despite these hardware differences, both computers can run the same operating system and execute the exact same binary code without it having to be recompiled or modified.

---

See additional Computerworld QuickStudies

Read more about Hardware in Computerworld's Hardware Topic Center.