OS X for IBM PC?

Factual Questions
1

I don’t mean to start another apple v wintel thread here, but I’m kind of curious about speculation that a version of OS X could be made available for IBM PC’s. The argument seems to be that as OS X is based on Unix it shouldn’t be too big a deal to produce a version which could compete with Windows, Linux, BeOS etc on the PC platform.

I might as well declare my own bias here and say that I would only consider buying a Mac if I could afford one in addition to an up to date wintel box. The main reason for this is that I like the modular nature of PC’s better than the proprietary nature of Macs, i.e. if I can’t build it out of bits myself, then I don’t want to know.

BUT

If I could have a dual boot system on the *86 architecture which could run both Windows and Mac OS, I’d jump at the chance.

My questions are

  1. Could it be done?

  2. How hard would it be to do?

  3. Would you buy it?

milo

2

I really don’t have that much thirst to run Mac OS. I have spent to much time on to many operating systems to take another one under my belt. At one point in time I was running BSD, Linux, WinXP, and BeOS across my network. I’ve since converted the BeOS machine to another WinXP machine. I have given a great deal of though to picking up the new Mac laptop(the one with the 15.2" screen that is only an inch thick and weighs like 5 pounds) and loading Linux for PPC on it. BeOS gave me enough taste of what Mac OS is all about.

3

Well, a portion of the Unix part of OS X, named Darwin, does run on Intel processors. (see here for more information).

However, that’s a far cry from the complete OS X as shipped by Apple. The Mac-style GUI isn’t there, so you couldn’t run, say, any OS X application on your Darwinized PC at this stage. Apple doesn’t really have any plans to do this, as they’re in the business of selling their own computers as well. They don’t want to end up being an OS-only company.

Not that you couldn’t get a GUI going on an Intel with Darwin – see this link, where they have an X windows running on Darwin. Of course, this isn’t really anything new, since X has been running on Unix machines for many years.

4

You can dual-boot Windows and MacOS on Power-PC machines. Granted, that’s not the *86 architecture and it may require non-standard Power-PC hardware, but it is doable. We’ve got a lab full of machines that dual-boot Win95 and some version of MacOS because the people using the lab needed to run existing software for both platforms.

So, it can be done, it’s not hard, and I wouldn’t bother with it myself. I see very little reason, but then I see very little reason for Macs anyway except they look nice with the furniture.

5

MacOS X on x86 hardware is never ever going to happen. Sure, it could be done, but what would that give you? The world’s greatest Unix system, but with no applications. MacOS X apps would all need to be recompiled for x86. No existing apps would run, most would need major porting work.

6

This is the crux of the matter. Apple makes a lot of their money selling their hardware. They’ve spun off their applications division, so all that’s left is hardware and O/S. Not a lot of money in OS’s when you have no apps of your own to run on them. Remember, Micro$oft was an applications company before they were an OS company.

Also, one of the keys to the stability of the Mac platform is that since they control the platform, they only have to support their hardware and none other. No worries about marginally incompatible hardware doing wonky things. If they migrated to the x86 platform they’d give up this edge.

7

<bernse sticks neck around corner>

Sooo… you’re saying it’d be just like another Mac?

<runs away real, real fast!>

:wink:

8

frogstein’s on target here.

But there are long repeated rumors out of cupertino that Apple has maintained x86 builds of Mac OS X but has opted not to do the final QA & release on them. I have no doubt that if Apple suddenly decided it was in their interests to run on Intel, that we’d see it in pretty short order.

9

Uh, actually DOS 1.0 pretty much predated any applications put out by Microsoft.

On the other hand, I don’t consider DOS (or Windows for that matter) much of an operating system, so, I’ll give you the match. :slight_smile:

10

Oh yeah. I meant to post a serious response.

Mac OS X on Intel isn’t all that unfeasible. Apple originally planned on something called “Yellow Box” which was a separate API from the now equal Carbon/Cocao/Java2 on Mac OS X. “Yellow Box” apps would have run on Windows or the Mac OS from the same source code. “Yellow Box” applications would have been distributed as “fat binaries” whereby the processor object code for both architectures would be included in the same file (Apple made this same thing work during the transition from 680x0 to PowerPC).

If you care to develop Java using the “Swing” APIs, you can get a Visual-Basic-quality type look and feel from the same source code on many, many platforms, although it seems Microsoft has abondoned Java “in the box.” Of course, Mac OS X supports Swing. Because compiled Java isn’t assembled into processor op-codes, but rather pseudo-code (like VB), it’s interpreted in a run-time engine in any environment.

Finally, none of that’s really good enough – the Swing Apps I’ve seen are awkward, and Yellow Box is dead. So what about Mac OS X on Intel?

As has already been pointed out, Darwin, which is BSD Unix atop a Mach kernal (essentially), already runs on Intel boxes. It’s mostly this “low-level” operating system that takes care of hardware interaction. Therefore, porting the user-interface wouldn’t be dependant upon hardware support for Intel vs Apple (and, uh, none of my external hardware is Apple, so that can’t even be a real concern). Once the hardware support is in the kernal of Darwin, the user interface builds right on top of it.

A user interface is essentially an API, i.e., an application programming interface. It’s kind of like a protocol, i.e., Macs and PCs both use HTTP. By porting the OS to Intel with the same API, in most cases the only thing that would need to be done to make the same source code work on both Intel and Mac would be a recompile. Then, we’re back at the ability to distribute as fat-binaries.

Apple also has real experience in emulation. Even to this day, the Mac OS includes a Motorola 680x0 emulator to support older applications that never made the migration to PowerPC. With this experience, it’s very probable that Apple could build a PowerPC emulator riding on an Intel chip. This would eliminate the need for fat binaries altogether. (I actually see the opposite happening – Apple may have to move to non-PPC architecture if Motorola keeps dropping the ball on PPC speed bumps) Emulation needn’t be all that slow. Running WinME on Virtual PC 4 under the Mac OS with a 400MHz G3, Norton Utilities benchmark tells me I’m running about 50% the speed as the same test on my HP Pavillion 600Mhz Celeron. Sure, not a speed demon, but it’s plenty quick for productivity work, plus the fact that VPC emulates the whole computer – not just the job of translating Intel to PPC.

11

Negative. 68k code runs native on PPC processors, it has nothing to do with emulation.

12

quote:

Originally posted by frogstein
Remember, Micro$oft was an applications company before they were an OS company.

Uh, actually DOS 1.0 pretty much predated any applications put out by Microsoft.

On the other hand, I don’t consider DOS (or Windows for that matter) much of an operating system, so, I’ll give you the match.

Actually Microsoft got it’s start by selling basic.

ben

13

I’m gonna cast my vote with Balthisar here. Mac OS includes a 68k emulator.

from Apple Developer Pages

14

Negative to the negative. Both processor families (the 680x0 series and the PPC series) are entirely different processors, with different designs and different op codes. The 680x0 was a “CISC” processor, i.e., it had a lot of opcodes to do a lot of different functions. The PPC is a “RISC” processor, it sacrifices opcodes for speed. The CISC/RISC debate is unimportant these days, but at the time, there was a huge difference. Essentially, the faster speed of the RISC could execute (for example) five op-code functions faster than a single op-code on a CISC, making the “R” part of RISC non-important (RISC=reduced instruction set chip; CISC=complex instruction set chip).

The PPC in no way executed 68000 code, since the required opcodes didn’t even exist any more! This is why the Mac OS needed (still needs) to provide 68000 emulation. This is the reason “fat binaries” existed – they contained 68000 CODE resources (resource fork) for older machines, and PPC code fragments (data fork) for PPC machines.

Interesting tidbit: most of the modern, classic Mac OS still can’t work without the emulator, even if you have the latest 9.2.1 with all pure, PPC applications. Many of the Mac’s toolbox calls are based on “traps,” that is, the use of op-codes that were never part of the 68000. Whenever the processor encounters an unimplemented instruction (a non-existent op-code), control is diverted to the OS’ trap dispatch table, which deciphers the unimplemented instruction into a ToolBox call. So without the 68000 emulator, the Mac Toolbox can’t even work!

15

beat you to your own defense, Balthisar : ) (and I even got a cite!)

