Lion is the first OS X release to drop support for any Intel processors – machines using 32-bit Core Solo and Core Duo machines (sold mostly in 2006 at the very beginning of the Intel switch) aren’t able to install the new OS without hacking (which is outside the scope of this review). This is common practice for Apple, whom habitually irks a small but vocal portion of its userbase who insist (not altogether unreasonably) that their Macs are still running just fine.

Apple usually doesn’t do this lightly – in most cases, dropping support for older models is done to move the platform forward (though, as when 10.4 dropped support for Macs without FireWire, it can also be done to push particular proprietary technology). Just as Snow Leopard pulled support for PowerPC Macs to emphasize Intel development, Lion will pull support for x86 to push 64-bit development.

I’ve seen quite a bit of confusion on this topic (and there was quite a bit when Snow Leopard trumpeted full 64-bit support at its release), so I want to go into some detail about the history of 64-bit OS X. If you’re not interested in that, though, let me lay out the most important stuff in brief:

  • Core Solo and Core Duo-equipped Macs are the only Intel Macs being dropped by Lion. Even if it can’t boot the 64-bit kernel of Lion or support 64-bit EFI, any Mac that came with a Core 2 Duo (or any 64-bit capable Intel processor) can install and run Lion without modification.
  • Core 2 Duo-equipped Macs that don’t support OS X’s 64-bit kernel or 64-bit EFI can still run 64-bit apps, which can address more than 4GB of RAM.
  • The Lion installer isn’t actually doing checks for processor capability, but for your Mac’s model identifier, meaning that Core Solo and Core Duo Mac Minis and iMacs that were later upgraded to Core 2 Duo processors will still fail to install Lion without modification because the installer assumes they’ll be running 32-bit processors (though if you can get Lion running, your processor should be able to run everything just fine). Remember that these processor upgrades, while technically possible, were never supported by Apple.

Now for a history lesson, combined with about as much information about Lion’s 64-bit support as you could ever want.

64-bit in Mac OS X 

OS X’s 64-bit implementation differs significantly from that of Windows, which treats its 32-bit and 64-bit versions as two distinct operating systems stored on different install media. This is done mostly to maintain Windows’ compatibility with older applications – moving or renaming things like the System32 folder would break programs that expected it to be there – and as a result the two are separated to the point that there isn’t even an upgrade path between 32-bit Windows and 64-bit Windows. Because of this, and because Windows applications and drivers usually have distinct 32-bit and 64-bit versions, Windows’ transition to 64-bit has been slightly rockier and slightly more visible to the user.

OS X, on the other hand, has made a more gradual transition between 32-bit and 64-bit, with support added slowly over the course of multiple releases. OS X 10.3 and 10.4 came with some basic support for 64-bit underpinnings, but support for 64-bit applications didn’t come until 10.5 Leopard (which included the 64-bit version of Cocoa, OS X’s primary API). The same technology that allowed developers to offer Intel and PowerPC programs as a single Universal Binary also allows developers to release single packages that support both the x86 and x64 architectures.

While Leopard brought support for 64-bit apps that can address more than 4GB of memory, Snow Leopard actually introduced an OS kernel (along with 64-bit kernel extensions and drivers) that was 64-bit, though a 32-bit kernel was used by default on almost all Macs whether they supported the 64-bit kernel or not. This was done mostly to give software developers time to get 64-bit KEXTs and drivers ready – since Snow Leopard’s release, Apple has released both Mac Pros and MacBook Pros that boot with the 64-bit kernel by default (and OS X Server uses a 64-bit kernel by default in even more models, as outlined in this Apple support document).

