Talk:MacOS

Main Image is Terrible

The top / main headshot image is absolutely drab, and not commissioned by Apple as a good consumer or contributed image. Someone has changed the previous beautiful image to a drab one. Could be hackers. — Preceding unsigned comment added by 72.209.223.190 (talk • contribs) 08:29, 14 July 2015‎ (UTC)

absurd

The letter X in OS X's name refers to the number 10, a Roman numeral. It is therefore correctly pronounced "ten" /ˈtɛn/ in this context.[11][29] However, a common mispronunciation is "X" /ˈɛks/.[30]

The first versions of apple GUI used code from X windows Apple had paid for / had authority to use from Xerox. The X is from Xerox Windows / workstations. When you see: "WM_MOVE": that's original Xerox programmer constant.

Microsoft stole some of Apple's modified X code to make Win3.1 and apple DID sue (and lost on that one).

Apple customized and such for Motorola processors and at the advent of closure (when Intel and or ARM became a wise choice), to fix the over-customized problem apple took in part of BSD (or freeBSD - I can't say which for sure).

The first OS/X on the shelf, and I remember the box and place in the store entrace clearly, said right on the back of the box it utilized X-Windows.

Infact it was at a time many companies were releasing DOS alternatives with new GUI - and one major other one utilized X-Windows as well (however, it was not nearly a full GUI like macintosh).

It is true that at one time Apple was using X release 10 - however not necessarily fully or on the first OS/X release. And the back of the box said nothing about which version of X.

Furthermore, most releases of OS/X used the powerPC or intel, and are base on X11 (R6, some from XFreee86, intel based), 11 not 10.

The 10 release Apple used at one time was a proprietary release and modified from the open one to include some proprietary technologies. Postscript dps display (in addition to postscript printing). This made the graphics display "subsystem" wonderful for .ps or Adobe (pdf) work - and it's still a feature many systems fail to show and avoid payments for the patents of.

OS doesn't mean X, and Apple did want everyone to know OS/X was X-Windows based. Never was the version which X much of a question. Infact the proprietary X10 used was not widely used/purchased at all (with some important exceptions).

YET another problem mr, is that you'll confuse people. OS/X 10 doesnt' mean 10 10. Your injecting frustrating formulas into the product logos. MEANING OS/X is not apple os v. 10. — Preceding unsigned comment added by 72.209.223.190 (talk • contribs) 15:49, 14 July 2015‎ (UTC)

The first versions of apple GUI used code from X windows Apple had paid for / had authority to use from Xerox.

No, they didn't. They wrote their own code for the GUI.

The X is from Xerox Windows / workstations.

The X in the X Window System is from "it's the next letter after W", the W Window System being a precursor to the X Window System.

Microsoft stole some of Apple's modified X code to make Win3.1 and apple DID sue (and lost on that one).

No, Microsoft may have made some of the UI visuals similar to Apple's, but there's no evidence that they used any code (given that the Apple GUI code was mostly 68k assembler, it'd require a substantial to make an x86 window system out of it).

Apple customized and such for Motorola processors and at the advent of closure (when Intel and or ARM became a wise choice), to fix the over-customized problem apple took in part of BSD (or freeBSD - I can't say which for sure).

Apple originally wrote the Macintosh software for Motorola 68000 family processors, first the Motorola 68000 and then successors such as the Motorola 68020. They then moved to PowerPC processors.

OS X was a descendant of NeXTSTEP; the original NeXT hardware also used Motorola 68000 family processors (starting with the Motorola 68030). However, the lower layers of NeXTSTEP were based on Mach and BSD, and thus were mostly written in C and thus reasonably portable to other processors. The higher layers were written in Objective-C, and thus also reasonably portable. Apple updated the Mach kernel to a newer version, and got updated BSD code from both FreeBSD and NetBSD.

When Apple bought NeXT, they decided to make the next version of OS X on NeXTSTEP, so the resulting OS was also reasonably portable. They kept it running on some x86-based PCs internally, and eventually switched to x86.

The first OS/X on the shelf, and I remember the box and place in the store entrace clearly, said right on the back of the box it utilized X-Windows.

Your memory is failing you; the box most definitely would not have said any such thing, as it was not based on X11. Apple had, and still has, their own graphics layer, Quartz.

It is true that at one time Apple was using X release 10 - however not necessarily fully or on the first OS/X release.

X11 was released in 1987, three years after the Mac came out. Apple would have used X10 only if they had an X server for the Mac (so that GUI apps UN*X boxes could display on the Mac) in the first few years; however, the X servers for the Mac were third-party products, not products from Apple.

Furthermore, most releases of OS/X used the powerPC or intel, and are base on X11 (R6, some from XFreee86, intel based), 11 not 10.

No release of OS X is based on X11. Some releases of OS X came bundled with an X11 server so that 1) applications using X11-based toolkits could be compiled and on OS X and 2) GUI apps running on other machines on the network can display on the Mac. However, starting with Mountain Lion, they don't bundle X11; instead, they bundle some stub libraries that, when an X11 application running on the Mac starts, a dialog pops up offering to let you download XQuartz from MacOSForge - XQuartz is an Apple project, but it's offered not as a core part of OS X, but as an add-on.

The 10 release Apple used at one time was a proprietary release and modified from the open one to include some proprietary technologies. Postscript dps display (in addition to postscript printing). This made the graphics display "subsystem" wonderful for .ps or Adobe (pdf) work - and it's still a feature many systems fail to show and avoid payments for the patents of.

You're thinking of NeXTSTEP and its PostScript-based display system, not anything from Apple. NeXTSTEP didn't use X11, they did their own graphics layer.

OS doesn't mean X, and Apple did want everyone to know OS/X was X-Windows based.

Given that it wasn't X-based, there's no way Apple would have wanted everyone to think it was.

The "X" comes from the fact that OS X was, nominally, the 10th version of Mac OS, following Mac OS 9; however, that's a bit misleading, given that OS X doesn't take much if any code from any of the preceding versions of the Mac OS. Guy Harris (talk) 23:23, 14 July 2015 (UTC)

The original web pages describing the original tech specs for the original OS X, which would have been consistent with any packaging at the time, are still available and publicly archived (see references). Note that X Windows is not mentioned as a core technology. — Preceding unsigned comment added by 2602:306:C445:1319:8DB3:6C1A:16EB:5167 (talk) 16:34, 4 October 2015 (UTC)

References

Semi-protected edit request on 30 September 2015

Change: OS X 10.11 "El Capitan" was announced on June 8, 2015. Apple's described this release as containing "Refinements to the Mac Experience" and "Improvements to System Performance" rather than new features.

To: OS X 10.11 "El Capitan" was released on September 30, 2015. This release as contains "Refinements to the Mac Experience" and "Improvements to System Performance" rather than new features.

TheRughster (talk) 22:58, 30 September 2015 (UTC)

I fixed the first sentence. I left the second one mainly intact, as it's just quoting Apple, but fixed it to say "Apple described this release as...". Guy Harris (talk) 23:46, 30 September 2015 (UTC)

As to the table about Mac OS X 10.4 and 10.5

The very first 64-bit computing support was introduced with Mac OS X 10.4 for non-graphical console applications, and also in Intel documentations, EM64T was also supported in this version. The very first and last version of Mac OS X supporting 64-bit Graphical Application and 64-bit PowerPC Processor is Mac OS X 10.5. It is the only version exposed all the potential power of PowerMac G5. So these both versions need 64-bit processors to execute 64-bit applications. Then I made the correction to the table below. — Preceding unsigned comment added by 218.27.76.83 (talk • contribs) 17:22, 25 October 2015‎

The table needs to have columns whose interpretation is a bit more obvious - and whose contents are a bit more useful.

Possible columns:

• Processor architectures supported for user-mode code - this would combine PPC/Intel and 32/64-bit, e.g. the early ones would be 32-bit PPC only, Tiger would list 32-bit and 64-bit PPC and 32-bit and 64-bit Intel but with a note indicating that only non-GUI 64-bit programs are supported, Leopard would list those four without the note, Snow Leopard would list 32-bit PPC with a note indicate that it requires Rosetta and would list both 32-bit and 64-bit Intel, all subsequent versions would list only 32-bit and 64-bit Intel.

• Processor architectures supported for the kernel - this would be similar, with the early ones being 32-bit PPC only, Tiger and Leopard being 32-bit PPC and Intel, Snow Leopard being 32-bit and 64-bit Intel, and Lion and beyond only listing 64-bit Intel. That column also indicates what hardware is supported.

I suppose one could split Tiger into the pre-10.4.4 PPC-only version, the versions that supported PPC and 32-bit Intel, and the versions that also supported 64-bit Intel (I forget whether 10.4.0 supported 64-bit PPC or whether that was introduced later, possibly at the same time as 64-bit Intel, but I do remember 64-bit Intel support not being available in the first version supporting Intel). Guy Harris (talk) 01:35, 26 October 2015 (UTC)

I've eventually re-arranged the table shown below. The coloured units would help readers figure out the transitional products, but there is something I should mention below,

• PowerPC is a 32-bit stripped version of 64-bit POWER architecture, which also eventually evolved into PowerPC architecture, so PPC32 and PPC64 is the same architecture but different versions. Mac OS X 10.3 utilises the PPC64 feature to address physical memory above 4GB within kernel only, while Mac OS X 10.4 even further provides 64-bit computing support for non-graphical applications. They both had the trend to transit from 32-bit to 64-bit. But eventually for reasons, this failure transition were replaced by another transition from IA-32 to Intel 64. So I do not change the colour of unit which content is PPC32, PPC64.
• It is considered that Intel 64 is the superset of IA-32, but as to Mac OS X 10.7, it still retains the 32-bit hybrid kernel, mostly running under IA-32 legacy mode. So I change the colour of unit, which content is IA-32, Intel 64. Since OS X 10.8, the kernel is running purely under 64-bit mode, so there is no more situation for kernel and applications running under IA-32 legacy mode. Intel 64 is the ideal word to state this situation.
• Few documents detail the information on the 64-bit architecture of Intel processor and Mac OS X 10.4.x, so I leave it to the pure 32-bit O/S alone, waiting for some time later to make revision.
• Last but not least, I should have to say that the column of the original table should not be changed. Because the Processor Support, Processor Architecture and Kernel Mode reflect three most important factors of Apple's transition from AIM alliance's PowerPC to Intel x86. And what's more, in the OS X products, kernel-land and user-land codes are not that clear as traditional O/S. The Pink coloured Column Processor Architecture also provide information on the architectures sealed into universal binaries of Mac OS X. As a side, Mac OS X 10.4.1 is the first product support IA-32 architecture, only provided for developers. About ten years ago, I remembered, it was rumored that those special developers would obtain Pentium D based PowerMac-like machine to develop their software for then-future Intel Mac.

--- IP user who edited the following table — Preceding unsigned comment added by 218.27.76.83 (talk) 09:45, 26 October 2015 (UTC)

"PowerPC is a 32-bit stripped version of 64-bit POWER architecture, which also eventually evolved into PowerPC architecture, so PPC32 and PPC64 is the same architecture but different versions." The original POWER (Peformance Optimized With Enhanced RISC - Yet Another Lame Backronym) instruction set architecture was 32-bit; see IBM RISC System/6000 processor architecture (behind a paywall, alas), which speaks of the fixed-point unit as having 32-bit registers. PowerPC took that, added 64-bit capabilities, removed some instructions, added some instructions, and changed the specifications of some instructions; see Appendix E of PowerPC User Instruction Set Architecture Book I Version 2.02.

PPC v2.02 also says that

Processors provide two execution environments, 32-bit and 64-bit. In both of these environments (modes), instructions that set a 64-bit register affect all 64 bits, and the value placed into the register is independent of mode.

According to [http://www.iman1.jo/iman1/images/IMAN1-User-Site-Files/Architecure/PPC_Vers202_Book3_public.pdf PowerPC Operating Environment Architecture Book III

Version 2.02], section 2.2.3 "Machine State Register", the high-order bit of the Machine State Register controls whether the processor is in 32-bit mode or 64-bit mode.

So PPC32 is what you have when that bit is clear, and PPC64 is what you have when that bit is set. And, yes, the processor behaves differently, in some respects, in 32-bit mode and in 64-bit mode. (And there are processors that don't support PPC64, just PPC32.) There are fewer differences between PPC32 and PPC64 than there are between IA-32 and x86-64, but there are differences, so I don't see a reason to treat PPC32/PPC64 differently from IA-32/x86-64 in the table.

"while Mac OS X 10.4 even further provides 64-bit computing support for non-graphical applications. They both had the trend to transit from 32-bit to 64-bit. But eventually for reasons, this failure transition were replaced by another transition from IA-32 to Intel 64." I'm not sure what you mean by "failure transition", but in 10.5 full support was added for 64-bit user mode, both for PPC and x86, so the transition didn't fail to make 64-bit GUI applications possible for PPC. What was replaced wasn't the transition, what was replaced was that PPC was replaced by x86.

"It is considered that Intel 64 is the superset of IA-32, but as to Mac OS X 10.7, it still retains the 32-bit hybrid kernel, mostly running under IA-32 legacy mode." There's no "but" involved there; yes, in 10.5, and on some systems in 10.6 and 10.7, the kernel continued to run 32-bit (to make kernel data structures containing pointers smaller, and to allow 32-bit-only kexts to continue to run), but 64-bit user-mode code was fully supported. Except in cases where the kernel wasn't doing the work it needed to do to properly support all four combinations of kernel bit-width and userland bit-width (10.5 didn't properly handle BPF filters from 64-bit user-mode code, and 10.6 didn't properly handle BPF timeouts from 64-bit user-mode code), user-mode code didn't need to be aware of the bit-width of the kernel.

"Since OS X 10.8, the kernel is running purely under 64-bit mode, so there is no more situation for kernel and applications running under IA-32 legacy mode." In 10.8 and later, the kernel runs only in 64-bit mode, but applications can still run in IA-32 mode:

$ sw_vers
ProductName:    Mac OS X
ProductVersion: 10.10.5
BuildVersion:   14F27
$ xcodebuild -version
Xcode 7.0.1
Build version 7A1001
$ cat foo.c
#include <stdio.h>

int
main(void)
{
        printf("Pointer size is %zu bits\n", 8*sizeof(char *));
        return 0;
}
$ gcc -arch i386 foo.c
$ ./a.out
Pointer size is 32 bits
$ gcc foo.c
$ ./a.out
Pointer size is 64 bits

"Last but not least, I should have to say that the column of the original table should not be changed. Because the Processor Support, Processor Architecture and Kernel Mode reflect three most important factors of Apple's transition from AIM alliance's PowerPC to Intel x86." There are three transitions, not one. There's the transition from supporting only 32-bit user-mode code to supporting 32-bit and 64-bit user-mode code (with an intermediate step, in 10.4, to providing a 64-bit libSystem but not other libraries), there's the transition from using PPC processors to using x86 processors (and, for a while, continuing to support PPC-based Mac with new versions of OS X, as well as continuing to support PPC applications on x86 with Rosetta), and there's the transition from only 32-bit kernels to supporting 64-bit kernels (first with support for both, and then without 32-bit kernel support).

So, for a given version of OS X, there's:

• Which types of instruction set (PowerPC, x86, or both) can it run on - 10.0 through 10.5 run on PPC, 10.4 and up run on x86;
• Which types of instruction set (PowerPC, x86, or both) can it support for application code - 10.0 through 10.6 support PPC, 10.4 and up support x86;
• Which bit-widths (32-bit, 64-bit, or both) can it run on - 10.0 through 10.3 run on 32-bit processors, 10.4 and up run on 64-bit processors, 10.8 and later run only on 64-bit processors;
• Which bit-widths (32-bit only or 32-bit and 64-bit) can it support for application code - 10.0 through 10.3 support 32-bit only, 10.4 also supports 64-bit command-line code, 10.5 and up support both 32-bit and 64-bit;

so the question is how to represent all four of those.

"About ten years ago, I remembered, it was rumored that those special developers would obtain Pentium D based PowerMac-like machine to develop their software for then-future Intel Mac." Those were called the "Developer Transition Kit". https://www.apple.com/pr/library/2005/06/06Apple-to-Use-Intel-Microprocessors-Beginning-in-2006.html Not a rumor]. Pentium D-based, in a PowerMac-style case. Guy Harris (talk) 19:56, 27 October 2015 (UTC)

OK, I change the colour of the unit which content is PPC32, PPC64, they both are transitional products. As to Mac OS X 10.7, the codes have also the chance to run under IA-32 legacy mode found on Intel 64 and IA-32 processors; since OS X 10.8, all the codes (32-bit and 64-bit) have only chance to run under IA-32e mode found on Intel 64 processors. So Mac OS X 10.7 is the last stop for this very transition. Transitional product does really mean that it is on the half way, not fully prepared for migration, maybe for some system routines, maybe for some standards. Unfortunately, Apple never realises the fully support for PPC64 architecture, even on Mac OS X 10.5, not all the system routines had been fully migrated to PPC64. When Mac OS X 10.5 was about official releasing, in mid-2007, there were seldom PowerPC based products on sale in Apple Shops. So the support for PPC32 and PPC64 had already become legacy for Mac OS X 10.5, no new Apple hardware would benefit from PPC based codes. XNU is a product heavily based on Mach kernel. Parts of traditional UNIX kernel in Mach would find convenient ways to be implemented in user-space, and maybe many versions would also be provided and configured onto the same O/S. Running 64-bit applications on the mixed 32-bit kernel of Mac OS X might be similar with it in running some IA-32 applications on Windows 3.x through Win32s API. But the real situation might be even complicated and irrelevant. From Mac OS X 10.3 to Mac OS X 10.7, all of them are on the way of computing transition from 32-bit (PPC32, IA-32) eventually to real 64-bit (Intel 64, most 32-bit IA-32 programmes are also supported within compatibility mode of Intel 64). The transitions of chip products and manufactures shocked the entire IT world, but are meaningless to the end-users.

--IP User who edited the following table — Preceding unsigned comment added by 119.51.184.70 (talk • contribs) 23:06, 27 October 2015‎

"OK, I change the colour of the unit which content is PPC32, PPC64, they both are transitional products" PPC wasn't a "transitional product"; it's not as if Apple intended to go to x86 from the beginning. They did x86 builds, to make sure the code continued to be able to run on x86 if they chose to switch to it, but that's not an indication that they intended to switch.

"As to Mac OS X 10.7, the codes have also the chance to run under IA-32 legacy mode found on Intel 64 and IA-32 processors; since OS X 10.8, all the codes (32-bit and 64-bit) have only chance to run under IA-32e mode found on Intel 64 processors. So Mac OS X 10.7 is the last stop for this very transition.". I don't remember the details from the talk given inside Apple on the 32-bit kernel/64-bit userland hackery, so I don't remember whether the 32-bit kernel ran in legacy mode or in long mode and compatibility submode; I suppose I could go dig through the XNU source to see which it was. If the former, 32-bit user-mode code might have run in legacy mode as well; if the latter, it probably ran in long mode and compatibility submode. Obviously 64-bit user-mode code runs in long mode and 64-bit submode. However, 32-bit code doesn't care whether it's running in legacy mode or long mode and compatibility submode; that's what "compatibility" means. So there's nothing interesting, from the point of view of 32-bit user-mode code, about the transition between 32-bit and 64-bit kernels. There's nothing interesting from the point of view of 64-bit user-mode code, either, as it runs in long mode and 64-bit submode on both kernels.

"Transitional product does really mean that it is on the half way, not fully prepared for migration, maybe for some system routines, maybe for some standards." Then the only "transitional" product was 10.4, which had limited support for 64-bit user-mode code.

"Unfortunately, Apple never realises the fully support for PPC64 architecture, even on Mac OS X 10.5, not all the system routines had been fully migrated to PPC64." Really? Which ones hadn't been migrated? They'd have to be assembler-language routines, or routines inside a platform-specific #ifdef, as C/C++/Objective-C-language routines would be 64-bit on both x86 and PPC. I doubt that claim is true.

"XNU is a product heavily based on Mach kernel. Parts of traditional UNIX kernel in Mach would find convenient ways to be implemented in user-space,, and maybe many versions would also be provided and configured onto the same O/S" Yes, in theory, that could be done. However, Apple never actually did that; that's why XNU is called a "hybrid kernel" - there's very little about it that's microkernelish.

"Running 64-bit applications on the mixed 32-bit kernel of Mac OS X might be similar with it in running some IA-32 applications on Windows 3.x through Win32s API." No, not similar. In user mode, the libraries were compiled "fat", containing PPC32, PPC64, IA-32, and x86-64 code. If the library makes a system call trap, the processor switches to 32-bit mode if it's a 32-bit kernel and 64-bit library or to 64-bit mode if it's a 64-bit kernel and 32-bit library as part of the system call trap process. The kernel code, when fetching stuff from userland or copying stuff to userland, checks whether the user-mode code is 32-bit or 64-bit, and translates between the userland format of the data structures and the format used in the kernel.

"From Mac OS X 10.3 to Mac OS X 10.7, all of them are on the way of computing transition from 32-bit (PPC32, IA-32) eventually to real 64-bit (Intel 64, most 32-bit IA-32 programmes are also supported within compatibility mode of Intel 64)." No, there were three transitions, one from PPC to x86, one from 32-bit-only to 32-bit-and-64-bit application and library support, and one from 32-bit kernels to 64-bit kernels. Guy Harris (talk) 21:08, 28 October 2015 (UTC)

I could go dig through the XNU source to see which it was

Excellent! But I am afraid that those critical codes might not be disclosed for open source. Anyway I wish that would help to improve the following table.

--IP User who edited the following table — Preceding unsigned comment added by 119.51.184.70 (talk • contribs) 16:11, 28 October 2015‎

Long mode and compatibility submode. See, for example, L_enter_lohandler2 in the 10.5.8 x86 idt64.s, which is for x86-64 machines (idt.s is for IA-32 machines). So it looks as if x86-64 machines with a 32-bit kernel run most of the kernel, and 32-bit user-mode code, in long mode and compatibility submode, and run 64-bit user-mode code in long mode and 64-bit submode. Guy Harris (talk) 00:02, 29 October 2015 (UTC)

Well, this is a good presumption. In this situation, it provides two complete suites of 32-bit kernel routines, one, purely 32-bit codes, running under legacy IA-32 mode for IA-32 processors; the other, mixed 32-bit codes, running under 64-bit Mode and Compatibility Mode for Intel 64 processors. For the latter, all the 32-bit kernel extensions and device drivers are running within Compatibility Mode too. This could be an efficient method, but problems arise. 32-bit codes in the Compatibility Mode does not have the privileges to finish jobs such as arrangement for paging, then those jobs must be mixed with 64-bit codes: first those paging algorithms are implemented with 32-bit codes, and then 64-bit codes assigns the products generated from 32-bit codes through paging unit; or everything is done using 64-bit codes. For the 32-bit interrupt handlers, 64-bit interrupt routines would trace back to the 32-bit routines in Compatibility Mode.

So there is another presumption: the kernel just provides only one complete suite of kernel routines, but some of which have two versions. In this presumption, 64-bit computing is treated like an extension, and all the kernel extensions and device drivers are running under legacy IA-32 mode for both IA-32 and Intel 64 processors. Only when 64-bit application is about to executing, the application loader creates a temporary 64-bit operating environment, prepares all the necessary things for it to run with 32-bit codes. The 64-bit interrupt handler part is the necessary component prepared for each interrupt from hardware and software, and traps the processor back to its legacy IA-32 mode, where the 32-bit processing routines do the real jobs. This is not likely an efficient method from the viewpoint of long journey transition of operating modes, but a bit more possible than the first presumption. And what's more, when Mac OS X 10.5 was about debuting, there were still many Macintosh computers based on pure 32-bit Intel processors, few applications were even Intel-bitlised, Office:mac 2004 was then the only productivity software running within the environment provided by Rosette Emulator.

--IP user who edited the following table — Preceding unsigned comment added by 175.17.63.241 (talk • contribs) 18:26, 28 October 2015‎

"In this situation, it provides two complete suites of 32-bit kernel routines, one, purely 32-bit codes, running under legacy IA-32 mode for IA-32 processors; the other, mixed 32-bit codes, running under 64-bit Mode and Compatibility Mode for Intel 64 processors." No, that's not what Apple did, so there is no point in discussing that any further.

"the kernel just provides only one complete suite of kernel routines, but some of which have two versions." That is what Apple did. The low-level code, and possibly the pmap code that handles the MMU, are examples of routines with two versions.

"all the kernel extensions and device drivers are running under legacy IA-32 mode for both IA-32 and Intel 64 processors." No, they run in legacy mode on IA-32 processors, and run in long mode and compatibility submode with x86-64 processors.

"Only when 64-bit application is about to executing, the application loader creates a temporary 64-bit operating environment, prepares all the necessary things for it to run with 32-bit codes." It's not temporary, it lives as long as the 64-bit process exists. The user-mode code runs with 64-bit code, obviously, as it's a 64-bit application.

And none of this is a "presumption", it's a description of what OS X actually does with a 32-bit kernel on x86-64. (On PowerPC, the kernel was 32-bit, with 32-bit pointers and 32-bit longs, but didn't have to go through quite as much pain to run 64-bit user-mode code.) Guy Harris (talk) 01:41, 29 October 2015 (UTC)

Too sure to be doubtful. As to the 32-bit kernel, 32-bit codes and compatibility mode, enough source is needed to prove its reality. This compatibility sub-mode of IA-32e mode is only actually utilised by 64-bit kernel for 32-bit applications (user-land).

--IP user who edited the following table 175.17.63.241 (talk) 02:03, 29 October 2015 (UTC)

That's right, I'm too sure to be doubtful about any of what I've said. (I was there when they did it, and saw the talk they gave inside Apple about it.) You want a source to prove what I said, here's a source, which is not only a source, it's the source (code to OS X). And what it says is that compatibility submode is used by the 32-bit OS X kernel as the mode in which it runs the vast majority of kernel code, as well as by both the 32-bit and 64-bit kernels to run 32-bit user-mode applications. Most OSes for x86 didn't do that, but OS X did, in order to preserve binary compatibility for kexts until the kext developers could make their kexts 32-bit/64-bit universal, and in order to reduce memory requirements for kernel data structures (32-bit pointers rather than 64-bit pointers). Guy Harris (talk) 03:47, 29 October 2015 (UTC)

Astonishing! That is to say there is nothing running under legacy mode of Intel 64 processor, even if the 32-bit kernel is running under IA-32e mode, especially Compatibility sub-mode. So I changed the colour and content of the corresponding unit. Or in other words, the 32-bit kernel within Mac OS X 10.7 is different from it in Mac OS X 10.5 and 10.6, it lacks the codebase residing on legacy mode.

The IP user who edited the following table 175.17.63.241 (talk) 06:04, 29 October 2015 (UTC)

"Astonishing!" Yes, the people who gave the talk at Apple said the Intel people were pretty astonished when they were told how the 32-bit kernel ran 64-bit user-mode code....

"That is to say there is nothing running under legacy mode of Intel 64 processor" Correct.

"Or in other words, the 32-bit kernel within Mac OS X 10.7 is different from it in Mac OS X 10.5 and 10.6, it lacks the codebase residing on legacy mode." The 32-bit x86 kernel in 10.4, the 32-bit x86 kernel in 10.5, the 32-bit kernel in 10.6 (there's no PPC kernel in 10.6), and the 32-bit kernel in 10.7 all run in long mode and compatibility submode on x86-64 processors. The 32-bit x86 kernel in 10.4, 10.5, and 10.6 run in legacy mode on IA-32 processors, because long mode isn't available; the 32-bit x86 kernel in 10.7 doesn't support IA-32 processors, and doesn't need to run in legacy mode (unless the machine has to pass through legacy mode during the startup process before going into long mode). It does, however, still have idt.s, so I'm not sure whether the support for IA-32 processors, and thus for running in legacy mode, was completely removed or whether that's still needed on x86-64 processors. Guy Harris (talk) 07:09, 29 October 2015 (UTC)

Well, if AMD had made another kind of AMD64 rather than today's version, it hybrids the PPC32 with 64-bit ISA of AMD64 without supporting IA-32 at all, it might challenge the transition from PowerPC towards Intel. If it were so, then Mac OS X would have transited from PPC64 to 64-bit ISA of x86-64 directly, without needing another kind of 32-bit computing. So I won't believe that was really astonishment towards Intel, rather than it, it is a surprise or gift from Apple to Intel. But that's all the past! This time I added information on the firmware support, that might help explain why 64-bit processor could not enable 64-bit kernel for some versions of Mac OS X, and the problem on the 3GB Barrier.

-- IP user who edited the following table 175.17.63.241 (talk) 00:57, 30 October 2015 (UTC)

OK, so:

• The row for Tiger should have two sub-rows, one for the PPC-only 10.4.0, with support only for Open Firmware, PowerPC, and PPC32/PPC64, with a note that PPC64 support is command-line only, and with a 32-bit kernel, and one for 10.4.1 and later, with support for both OpenFirmware and EFI32, both PowerPC and Intel, and PPC32/PPC64/IA-32/x86-64, and a 32-bit kernel, with a note that PPC64 support *and* x86-64 support is command-line only.

• The "Processor Architecture" column is not consistent. For Snow Leopard, it lists IA-32, Intel 64, and PPC32, which are the instruction set architectures it supports for application binaries, with PPC32 supported through Rosetta. For Lion, however, it lists only Intel 64, which is the instruction set architecture it supports for the processor it runs on; for application binaries, it supports both Intel 64 and IA-32. Please choose whether that column indicates the instruction sets for the processors on which the OS can run or the instruction sets for which it supports application binaries. Guy Harris (talk) 02:54, 30 October 2015 (UTC)

It is considered that Intel 64 is the superset of IA-32, so I use it to express the architecture, both 32-bit and 64-bit, supported by Mac OS X 10.7. I use IA-32 to denote the 32-bit only Intel processor and architecture, which Mac OS X 10.7 does not support. I also added information on Mac OS X Server 10.4.7 universal.

-- IP User who edited the following table 139.210.137.43 (talk) 04:32, 30 October 2015 (UTC)

You have not addressed the inconsistency in the "Processor Architecture" column.

If it lists the instruction set architectures that are supported for applications, then either Snow Leopard should list only Intel 64 and PPC32 if "Intel 64" includes IA-32, or all the ones after Snow Leopard should list IA-32 as well as Intel 64 as they support both 32-bit and 64-bit x86 applications.

If it lists the instruction set architectures on which the OS can actually run, then Snow Leopard should not list PPC32, as it will not run on PPC Macs, only Intel Macs. Guy Harris (talk) 08:38, 30 October 2015 (UTC)

In Intel Itanium document, it says, "IA-32 Architecture – The 32-bit and 16-bit Intel architecture as described in the Intel® 64 and IA-32 Architectures Software Developer’s Manual." So the architecture and Instruction Set sealed in compatibility sub-mode of IA-32e mode are not strictly equal to the IA-32. So I added two comments without changing the relate units of the following table.

"and with a 32-bit kernel, and one for 10.4.1 and later, with support for both OpenFirmware and EFI32, both PowerPC and Intel, and PPC32/PPC64/IA-32/x86-64, and a 32-bit kernel, with a note that PPC64 support *and* x86-64 support is command-line only.", I found that Mac OS X 10.4 Intel installation media seems almost another universal release. But I have no ideas if someone used it to install on PowerPC Mac. At least, I found no information about it on Apple website. So I would not change it this time. But through the 10.4.6, 10.4.7 and 10.4.8 delta updates for Intel, I found Intel 64 support information on 10.4.8, so I change the related table units.

-- IP user who edited the following table

You still have not addressed the inconsistency in the "Processor Architecture" column.

If it lists the instruction set architectures for which applications will work on the OS, then if you're going to treat "Intel 64" as including both 64-bit and 32-bit IA-32 code, then Leopard and Snow Leopard should just list "Intel 64", as they support both 64-bit and 32-bit x86 applications. Tiger, however, would have to list them separately, so that it can indicate that is supports GUI IA-32 applications but only command-line Intel 64 applications.

If it lists the instruction set architectures for processors on which the OS will run, then Snow Leopard should not list PPC32, as Snow Leopard only runs on Intel Macs, even though it can run PPC32 applications through Rosetta.

As for the Intel manual quote, all it means is that the "Intel® 64 and IA-32 Architectures Software Developer’s Manual" describes, as the title itself makes obvious, both the Intel 64 and IA-32 versions of the architecture; Intel 64 is a superset of IA-32, in that an Intel 64 processor supports all the processor modes IA-32 does (real, 16-bit protected, and 32-bit protected), and also supports long mode.

Long mode in compatibility sub-mode isn't 100% compatible with legacy mode 32-bit protected sub-mode; as section 3.1.1 "Intel® 64 Architecture" of volume 1 of the Intel® 64 and IA-32 Architectures Software Developer’s Manual says:

Legacy applications that run in Virtual 8086 mode or use hardware task management will not work in this mode.

As far as I know, few if any OS X apps used either of those capabilities, however, so they should all work on OS X on Intel 64 processors. Guy Harris (talk) 02:49, 31 October 2015 (UTC)

Well, Mac OS X or OS X is something different from UNIT-like O/S, it is not written for some a specific architecture, but for some a specific computer system. So the Processor Architectures mentioned here is mostly the touchable things, in other words, they should be supported by the system kernel and/or user-land routines. They might present on the real processor, or emulated by ISA emulator. So from this very viewpoint, the PPC64 on Mac OS X 10.3 is not touchable for userland applications. Even if application programmers could have writen some applications using the 64-bit GPRS of PPC64, but the kernel itself does only maintain the shrunk 32-bit values. It would incur problems when those processes swap in and out. And in fact, the situation of PPC64 in Mac OS X 10.3 is similar with 386 enhanced mode in Windows 3.1x. Windows 3.1x is designed for 80286 based system, but borrows some functions from 80386 processor to support even more physical memory than 16MB. Back to the situation of PPC64 and Mac OS X 10.3, the kernel just borrows some functions from PPC64 processor, rather than really support the PPC64 architecture. So I did not list it in the following table. As to the Mac OS X 10.4, not only the libSystem but also the kernel itself knows how to manipulate 64-bit codes, the situation changed. Early version of 10.4 Intel does not support Intel 64 at all, no matter IA-32 processor or Intel64 one are treated as the IA-32 one. So it support the real IA-32 architecture. After universal server edition released, both updates merged together, so Mac OS X 10.4 Intel had the 64-bit capabilities, EFI64, x86-64 version of libSystem and mach kernel itself happened to change. This time Intel 64 processor is running under compatibility mode mostly rather than treated as another IA-32 processor. So I list Intel 64 to that table unit. There are large differences between Mac OS X 10.6 and 10.7, and the most obvious one is that in the latter one, there is no support of 32-bit IA-32 processor. So there is no processor in Mac OS X 10.7 treated as IA-32 processor, so that architecture could really be taken over by Intel 64. Or in other words, the backward-support could clearly describe that how touchable it is for the support of applications written for IA-32 architecture.

-- IP user who edited the following table

What on earth is a "UNIT-like OS"? I have never heard that term.

If you mean "Unix-like OS", then most Unix-like systems, these days, are not written for some specific architecture - Solaris runs on SPARC and x86, HP-UX runs on PA-RISC and IA-64, Linux runs on a lot of different instruction set architectures, and most *BSDs run on at least two instruction set architectures, so that's clearly not what you meant.

"So the Processor Architectures mentioned here is mostly the touchable things, in other words, they should be supported by the system kernel and/or user-land routines. They might present on the real processor, or emulated by ISA emulator." Then it's the instruction set architectures for which applications will work on the OS. In that case, if you're going to draw a distinction between the IA-32 instruction set architecture and the instruction set architecture in compatibility sub-mode of long mode (the differences being the lack of virtual 8086 mode and support for hardware task management, as per the Intel manual), it would be far clearer if "Intel 64" were stated as "Intel 64 long mode and compatibility sub-mode", although, from a practical point of view, for most if not all OS X applications, there is no difference between IA-32 in 32-bit protected sub-mode and Intel 64 in long mode and compatibility sub-mode.

"There are large differences between Mac OS X 10.6 and 10.7, and the most obvious one is that in the latter one, there is no support of 32-bit IA-32 processor." That "large difference" mainly consists of the removal of support for IA-32 processors from the kernel. However..

"Or in other words, the backward-support could clearly describe that how touchable it is for the support of applications written for IA-32 architecture." ...there is absolutely no difference between 10.6 and 10.7 in support for applications built for IA-32 architecture, other than support for virtual 8086 mode (which I'm not sure OS X supports at all) and hardware task management (which OS X might also not support). Guy Harris (talk) 07:15, 31 October 2015 (UTC)

I typed something wrong, it is UNIX-like, not UNIT-like. Well, OK. As to Intel 64 processor, the legacy IA-32 architecture are not compatible with 64-bit architecture. But the 64-bit architecture of Intel 64 processor, Intel 64 architecture, is backward compatible with most programmes written for IA-32 architecture. This is difference between the relationship of PPC32 and PPC64. PPC32 is the scale-down version of PPC64, so PPC32 is upward compatible with PPC64, and PPC64 is backward-compatible with PPC32.

--IP user who edited the following table

"the legacy IA-32 architecture are not compatible with 64-bit architecture" only in the senses that 1) code that runs in long mode, 64-bit submode won't run on an IA-32 processor and 2) code that uses virtual 8086 mode or hardware task management won't run in long mode, compatibility submode. Code that runs on an IA-32 processor will run on an Intel 64 processor running in legacy mode, and almost all user-mode code that runs on an IA-32 processor (and even, as per the 32-bit OS X kernel, even most kernel-mode code that runs on an IA-32 processor, if the right stuff is done in the lower layers of the kernel) will run on an Intel 64 processor running in long mode, compatibility submode. That's rather a lot of compatibility, and that compatibility is probably a reason why x86-64 succeeded in the marketplace.

"PPC32 is upward compatible with PPC64" in the sense that user-mode PPC32 code will work on a PPC64 processor (if the OS cooperates, but that's true of any 32-bit architecture extended to 64 bits). "PPC64 is backward-compatible with PPC32" in the sense that user-mode PPC32 code will work on a PPC64 processor (if the OS cooperates, but that's true of any 32-bit architecture extended to 64 bits). Obviously, PPC64 code will not run on a PPC32-only processor.

And before you talk about otherwise 32-bit code on a PPC64 processor being able to use all 64 bits of the GPRs, please read about the x32 ABI.

So what is the big difference here between x86 and PPC in that regard? Guy Harris (talk) 09:03, 31 October 2015 (UTC)

Compatibility Mode, where the 32-bit kernel and 32-bit applications work, is part of Intel 64 architecture, but not part of IA-32. So Intel 64 is exactly the Processor Architecture of Mac OS X 10.7. Saying Intel 64 architecture implies most programmes written for IA-32 architecture are compatible with this architecture. In Mac OS X 10.6, the 32-bit kernel and 32-bit applications work under protected mode of IA-32 architecture for 32-bit Intel processor; the 32-bit kernel and 32/64-bit applications work under IA-32e mode of Intel 64 architecture for 64-bit Intel processor; the 32-bit PowerPC applications work under Rosetta emulator, which is part of Macintosh system. So for the Mac OS X 10.6, the Processor Architecture is IA-32, Intel 64 or PPC32. IA-32 and Intel 64 present on the real processors, while PPC32 present on the virtual processor (emulator). PPC32 is a scale-down version of PPC64, or in other words, PPC64 is scaled up from PPC32. But the compatibility mode (backward-compatible IA-32 architecture) is alongside with 64-bit mode (64-bit architecture). So in Mac OS X 10.3, the 64-bit PowerPC is used as a scaled-down version, the Processor Architecture is essentially PPC32; while in Mac OS X 10.7, Intel 64 is the best choice. That's the big difference.

Because the 32-bit kernel of Mac OS X 10.7 could run 64-bit applications, so the 32-bit applications has the potential possibilities to hybrid part of itself with 64-bit codes. Then this hybrid 32-bit applications could not run on IA-32 architecture. That is some better reason that I give to use Intel 64. I also added (32-bit, 64-bit) below it, and I wish this would help make it clear.

--IP user who edited the following table — Preceding unsigned comment added by 139.210.137.43 (talk) 13:03, 31 October 2015 (UTC)

Then, to be consistent, you should say "Intel 64 (32-bit, 64-bit)" for 10.5, and 10.6, as well as 10.7, to clarify that all of them support both 32-bit and 64-bit applications. For 10.4, you should say "Intel 64 (32-bit, 64-bit CLI only)" to clarify that it support all 32-bit applications, and supports only 64-bit CLI applications.

In addition, for 10.4, you should say "PPC32, PPC64 (CLI only)" to indicate that only 64-bit CLI applications are supported.

"Because the 32-bit kernel of Mac OS X 10.7 could run 64-bit applications" That's also true of the 32-bit kernel of 10.4, 10.5 and 10.6.

"so the 32-bit applications has the potential possibilities to hybrid part of itself with 64-bit codes" No, OS X doesn't support anything like x32, so you can't have a 32-bit application with some 64-bit code in it for Intel 64. That's true of 10.4, 10.5, 10.6, 10.7, 10.8, 10.9, 10.10, and 10.11. Guy Harris (talk) 15:05, 31 October 2015 (UTC)

That's right! If you think some a time is ok, you are welcome to represent the following table onto the main article. Any modification is also welcome to it. Thank you.

I've changed the table and added the relative information. As to the firmware, especially EFI. I have to say that EFI32 is not bootia32.efi, and EFI64 is not bootx64.efi. Later information on EFI specification might possibly to add into the table.

I've also added the information on Intel Rhapsody, that might be the important reason why Apple named their Mac OS X 10.7 as Mac OS X (for it still retains the 32-bit kernel), but removed the cap (Mac) from OS X 10.8 and later versions. Not only the NeXT, but also the Apple in mid 1990s developed a hybrid computer, dual systems. dual processors, dual architectures. That machine could also run Windows 95 alongside with Mac OS. Fantastic! From all those things, the transition to Intel was the expectation long-long before PowerPC970 was improper for mobile computing.

I did not want to make any change, but eventually I changed the information on Mac OS X 10.7. Even though the 32-bit kernel and 32-bit applications are backward supported within compatibility sub-mode of IA-32e. But just like PPC32 was emulated by Rosetta as part of Macintosh system, this IA-32 architecture, or i386 (output of uname -a within Mac OS X 10.7), is realised on a new architecture of a new processor, Intel 64. For keeping the consistency with the name Mac OS X, I think the change that I made is valuable. As to the OS X 10.8 and later versions, the Processor Architecture is exactly the Intel 64, but most programmes written for IA-32 architecture could also run on those new systems, so Intel 64 (32-bit, 64-bit) could make it clear.

--IP user who edited the following table 119.51.186.57 (talk) 02:59, 1 November 2015 (UTC)

"From all those things, the transition to Intel was the expectation long-long before PowerPC970 was improper for mobile computing." You're just guessing there. There's a difference between being prepared to switch to Intel if it became necessary (which Apple definitely were prepared to do with Mac OS X, as they did builds for PCs internally, to make sure the x86 support didn't suffer from bit-rot) and expecting to switch to Intel.

There is no difference between the x86 application support on 10.5, 10.6, 10.7, 10.8, 10.9, 10.10, and 10.11 on Intel 64 processors. All of them support both 32-bit applications in compatibility mode and 64-bit applications in long mode. Therefore, all of them should say, in whatever column indicates what application instruction sets are supported, "Intel 64 (32-bit, 64-bit)".

"But just like PPC32 was emulated by Rosetta as part of Macintosh system, this IA-32 architecture, or i386 (output of uname -a within Mac OS X 10.7), is realised on a new architecture of a new processor, Intel 64." There's nothing "like" about them. PPC is emulated on IA-32 and Intel 64 with Rosetta software. 32-bit and x86 code is executed in hardware on Intel 64 processors. And if you're going to say "this IA-32 architecture, or i386 (output of uname -a within Mac OS X 10.7), is realised on a new architecture of a new processor, Intel 64.", then you should simply say "IA-32" and "Intel 64" in the column that indicates what application instruction sets are supported.

As for uname -a, that's just uname -mnrsv, as the man page says. uname -m prints "the machine hardware name", whatever that is supposed to mean; uname -p prints "the machine processor architecture name", whatever that is supposed to mean.

Mac OS X 10.7, when running on an Intel 64 machine, prints, for uname -m, "x86_64", and prints, for uname -p, "i386".

OS X 10.10 does the exact same thing, as do OS X 10.8, OS X 10.9, OS X 10.11. 10.6 prints "i386" for both. But don't read too much into any of that; you just get into trouble if you try to guess, based on how you think, what other people thought when they did something. Guy Harris (talk) 07:10, 1 November 2015 (UTC)

The IA-32 in sentence "most programmes written for IA-32 architecture could also run on those new systems." is different from it in "this IA-32 architecture, or i386 (output of uname -a within Mac OS X 10.7), is realised on a new architecture of a new processor, Intel 64." Because for the latter, developers of Mac OS X also made efforts to enable 32-bit kernel extensions and 32-bit device drivers work without problem, making the end-users operate as if they were really working on the IA-32 architecture. All those efforts, in other words, were put to realise the upward compatibilities from IA-32 to 64-bit architecture (Intel 64) and fill in the gaps between them from software programming standpoint. That is the astonishment you mentioned before. I denoted Intel 64 (32-bit, 64-bit) for Mac OS X 10.6 through OS X 10.11, but did not do it for Mac OS X 10.4 and 10.5. The reason is that both of Tiger and Leopard do not equip with a 64-bit kernel, but that realised IA-32 and 64-bit architecture are visible to the end users. As to Snow Leopard and later versions, 64-bit kernel is provided, so 64-bit and 32-bit applications both are supported under Intel 64 architecture.

As to the uname -a, ok, for system equipped with 32-bit only EFI firmware, or EFI32, the results of uname -pm is i386, i386, even if the processor is 64-bit and 64-bit applications are supported.

-- IP user who edited the following table 119.51.186.57 (talk) 08:26, 1 November 2015 (UTC)

In third table below, I've also added information on additional operating environments supplemented by Classic Environment and Boot Camp. Classic Environment provided two ways for backward compatibilities with applications written for Mac OS, hosted within Mac OS X, or a secondary O/S installed onto the same computer. While Boot Camp is widely considered to be a utility for creating storage space and providing drivers for Windows O/S. Even without Boot Camp, users could also install Windows onto an Intel Mac, making it as the only O/S. But Macintosh is not designed for completely open standard computing system. It does not set up some open standards on configurations for other computer manufacturers to clone their products. Mac OS X is the necessary and inseparable part of Macintosh. The Intel Mac provides the compatibilities to Microsoft Windows O/S, for the firmware, storage space, hardware support,..., and everything based on Intel core enable the implementation of compatibilities easier than ever before. But that is not to say that it is another PC from Apple, just Boot Camp is that window from Macintosh towards Windows O/S. So the support of Windows O/S is also part of Mac OS X system. I merged two environments into one column, and treated them both equally.

--IP User edited the following tables 218.27.80.215 (talk) 02:54, 5 November 2015 (UTC)

At this moment, the table in the main article is still problematic, and my suggestion and effort turn to be completely in vain. Es ist sehr schade, aber I am  Done from here.

-- IP User who edited the following tables 218.27.81.236 (talk) 05:47, 8 November 2015 (UTC)

Janagawen, your suggestions were bogus, which is why they were in vain. If you seriously think, for example, that the bit-width of the kernel is different from the bit-width of supported kexts, you are so ignorant of the OS X kernel that your changes made the table worse, not better. Guy Harris (talk) 09:19, 8 November 2015 (UTC)

Who is Janagawen? What is that? That takes non-sense. But please correct the codenames of Mac OS X Developer Preview and Public Beta. Besides that, Application support is a worse description, you might use kind to take place of it. Mac OS X 10.2 G5 release supports PowerPC G5 (PowerPC 970) processor, but you could treat it as another 32-bit PowerPC processor. Rhapsody Developer Release provided 80486 release first, and then for PowerPC. Those could be called bogus which you find time to debug in the future.

"bit-width of the kernel is different from the bit-width of supported kexts", sorry, I do not understand what you said. But on the first table shown below, take Mac OS X 10.2.8 G5 for example, it possesses a 32-bit kernel with supporting only 32-bit KEXT, but in order to support PowerPC G5, instructions of 64-bit architecture (PPC64) are necessary involved. As to Mac OS X 10.3, advanced features of PowerPC G5 is borrowed into its kernel, which in Mac OS X 10.4 is also further extended to support 64-bit processes depending on 64-bit version of libSystem. How can a 32-bit kernel support a 64-bit process above on it? Blind, like it in all those beautiful and innocent days when 32-bit applications running on 16-bit DOS? No, completely no. But the fact is that they are not virgins! They are just essentially 32-bit kernels, from the 32-bit standpoint, they are upward to support 64-bit computing. But the true story is just like that an experienced actress portrays an innocent young lady. OK, you could treat it a bogus. I have already said done from here, but I have to make those words.

-- IP user who edited the following tables Janagewen7 (talk) 00:20, 17 November 2015 (UTC)

Tables associated with the above section

Those following tables are modified by Janagewen

Sample One

Mac OS X version information

Note: In the following table, IA-32 refers to the 32-bit architecture of 32-bit Intel processors;
while Intel 64 refers to the 64-bit architecture of 64-bit Intel processors, which also provides backward-compatible environment for programmes written for IA-32

Version	Codename	Firmware Support	Processor Support	Processor Architecture	Kernel Mode		Date announced	Release date	Most recent version
					Kernel	ISA
Rhapsody Developer Release	Grail1Z4 / Titan1U	Open Firmware	PowerPC	PPC32	32-bit	32-bit	Un­known	August 31, 1997	DR2 (May 14, 1998)
		BIOS	Intel	IA-32			Un­known
Mac OS X Server 1.0	Hera	Open Firmware	PowerPC	PPC32			Un­known	March 16, 1999	1.2v3 (October 27, 2000)
Mac OS X Developer Preview	Kodiak						May 11, 1998	March 16, 1999	DP4 (April 5, 2000)
Public Beta	Cheetah						Un­known	September 13, 2000	—
Mac OS X 10.0	Cheetah						Un­known	March 24, 2001	10.0.4 (June 22, 2001)
Mac OS X 10.1	Puma						July 18, 2001	September 25, 2001	10.1.5 (June 6, 2002)
Mac OS X 10.2	Jaguar					32-bit 64-bit	May 6, 2002	August 24, 2002	10.2.8 (October 3, 2003)
Mac OS X 10.3	Panther				32-bit		June 23, 2003	October 24, 2003	10.3.9 (April 15, 2005)
Mac OS X 10.4	Tiger			PPC32, PPC64			May 4, 2004	April 29, 2005	10.4.11 (November 14, 2007)
		EFI32, EFI64	Intel	IA-32, PPC32 Intel 64			June 6, 2005 (10.4.1)	January 10, 2006 (10.4.4)
	Tiger (Universal)	Open Firmware EFI32, EFI64	PowerPC, Intel	PPC32, IA-32 PPC64, Intel 64			August 10, 2006 (Server 10.4.7)	August 10, 2006 (Server 10.4.7)
Mac OS X 10.5	Leopard						June 26, 2006	October 26, 2007	10.5.8 (August 5, 2009)
Mac OS X 10.6	Snow Leopard	EFI32, EFI64	Intel	IA-32, PPC32 Intel 64 (32-bit, 64-bit)	32-bit 64-bit		June 9, 2008	August 28, 2009	10.6.8 v1.1 (July 25, 2011)
Mac OS X 10.7	Lion		Intel 64	IA-32 Intel 64 (32-bit, 64-bit)		64-bit	October 20, 2010	July 20, 2011	10.7.5 (September 19, 2012)
OS X 10.8	Mountain Lion	EFI64		Intel 64 (32-bit, 64-bit)	64-bit		February 16, 2012	July 25, 2012	10.8.5 (12F45) (October 3, 2013)
OS X 10.9	Mavericks						June 10, 2013	October 22, 2013	10.9.5 (13F1112) (September 18, 2014)
OS X 10.10	Yosemite						June 2, 2014	October 16, 2014	10.10.5 (14F27) (August 13, 2015)
OS X 10.11	El Capitan						June 8, 2015	September 30, 2015	10.11 (15A284) (September 30, 2015)

Sample Two

Mac OS X version information

Note: In the following table, IA-32 refers to the 32-bit architecture of 32-bit Intel processors;
while Intel 64 refers to the 64-bit architecture of 64-bit Intel processors, which also provides backward-compatible environment for programmes written for IA-32

Version	Codename	Firmware Support				Processor Support				Processor Architecture				Kernel Mode		Date announced	Release date	Most recent version
		OF	BIOS	EFI32	EFI64	PowerPC	Intel	32-bit	64-bit	PPC32	PPC64	IA-32	Intel 64	32-bit	64-bit
Rhapsody Developer Release	Grail1Z4 / Titan1U	Y	N	N	N	Y	N	Y	N	Y	N	N	N	Y	N	Un­known	August 31, 1997	DR2 (May 14, 1998)
		N	Y			N	Y			N		Y				Un­known
Mac OS X Server 1.0	Hera	Y	N			Y	N			Y		N				Un­known	March 16, 1999	1.2v3 (October 27, 2000)
Mac OS X Developer Preview	Kodiak															May 11, 1998	March 16, 1999	DP4 (April 5, 2000)
Public Beta	Cheetah															Un­known	September 13, 2000	—
Mac OS X 10.0	Cheetah															Un­known	March 24, 2001	10.0.4 (June 22, 2001)
Mac OS X 10.1	Puma															July 18, 2001	September 25, 2001	10.1.5 (June 6, 2002)
Mac OS X 10.2	Jaguar								Y					YB		May 6, 2002	August 24, 2002	10.2.8 (October 3, 2003)
Mac OS X 10.3	Panther														U	June 23, 2003	October 24, 2003	10.3.9 (April 15, 2005)
Mac OS X 10.4	Tiger										C					May 4, 2004	April 29, 2005	10.4.11 (November 14, 2007)
		N		Y	Y	N	Y			E	N	Y	C			June 6, 2005 (10.4.1)	January 10, 2006 (10.4.4)
	Tiger (Universal)	Y				Y				YE	C					August 10, 2006 (Server 10.4.7)	August 10, 2006 (Server 10.4.7)
Mac OS X 10.5	Leopard										Y		Y			June 26, 2006	October 26, 2007	10.5.8 (August 5, 2009)
Mac OS X 10.6	Snow Leopard	N				N				E	N				UY	June 9, 2008	August 28, 2009	10.6.8 v1.1 (July 25, 2011)
Mac OS X 10.7	Lion							N		N				B		October 20, 2010	July 20, 2011	10.7.5 (September 19, 2012)
OS X 10.8	Mountain Lion			N										N	Y	February 16, 2012	July 25, 2012	10.8.5 (12F45) (October 3, 2013)
OS X 10.9	Mavericks															June 10, 2013	October 22, 2013	10.9.5 (13F1112) (September 18, 2014)
OS X 10.10	Yosemite															June 2, 2014	October 16, 2014	10.10.5 (14F27) (August 13, 2015)
OS X 10.11	El Capitan															June 8, 2015	September 30, 2015	10.11 (15A284) (September 30, 2015)
Version	Codename	OF	BIOS	EFI32	EFI64	PowerPC	Intel	32-bit	64-bit	PPC32	PPC64	IA-32	Intel 64	32-bit	64-bit	Date announced	Release date	Most recent version
		Firmware Support				Processor Support				Processor Architecture				Kernel Mode

• Y: yes and present
• N: no and unavailable
• E: emulated and presented
• B: backward implemented and presented
• U: upward implemented, unavailable
• YE: physically or virtually presented
• YB: physically presented or backward implemented and presented
• UY: upward implemented, unavailable or physically presented
• C: 64-bit application only supported on text BSD UNIX layer

Sample Three

Mac OS X version information

Note: In the following table, IA-32 refers to the 32-bit architecture of 32-bit Intel processors;
while Intel 64 refers to the 64-bit architecture of 64-bit Intel processors, which also provides backward-compatible environment for programmes written for IA-32

Version	Codename	Firmware Support	Processor Support	Processor Architecture			Kernel Mode	Classic Environment	Date announced	Release date	Most recent version
				Application	KEXT	Kernel
Rhapsody Developer Release	Grail1Z4 / Titan1U	Open Firmware	PowerPC	PPC32	PPC32	PPC32	32-bit	Mac OS 8	Un­known	August 31, 1997	DR2 (May 14, 1998)
		BIOS	Intel	IA-32	IA-32	IA-32		—	Un­known
Mac OS X Server 1.0	Hera	Open Firmware	PowerPC	PPC32	PPC32	PPC32		Mac OS 8.5.1	Un­known	March 16, 1999	1.2v3 (October 27, 2000)
Mac OS X Developer Preview	Kodiak							Un­known	May 11, 1998	March 16, 1999	DP4 (April 5, 2000)
Public Beta	Cheetah							Mac OS 9.0.4	Un­known	September 13, 2000	—
Mac OS X 10.0	Cheetah							Mac OS 9.1 and later	Un­known	March 24, 2001	10.0.4 (June 22, 2001)
Mac OS X 10.1	Puma								July 18, 2001	September 25, 2001	10.1.5 (June 6, 2002)
Mac OS X 10.2	Jaguar					PPC32 (PPC64)			May 6, 2002	August 24, 2002	10.2.8 (October 3, 2003)
Mac OS X 10.3	Panther					PPC32 PPC64	32-bit		June 23, 2003	October 24, 2003	10.3.9 (April 15, 2005)
Mac OS X 10.4	Tiger			PPC32 PPC64 (CLI only)					May 4, 2004	April 29, 2005	10.4.11 (November 14, 2007)
		EFI32, EFI64	Intel	IA-32, PPC32 Intel 64 (CLI only)	IA-32	IA-32, Intel 64		Microsoft Windows	June 6, 2005 (10.4.1)	January 10, 2006 (10.4.4)
	Tiger (Universal)	Open Firmware EFI32, EFI64	PowerPC, Intel	PPC32, IA-32 PPC64, Intel 64 (CLI only)	PPC32, IA-32	PPC32, IA-32, PPC64, Intel 64			August 10, 2006 (Server 10.4.7)	August 10, 2006 (Server 10.4.7)
Mac OS X 10.5	Leopard			PPC32, PPC64 IA-32, Intel 64					June 26, 2006	October 26, 2007	10.5.8 (August 5, 2009)
Mac OS X 10.6	Snow Leopard	EFI32, EFI64	Intel	IA-32, PPC32, Intel 64	IA-32 Intel 64	IA-32 Intel 64	32-bit 64-bit		June 9, 2008	August 28, 2009	10.6.8 v1.1 (July 25, 2011)
Mac OS X 10.7	Lion		Intel 64	IA-32, Intel 64		Intel 64			October 20, 2010	July 20, 2011	10.7.5 (September 19, 2012)
OS X 10.8	Mountain Lion	EFI64			Intel 64		64-bit		February 16, 2012	July 25, 2012	10.8.5 (12F45) (October 3, 2013)
OS X 10.9	Mavericks								June 10, 2013	October 22, 2013	10.9.5 (13F1112) (September 18, 2014)
OS X 10.10	Yosemite								June 2, 2014	October 16, 2014	10.10.5 (14F27) (August 13, 2015)
OS X 10.11	El Capitan								June 8, 2015	September 30, 2015	10.11 (15A284) (September 30, 2015)
Version	Codename	Firmware Support	Processor Support	Application	KEXT	Kernel	Kernel Mode	Boot Camp	Date announced	Release date	Most recent version
				Processor Architecture

 Done