but I’ll pick one little nit:

uh, even if Chas was right and PPC could execute 68k code, we’d still need fat binaries so an app could run on either platform.

I don’t know what proportion of the classic OS is still 68k, but I think that they reduced it a lot with the last few major releases.

16

Ah, interesting document, guys. I thought all this stuff got tossed when they abandoned that blue box/red box/yellow box stuff. But I’m still not quite sure this qualifies as true emulation like the core emu in Virtual PC or RealPC or programs of that type. It looks more like a memory handler. But if Apple wants to call it emulation, I won’t quibble.

17

:whoooosh:

Thanks for the responses folks, but a lot of this is parting my hair as it passes so I’m going to have to ask some more questions.

How much of OS X is Darwin? Is it everything except the GUI? If the Aqua interface was converted for use on Intel/AMD machines and installed with darwin, could the machine then run Mac applications which had been recompiled without changes to the source code as Balthisar suggests?

Or is it a lost cause?

(bolding mine)

How about Emulation? Is there an Mac emulator for PC’s which would allow me to install and use OS X in the same way as Balthisar semms to be able to use Win ME on a Mac?

milo

18

Not as of yet, although it isn’t beyond feasibility. In theory, you can emulate any digital hardware in software that runs on some other hardware. However, you’d take a speed hit. I have Windows 2000 Server as one of my Virtual PC operating systems, and it really makes my 500 MHz PowerBook pant and wheeze. MacOS X can make a 233 MHz G3 pant and wheeze, and even a good emulator running on a 1.8 GHz dual Pentium box would probably feel no faster than that.

