(This weekly column looks at features and products that revolve around Mac OS X, Apple’s next generation operating system that’s due in early 2001. If you aren’t familiar with terms like “Rhapsody” and “OpenStep,” check out our explanatory “Note” at the end of this article before proceeding.)
This week we’re looking at the UNIX aspects of Mac OS X — specifically the ability to run UNIX executable programs under Mac OS X — in the second of a three-part series. This information is based on my conversation with others as, admittedly, UNIX is not an area of expertise for me. As I try to point out on occasion, this column is written by an advanced end user (Yours Truly), not a programmer or developer. However, the folks quoted in this article do fall into these categories or otherwise have extensive UNIX experience. Be warned: this week’s installment is pretty technical.
Programmer Michael Baltaks said a great deal of UNIX software is available as source code, which means that the easiest way to run this software on Mac OS X is simply to compile the source into a Mac OS X program. Sometimes this isn’t a simple compile, but rather someone needs to “port” the code — in other words, get the code to compile and run, he said.
“This is usually not a huge effort and will become easier as more work is done in Darwin to support the things most UNIX software needs,” Baltaks said. “For example, I have already compiled Apache and php and mysql together under the Mac OS X public beta for Web development, but it required some patches from a third party. However, I don’t expect to need patches by the time Mac OS X ships.”
With that said, “UNIX executable programs” sound more like binaries and Baltaks said there are three things that describe a binary program:
Processor architecture (Athlon/iX86, PowerPC, Sparc, Alpha, MIPS, etc.). “A binary compiled for one of these will typically not run on any other.”
Operating system (Mac OS 9, Mac OS X, GNU/Linux, BSD, Windows, etc.). “Even if a binary is for the same processor, if it is compiled for a different operating system, it will typically not run.”
Binary format (ELF, Mach-O, a.out, etc). “Even on the same processor and operating system there are different ways of formatting binary executable programs, although typically there is a very dominant format for each OS, so this is not often an issue since the programs you want to run are all in the most popular format.”
It sounds like there are a lot of problems but the fact is anyone who uses a product like Virtual PC already runs a program that translates programs between these. Baltaks said there are a couple of ways to do this:
Emulate the processor: By directly translating at the processor level, it indirectly translates at the other two levels, meaning that you can run a full copy of the other OS on a processor that doesn’t run that OS (as Virtual PC does with Windows, GNU/Linux, etc). The major downside here is that this is much slower than native speed, Baltaks said. The benefit is that you get the full environment of the other operating system.
Emulate the OS: FreeBSD has mechanisms to run GNU/Linux programs on the same type of processor (iX86), so this is translation at the operating system level, and it works just fine, according to Baltaks.
“However, as far as I know, it only works for ELF binaries, not a.out binaries, and it only works on the same type of processor. With this method you get the foreign program running on your OS, without the other environment. However, since you are only doing some light translating, you get very good speed from this method. And if you like the host environment then you get to use that as well.”
If the software program binary you want to run is for a different processor than the one you want to run it on, you need to emulate the processor. If you do so, then you can run a full copy of the other operating system, there’s no gain from doing any more. Solutions like Virtual PC are a very good option when you need your processor to pretend to be a different processor.
If the software is for the same processor but a different operating system, then some runtime environment software can be developed to translate between the program and the operating system. This will give near native performance (such as Classic in Mac OS X, GNU/Linux programs in FreeBSD, and Wine for GNU/Linux), Baltaks said.
“For example, in the case of running a Sun Solaris Sparc program on Mac OS X on PowerPC, you would need to emulate the different processor, which slows the program down a lot,” he explained. “Once you have emulated the processor you might as well run Solaris on top since you have a full run time environment going, and now you have ‘VirtualSparcStation.’ This would be a costly and slow way to run things, but as far as I know it’s the only way.”
In the case that you’ll want to run a LinuxPPC, YellowDog Linux, Debian PPC, NetBSD PPC, OpenBSD PPC, or some such binary on Mac OS X, Baltaks said. It’s possible for someone to write a translation layer for a specific type of binary that would link to Mac OS X equivalents in real time.
“There would be different levels this could be done for,” Baltaks said. “You could require an X-Windows Server to be present and link to that. Or perhaps provide translation libraries to make a LinuxPPC X-Windows program use Quartz instead. This last option would be wonderful — and probably a lot of work. Having looked at this, it’s very unlikely since most LinuxPPC software is available as source code so there would be almost no reason at all for having any run-time translation software.”
With Mac OS X’s ability to run Mac OS classic programs, UNIX and Linux source code programs and Mac OS X (Carbon and Cocoa) programs, and Java programs, he doesn’t see any real need to run many binary UNIX programs.
“For what small need is there, specific emulation software is needed to allow Mac OS X on PowerPC to run SomeUNIX on SomeProcessor software. If the need is there, then as we have already seen with Virtual PC and SoftWindows, it will most likely be meet by a commercial vendor.”
Moving on, Tom Zerucha, a developer, said that there’s now an X server that works with Quartz, though not quite at the same time. You have to do Apple-option-A to return Quartz or click an icon to get back to X. However, Zerucha said he has run Enlightenment (from Gnome) and Mac OS X at the same time.
He’s starting to develop for Darwin and/or OS X, having done a lot of Linux development, but has always enjoyed the Mac interface. The largest problem he’s run into currently is the IOKit, but said he can see problems with the other areas Apple changed from the traditional BSD.
Also, remember VVI, a privately held corporation, is preparing a big push into Mac OS X territory and needs some Mac user input, Ed VanVliet, director of application development, told MacCentral.
For this reason, the company has set up an
where users can submit what they want. However, VVI will expand its presence into X territory by expanding its current focus.
VVI’s customers are world-leading companies in the banking, biotechnology, chemical, financial services, manufacturing, and pharmaceutical industries. For these customers, the company has built systems that are, in part, based on VVI’s OpenGraph data reporting solution.
“We’re ready to bend over backwards for the Mac OS X user,” VanVliet said. “Since our field is technical in nature, the feedback would be in technical fields: science, engineering, academic, research, medical, industrial, mathematics, instrumentation, statistics, graphic design (for technical reports), image and mapping transformations, financial modeling, financial service reporting, any type of computer modeling (although I would accept pictures of non-computer models as well), numerical, machine, factory, environmental control, etc.”
(Note: Mac OS X is the upcoming, “next generation” operating system from Apple, due in the first half of 2001. Mac OS X will include components of the traditional Mac OS, as well as components of the Rhapsody project. Rhapsody was once planned as Apple’s next generation operating system. It’s still around as Mac OS X Server, and parts of Rhapsody technologies will become part of Mac OS X. Rhapsody/Mac OS X Server is partially based on OpenStep technologies that Apple obtained in the purchase of the NeXT company. Carbon is the modified version of the Mac OS application programming interfaces (APIs) that lets applications be rewritten with relative ease for Mac OS X.)