Despite Steve Jobs's statement that everything about NeXTSTEP and NeXTSTEP for Intel was the same, observers remained skeptical. PCs are indeed different than NeXTstations: different video displays, different keyboards, different mice. Wouldn't programs have to be modified? Furthermore, the Intel and Motorola microprocessors represent numbers with exactly the opposite byte order: Wouldn't data files written by one have to be translated to be readable by the other?
A year later, it seems that most of these fears were unfounded. That's because, unlike in the DOS world, NeXT programs don't directly access the computer's hardware; they communicate with the NeXTSTEP operating system instead. By porting the operating system itself, NeXT has hidden all the differences. (The idea of porting applications by porting the operating system dates back to 1977, when Bell Labs ported the UNIX operating system from a DEC PDP-11 to an Interdata 8/32.)
In my experience, programming NeXTSTEP for Intel is almost exactly the same as programming a NeXTstation. For example, every program in my book, NeXTSTEP Programming, can be run on NeXTSTEP for Intel by simply compiling the program on a '486 computer. I also tried porting SBook, my 26,000-line address-book program. The program worked on NeXTSTEP '486 the first time, without a single line of code being modified.
Other programs may not fare as well. For example, windows that are wider than 800 pixels or higher than 600 simply won't fit on the smaller screen of most '486 systems. And some programs, like WriteNow, won't port at all, since they're mostly written in 68000-assembler language.
Data-file compatibility is likely to be a nagging problem for some developers.
NeXTSTEP's archiving package will automatically swap bytes, but developers who write their own � or who use bit fields � will have to modify their programs to deal with this nagging architectural incompatibility. SBook does neither, but another program I wrote did its own archiving, and I still haven't tracked down all of the byte-swapping bugs.
Other NeXT programmers are reporting similar expe-riences. It took David Pollak, president of Athena Design, just 30 minutes to get his Mesa spreadsheet work-ing under NeXTSTEP for Intel, though it took the better part of a week to get all of the bugs ironed out to provide true file compatibility.
Not surprisingly, SunSoft reports similar experience with developers porting from Solaris on SPARC to Solar-is on Intel. Most Solaris developers only have to re-compile their application. "It's taken as little as 30 minutes; the longest that I know of was three days," says Judy Borcz, a product manager at Sun.
Windows NT developers tell similar stories about moving from Intel to high-performance RISC architectures. "Third parties that have already ported to NT are experiencing very little difficulty in moving to the Alpha platform. In most cases it's just a recompile," says David Price, a manager at Digital Equipment Corporation's Windows NT project.
Operating in a mixed environment � Intel and Motorola, or Intel and SPARC � is a different matter entirely. NeXT is the only company that has announced any sort of system for letting two different architectures run from a single binary. NeXT's "fat binaries" should make life easier for both developers shipping programs on floppy disks and system administrators trying to manage heterogenous networks.
NeXT has also modified the UNIX file system so that floppy disks and hard drives formatted on one kind of computer can be readily moved to another � something that NT does but Solaris doesn't. "At Sun, we used to move data around on DOS floppy disks," says Bob Lawton, NeXTSTEP for Intel program manager, who formerly headed Sun's Solaris on Intel project. "That's stupid."
by Simson L. Garfinkel