There is an open source project going on at http://sourceforge.net/projects/winmac called WinMac. The sight homepage says “WinMac is attempt to clone Mac OS X for the intel platform using the Apple Darwin 1.2 kernel. There are currently two teams working on the project. The kernel team is working on the basic compiling of Darwin on Intel. The GUI team is researching the Aqua.”
Balthisar
Actually, not very probable at all. At least not with a performance that anyone would be happy with. There are radical architectural differences between the Intel chips (CISC) and the PowerPC chips (RISC). The Intel chips just aren’t up to the task.
Apple could conceivably release OS X for Wintel, but as has been pointed out it would simply be a look and feel copy; it wouldn’t be able to run native Mac applications.
I think there are good political reasons why Apple would not likely do this. Apple depends on Microsoft (and visa versa). Why would Apple want to step on the toes of their ally in a arena where they really would rather not play anyway (software for software’s sake)? Apple does software because Apple must do software to support their real business, hardware…
Maxwell Edison–Darwin ALREADY runs on Intel. I have a copy that runs on VirtualPC, just to see what it’s like. (command line Unix, of course). Apple made the source code available and I don’t think it took them long to compile it for Intel (and standard associated architecture).
The challenge would be cloning the rest of MacOS X, for which source code has not been released.
assumed with a porting of OS X to Intel is that native apps would have to be recompiled for it. Obviously, there are already plenty of compilers for x86. And by having the OS ported, that means that all existing calls to the OS would work.
Yes, recompiling Mac apps is a significant effort, but it is also one that has been handled successfully before (in the switch to PPC, and switch to Carbon).
Oh, I agree completely. All I meant was that it’s probable that Apple could–not would– build an emulator. Speed would suffer of course; anything in software does. Given the speed of Intel chips these days, a pure processor emulator may run at acceptable speeds, depending on your definition of acceptable. I don’t mean 500Mhz G4 performance out of a 2GHz P4, but something that works.
I don’t ever expect to see a port to Intel of OS X; that would kill Apple (which is, as you say, a hardware company). The OP was more along the lines of the technical possibilities. Along those lines, it would be silly to have a processor emulator, when the whole OS could be ported to Intel. It wouldn’t be just a look-and-feel clone. Once the toolbox is in place, the only real requirement would be a recompile. To use a REALLY basic example, WriteLn(fdgf) does the same thing on any computer. For specific applications where speed is involved, developers would have to take into account things like processors, such as the G4 vector math unit that can be used on the Mac but not the Intel. OTOH, given a smart compiler, maybe not?
audient
I think you miss my point:
Recompiling is not the same as porting. The effort to write software that is portable between Intel and Motorola platforms is tremendous (even with tool sets like CodeWarrior to help). It’s not something a developer generally does unless they intend to support both platforms (and even then sometimes not).
For most applications, we’re not talking about a recompile - we’re talking about a port.
Balthisar:
A Mac programming wizard I know looked at the instruction pipes and most frequent instruction sequences on both platforms and estimated it to about 8 to 1. In other words, a 2GHz Pentium IV could possibly emulate a 250MHz G4 - I guess we all have our own definition of acceptable performance. 
Both the Pentium III and Pentium IV support vector processing. Granted the Pentium III’s vector engine is so lame as to be almost useless, but the Pentium IV has a fairly respectable vector engine… too bad the rest of NetBurst micro-architecture is a NetBust.
curious - why do you believe that? True that the OS would need to be ported. (The rumors I hear say that that is largely done.) But given that the apps sit on top of the OS, why do you think they need to be ported rather than recompiled?
why would this be any different than the switch to PPC, which required mostly recompiling, with occasional code changes?
Now that we’re talking about porting versus recompiling, let’s take a look at our new Unix capabilities under OS X. Lots of people are spilling out words like “recompiling” and “porting” to get Unix software running on the Mac OS. I tend to think that in most of these cases, “porting” only means making some minimal changes to directory locations. But, or the most part, the same source code supports a whole lot of Unixes, i.e., the source code is self-porting! Well, that’s just silly to say – let’s say the source code is adaptive to the target platform. The only real work that needs to be done is a recompile. This gives us the ability to run, for example, the Gimp on Mac OS X (in Darwin), any number of Linuxes, BSD for Intel -or- PPC, and so on, and so on. All from the same source code!
Granted, it’s taken time to add the support to these source distributions, but we’re not talking about bankrupting amounts of time.
If OS X were designed to have the same libraries on PPC and Intel, it would by definition be MORE COMPATIBLE than all of these different Unix-like operating systems. I should think a “recompile” would be needed to go to Intel from PPC, rather than a “port.”
Ahh… I think I see part of the source of your confusion. First, the operating system only influences part of the total equation.
There are essentially four different kinds of code:
(1) Machine independent
(2) OS dependent
(3) Library dependent
(4) Hardware dependent
Machine independent code is the meat and potatos code, adding numbers, looping, testing conditions, etc… This code generally doesn’t require any porting.
OS dependent code are things like input/output, file system access, memory management, etc… If the OS is supported on both platforms, this does not require (much) porting.
Library dependent code is generally the level where the user interface resides, drawing windows, drawing inside windows, drawing outside windows, performing transformations on various types of platform specific data, etc… Many of these libraries are platform specific and (in some cases) hardware specific so unless there has been some effort to emulate the libraries on both platforms, some porting is often required.
Hardware dependent code, obviously always requires some effort to port. Part of what we think of as part of the OS are the drivers and many of these are hardware specific.
There are development packages that try to mitigate some of this, but it would take too long to go into detail how these work. Essentially they replace some of the OS specific and library specific routines with generic versions that represent the least common denominator of the two platforms. If you’re developing for multiple platforms, this can greatly reduce your development effort. It also greatly reduces your flexibility and your code is typically sub-optimal… but life is all about tradeoffs.
Three reasons (probably others).
(1) Apple supported 68K emulation on the PowerPC to run the old applications without modification (usually).
(2) Apple designed downward compatible libraries so that older code could still be used.
(3) Apple was in full control of the hardware and drivers so that they could buffer the transition to the new platform.
[QUOTE]
*Originally posted by ACoverOfNoise *
excellent points. It’s true that the PPC transition was smoothed by 68k emulation, and the OS X transition was smoothed by blue box. No, I take that back, “smoothed” is too weak a term - more like “made possible by”
In each case, existing binaries could still run. I guess I presume that for a x86 transition, we’d just have to give up on existing binaries. There’s no way I’m suggesting that there would be ppc or 68k emulation for OS X on intel!
I stand by my original point that Apple’s not releasing OS X for Intel has mostly to do with marketing. Technically, I think they could pull it off, and many software vendors would follow.
yes, drivers would need to be ported - just as was done for PPC and is being done for OS X. many hardware vendors would have a headstart in that they already have working drivers for Intel, albeit under a different OS. We disagree on libraries - they mostly call into the OS, so therefore will just need recompiles. perhaps we’re getting into semantics. If it’s calling straight into hardware, I generally consider it OS (which is rumored to be already ported). OS X takes the Hardware Abstraction Layer pretty seriously, precisely to enable moving to another platform.
audient,
Probably just beating a dead horse, but let me try an alternate explanation that may help illustrate my point. If you look at a typical Mac the OS is what loads from disk. It is semi flexible (you may include drivers in your definition or you may not). Examples of this are OS 8.0, OS 9.0, and OS X, etc… However, this does not encapsulate all of the capabilities of the machine. In fact, there are many more routines in the ROM (ToolBox). These are fixed (although they can be overridden or may be semi-soft (see NewWorld comment below)) and the OS and applications depend on these routines. These are not merely hardware specific things, though some may be tied to a PowerPC specific architecture. These include basic underlying graphics primitives, look and feel elements, resource management, and much more. Granted, for newer Macs (with the NewWorld architecture), some of this ROM code is not actually in ROM but in a disk file, but from a software architecture standpoint, it’s virtually the same and not a part of the OS.
So, for applications to merely require a recompile, a set of libraries and a Mac ROM emulation mechanism would have to exist for the new platform. I am not aware of any effort in Apple to rewrite the Mac ROM code for an Intel platform. This would be a huge undertaking with no payback…
well, i’ll try letting the horse rest in peace also : )
(after this one clarification…)
it seems our differences have been whittled down to whether or not the ROM could be ported.
The ROM may not be ‘part of the OS’, but it still goes thru the HAL. the old ROM toobox routines have already been ported from 68k to PPC. I think we both know that the 2nd port of anything is much easier than the 1st. and i claim that the transition to x86 has mostly been solved but not released.
audient,
Yet more clarification…
The abstraction spoken of in your link divorces the Mac ROM from specific Mac hardware. It was not a platform independent abstraction (at least, that was not the design goal).
Your reference was, in fact, the same thing that I was talking about - the ‘NewWorld’ architecture. Here’s a link that talks about it in more detail:
http://developer.apple.com/technotes/tn/tn1167.html
Here’s a couple of quotes that support what I was claiming:
Hope that helps.