The 68LC040 emulator built into the Mac operating system is much simpler than an emulator that has to emulate another platform’s entire chipset, and the Mac is not merely a PC with a different central processing unit.

19

Thanks for the defense. But what nit did you pick? Maybe I didn’t word it right. I meant that fat binaries included BOTH 680x0 code and PPC code, so that depending on the type of processor (old machine vs. PPC machine) the correct code would be used. Maybe that’s what confused everyone.

More specifically: 680x0 Macs CAN’T run PPC code, but they CAN run fat-binaries, 'cos the fat binary has BOTH the 680x0 and PPC versions of the exact same program. A PPC Mac CAN run 680x0 code because of the 680x0 emulator. However, emulation is slower, so PPC Macs should run PPC code. With fat-binaries, the PPC code is used instead of the 680x0 code. There even used to be “cleaner” applications that would shrink the size of Mac apps to remove the unused PPC code or unused 680x0 code from an Application, since it wasn’t being used.

I agree that probably all the ToolBox is now PPC native code, but for backwards compatibility, the trap-dispatch mechanism is still used to access ToolBox calls. Programmers don’t worry about this, though, since the compiler does the work. This is probably the biggest bottlneck in the classic Mac OS – just to make a ToolBox call depends on emulating a defunct processor!

Chas.E: Really, it’s an emulator, not just a memory manager. If you have pure, assembled 600x0 code, and try to execute it on a PPC chip, it won’t work – it’s just like trying to run assembled x86 code on a PPC. They’re completely different. Maybe your confusing the more common definition of an emulator – I don’t mean a “computer” emulator, since we’re not emulating a computer. Virtual PC is a computer emulator. There are a lot of computer emulators; try http://www.emulation.net. The emulator in the Mac OS is a processor emulator, i.e., it emulates a processor, specifically the M680LC40 (thanks Audient!). It converts machine instructions in Motorola binary format into the equivilent instructions in PPC format. Now of course, part of a machine emulator, such as VPC, also includes a processor emulator for doing the work of translating x86 to PPC.

20

yup, I understand fat binaries. maybe I misunderstood your prev post. It looked like you were saying that fat binaries existed as a refutation to the notion that ppc didn’t need an emulator. i.e. if there was a 68k emulator built in to ppc, then we wouldn’t need fat binaries. (we would so)

whatever. the OT is now fading weakly in our rear view mirror : )