Lion pushes this a bit further by booting a 64-bit kernel on basically any Mac that supports it – the 2007 aluminum iMac, the 2009 unibody MacBook Pro, and the 2010 MacBook Air I used booted Snow Leopard with the 32-bit kernel by default, but booted with the 64-bit kernel for Lion (and the iMac and the Air didn't even support the 64-bit kernel in Snow Leopard). That being said, Lion still includes the 32-bit OS X kernel, and will use it on machines that don’t support the 64-bit kernel – you can still make full use of 64-bit apps and more than 4GB of RAM, even though the OS kernel itself can’t. This won't usually be a big deal, since the Macs that can’t use the 64-bit kernel are mostly older models with RAM caps at or under 4GB anyway.

In both Snow Leopard and Lion, you can check your kernel's 64-bitness by opening up System Profiler/Information, going to the Software section, and looking at the "64-bit Kernel and Extensions" field. Yes means a 64-bit kernel, No means 32-bit.

Lion with a 32-bit kernel on a 2008 MacBook

Support for the 64-bit kernel requires four things to be true: You need (obviously) a 64-bit Intel processor, a Mac that supports 64-bit EFI, hardware for which OS X has 64-bit drivers (graphics cards are usually the problematic area here), and a Mac that has not been specifically disallowed from booting the 64-bit kernel – most new Macs support the 64-bit kernel, but white MacBooks are still artificially limited by Apple from booting the 64-bit kernel in Snow Leopard despite hardware that fully supports it. Most if not all of these artificial limitations have been removed in Lion for machines that meet the other 64-bit criteria.

Apple began really pushing 64-bit with its marketing for Snow Leopard, and has been dropping support for 32-bit APIs like Carbon for years – giving developers aiming for Lion guaranteed 64-bit capability both enables them to better take advantage of the architecture improvements and saves them the effort (and file size) of also supporting a 32-bit version. That said, 32-bit programs will continue to run fine in Lion, just as they ran fine in Snow Leopard and Leopard before it.

The hidden downside of the 64-bit push for Core Solo and Core Duo users is that, as developers slowly move to 64-bit only applications, we’ll start getting more and more things that won’t run on 32-bit Snow Leopard despite being supported on 64-bit Snow Leopard (the same thing is currently happening to Leopard users still using PowerPC processors – Flash Player, Google Chrome, Firefox 4, and Microsoft Office 2011 are all fairly mainstream apps that run in Leopard but only on Intel machines). The disappearance of 32-bit programs will be gradual, but it is something to be wary of if you continue to use a Core Solo or Core Duo Mac going forward.

What gets dropped next?

This discussion isn’t complete without a look into our murky crystal ball to see what Macs will be dropped by the next version of Mac OS. The continued push for 64-bit makes me think that we could see machines incapable of running the 64-bit kernel dropped, though that line in the sand could be too faint for most consumers to see, especially given the scarce and not-always-clear documentation on what Macs support it in the first place.

It’s worth noting that Apple could easily issue EFI, KEXT, and driver updates for any Macs it wants to enable to run the 64-bit kernel – there are some models like the 2007 aluminum iMac (iMac 7,1, for those who prefer information pulled from System Profiler) that didn’t support Snow Leopard’s 64-bit kernel, but boot with Lion’s 64-bit kernel by default.

The more likely cutoff point for 10.8 (or OS XI, or whatever comes next) is graphics-related – Apple has been shipping mostly OpenCL-capable products since 2009, and by the time the next Mac OS is upon us (2013-ish, at the current rate), products pre-dating OpenCL support will mostly be four and five years old (roughly the same age as the current Core Solo/Duo Macs). If Apple continues its trend of dropping products that hold back the platform in one way or another, pre-OpenCL machines seem to be the most likely candidates on the chopping block.

Screen Sharing, Boot Camp, Migration Assistant SMB File Sharing in Lion
Comments Locked

106 Comments

View All Comments

  • rs2 - Wednesday, July 20, 2011 - link

    Okay, it makes sense on a touch device where your finger is actually making contact with the thing you are scrolling. But a mouse cursor is *not* a finger. It is not an analog for a finger. It is a different input paradigm entirely, and trying to make it behave as if the mouse cursor is your finger by making scrolling go backwards is stupid.

    It's good that they put in an option to disable the nonsense that is "natural" scrolling.
  • name99 - Thursday, July 21, 2011 - link

    Not at all. The issue is simple : what is the metaphor?
    When I move my finger, am I moving
    - the window container? OR
    - the content?

    Claiming that one is more "natural" than the other is as stupid as claiming that English is more natural than Chinese. It's simply that you are used to one and, like a good American, you simply cannot imagine that the world could possibly be different --- after all, Jesus spoke English.
  • rs2 - Thursday, July 21, 2011 - link

    Not at all. There is no "finger" when using a mouse. Touch and mouse-driven are distinct input paradigms. If a touch-based interface ever scrolled content in the opposite direction that the user moved their finger, then people would say that it was broken. And rightly so. Moving content in the same direction as the touch is the intuitive operating mode of a touch interface.

    And similarly, moving content in the opposite direction of the scroll (or more accurately, moving the scrollbar in the same direction of the scroll) is the intuitive operating mode for a mouse-driven interface. By your logic scrollbars themselves should also be inverted.

    As a side-note, a direct analog to touch style scrolling does exist in the mouse-driven paradigm, it is the drag operation. It is available in some things like Adobe PDF documents, and also work on any scrollbar. In this operation you choose an anchor-point, and then that anchor point moves in the same direction that you move, and it all makes sense. The problem with scrolling is that it has no anchor point, it is a distinct operation from a drag operation, and by conflating the two Apple has broken their interface. At least until they start incorporating touch into every computer they sell.

    Mouse-driven and touch interfaces are not the same thing, and just because a metaphor makes sense in one does not mean that it also makes sense in the other.
  • Uritziel - Friday, July 22, 2011 - link

    Agreed.
  • CharonPDX - Wednesday, July 20, 2011 - link

    On page 23 "Performance: Similar to Snow Leopard", you have a couple bar graphs comparing Snow Leopard to Lion performance. Unfortunately, you use a generic "compared to before as 1.0" metric, with no indication on a per-test basis whether higher or lower is better. In the Core 2 Duo graph, you talk about boot time skyrocketing, and the boot time graph for Lion shows Lion as "about 1.4" of Snow Leopard, yet you also talk about iPhoto having a "greater than 10% increase in performance", where the graph shows "about 1.1" of Snow Leopard. So in one line in the graph, higher is worse, in the other line, higher is better.

    You either need a per-test identifier (Higher is better / Lower is better) or you need to to standardize them all (so 'benchmark' ones would stand as-is, while 'timing' ones would use the inverse, so that both would be 'higher is better', or example.)
  • Deaffy - Thursday, July 21, 2011 - link

    Did anyone check to see whether Apple has included a UI element to enable IPv6 privacy extensions for statelest address autoconfiguration?
    And did DHCPv6 to get IPv6 addresses from your ISP's cable via IPv6 finally make it's entry?
  • Deaffy - Thursday, July 21, 2011 - link

    Oh yeah, and maybe the ability to query a name server via IPv6?
  • kevith - Thursday, July 21, 2011 - link

    they are more and more returning to the Linux it came from. Who knows, they might even go bact to open source:-)
  • Omid.M - Thursday, July 21, 2011 - link

    Anand/Andrew/Christian,

    If you right click on a YouTube video, does it say the rendering AND decoding is "accelerated" ? I thought Lion was supposed to bring that.

    If this is now the case, it'd be enough reason for me to buy Lion and a new MBP 15". I can't stand the fans on my 2008 MBP 15 going nuts every time I watch a 30 second YouTube clip. The laptop gets unreasonably hot right now.

    @moids

    P.S. I'm not a fan of the way buttons appear on the upper borders of windows. There's no typical button "design" to signify that the text is clickable, at least not from the screen shots I saw in the article.
  • Omid.M - Thursday, July 21, 2011 - link

    I guess it's disabled:

    http://www.macrumors.com/2011/07/21/adobe-suggests...

Log in

Don't have an account? Sign up now