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

(Comment by block-evading sockpuppet removed per WP:DENY. See Wikipedia:Sockpuppet investigations/Janagewen.)

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)

(Comment by block-evading sockpuppet removed per WP:DENY. See Wikipedia:Sockpuppet investigations/Janagewen.)

"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)

(Comment by block-evading sockpuppet removed per WP:DENY. See Wikipedia:Sockpuppet investigations/Janagewen.)

"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)

(Comment by block-evading sockpuppet removed per WP:DENY. See Wikipedia:Sockpuppet investigations/Janagewen.)

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)

(Comment by block-evading sockpuppet removed per WP:DENY. See Wikipedia:Sockpuppet investigations/Janagewen.)

"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)

(Comment by block-evading sockpuppet removed per WP:DENY. See Wikipedia:Sockpuppet investigations/Janagewen.)

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)

(Comment by block-evading sockpuppet removed per WP:DENY. See Wikipedia:Sockpuppet investigations/Janagewen.)

"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)

(Comment by block-evading sockpuppet removed per WP:DENY. See Wikipedia:Sockpuppet investigations/Janagewen.)

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)

(Comment by block-evading sockpuppet removed per WP:DENY. See Wikipedia:Sockpuppet investigations/Janagewen.)

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)

(Comment by block-evading sockpuppet removed per WP:DENY. See Wikipedia:Sockpuppet investigations/Janagewen.)

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)

(Comment by block-evading sockpuppet removed per WP:DENY. See Wikipedia:Sockpuppet investigations/Janagewen.)

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)

(Comment by block-evading sockpuppet removed per WP:DENY. See Wikipedia:Sockpuppet investigations/Janagewen.)

"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)

(Comment by block-evading sockpuppet removed per WP:DENY. See Wikipedia:Sockpuppet investigations/Janagewen.)

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)

(Comment by block-evading sockpuppet removed per WP:DENY. See Wikipedia:Sockpuppet investigations/Janagewen.)

"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)

(Comment by block-evading sockpuppet removed per WP:DENY. See Wikipedia:Sockpuppet investigations/Janagewen.)

(Comment by block-evading sockpuppet removed per WP:DENY. See Wikipedia:Sockpuppet investigations/Janagewen.)

(Comment by block-evading sockpuppet removed per WP:DENY. See Wikipedia:Sockpuppet investigations/Janagewen.)

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)

(Comment by block-evading sockpuppet removed per WP:DENY. See Wikipedia:Sockpuppet investigations/Janagewen.)

Tables associated with the above section

(Those following tables are created by Comment by [[Wikipedia:Sockpuppet investigations/Janagewen]|Janagewen], block-evading sockpuppet removed per WP:DENY. See Wikipedia:Sockpuppet investigations/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