Apple pushes devs to deliver 64-bit support with new Snow Leopard beta

[AppleInsider]

As expected, Apple on Wednesday evening provided its vast developer community with a new pre-release distribution of Mac OS X 10.6 Snow Leopard and asked that they focus attention on 64-bit compatibility in their third party kernel extensions.

The seed, true to predictions earlier in the day, is indeed build 10A314, which arrived in tandem with an identically labeled build of Mac OS X 10.6 Snow Leopard Server.

According to people familiar with the matter, Apple is "strongly encouraging" developers to get busy developing and testing 64-bit support in their kernel extensions (typically low level hardware drivers) for the new build.

While relatively few third party developers create kernel-level software, the new operating system won't work in 64-bit if users lack 64-bit versions of the kernel extensions (kexts) they need.

Developers can deliver both 32 and 64-bit kexts that will enable Snow Leopard to automatically boot as a 64-bit kernel on 64-bit hardware, including all Macs that use a Core 2 Duo or Xeon CPU, while also working properly in 32-bit on earlier Macs using Core Solo or Core Duo CPUs.

Microsoft faced similar driver transition issues when it tried to move Windows XP users to Windows Vista, which used a new driver architecture. Windows users have also faced some transition problems in moving from the 32-bit versions of Windows XP and Vista to the 64-bit versions of those operating systems.

Apple's need to get kernel developers up to speed on 64-bit support is somewhat less problematic because Mac OS X runs on a much smaller subset of hardware than Windows does, and Apple develops or manages most of the kernel-level driver software that most Mac users need to use the new 64-bit kernel.

Users who have specialized hardware and want to run Snow Leopard in 64-bit will need to make sure their vendors supply them with 64-bit versions of those drivers by the time the new operating system ships; it is expected to be released sometime this summer.

Other software faces less urgency in moving to 64-bit, as the Snow Leopard 64-bit kernel has no problem running 32-bit software outside of the kernel; it just can't run 32-bit kernel drivers. Other 64-bit processes similarly can't run 32-bit plugins or extensions, so developers of "pref pane" modules that get installed in System Preferences will need to release 64-bit versions of those items to allow users to run the 64-bit version of System Preferences.

The Cupertino-based Mac maker is also reportedly equipping developers with a new 64-bit transition guide to make the process as smooth as possible.

Other change arriving alongside the new build are an updated version of Xcode and the ability to install Snow Leopard on MacBook Airs wirelessly via Remote Install, those familiar with the matter say.

As was mentioned earlier, it appears Apple will hold any cosmetic changes to Snow Leopard's interface from the public until its annual developers conference in June.

[ View this article at AppleInsider.com ]

[hmurchison]

64-bit or bust

[melgross]

These requirements will separate the women from the girls in the programming world.

[iVlad]

Nice, Apple must be so busy with all this new programming. Two new Operating Systems at once. Just amazing.

[ltcommander.data]

Do printer drivers need to be 64-bit? Seeing the OS X always promotes the number of printers it supports out of the box, it'll be interesting to see the effort needed to move them all over to 64-bit.

[melgross]

Originally Posted by ltcommander.data

Do printer drivers need to be 64-bit? Seeing the OS X always promotes the number of printers it supports out of the box, it'll be interesting to see the effort needed to move them all over to 64-bit.

Drivers are supposed to be 64 bit. This is one of the problems MS had with the initial Vista release. So few drivers were ready. Apple does much of he work here, so we'll see if that helps the situation.

[GregAlexander]

It'd be nice to have an app to tell us how much of our system is ready for 64bit. Look at our computer, printers, system prefs, etc ... Apple did that before for one of the transitions didn't it?

Originally Posted by iVlad

Nice, Apple must be so busy with all this new programming. Two new Operating Systems at once. Just amazing.

I presume that they cross over quite extensively. But they'll focus more on iPhone OS 3.0 being released June/July after which they'll give more attention to the Snow Leopard release. I wonder if the old trusty AppleTV is going to see an upgrade beyond 10.4.7 (or a totally new box).

[hmurchison]

Originally Posted by GregAlexander

I presume that they cross over quite extensively. But they'll focus more on iPhone OS 3.0 being released June/July after which they'll give more attention to the Snow Leopard release. I wonder if the old trusty AppleTV is going to see an upgrade beyond 10.4.7 (or a totally new box).

That's how I see it playing out as well. SL will move along at a steady pace and once the team gets the iPhone SDK done and WWDC hits it's fast break time on Snow Leopard.

I'm still holding out for an Apple TV upgrade this year.

[scottkitts]

With all the arguments in favor of dropping PPC support with Snow Leopard (disregarding the fact that the G5's were/are 64bit and dual processor equipped), why bother with the 32bit version at all? Seems like a lot of effort just to support some old Mac minis. Why not just do a clean break with the past and go 64bit only? Seems odd to support one kind of legacy hardware and not some others. Or is Snow Leopard more marketing based than technology based?

[melgross]

Originally Posted by scottkitts

With all the arguments in favor of dropping PPC support with Snow Leopard (disregarding the fact that the G5's were/are 64bit and dual processor equipped), why bother with the 32bit version at all? Seems like a lot of effort just to support some old Mac minis. Why not just do a clean break with the past and go 64bit only? Seems odd to support one kind of legacy hardware and not some others. Or is Snow Leopard more marketing based than technology based?

I believe that Apple would have a problem dropping any Intel support right now. While Jobs said, in the introduction to the new coming Intel platform, "We are done with "Power". That's a paraphrase, of course. but the idea was that they were finished with it.

People who rushed to buy the new Yonah 32 bit systems were led to believe that support for them would be around for a while. Perhaps in 10.7 they can drop that. I don't see how they could do that now.

I'm still not sure, in the absence of anything from Apple, that we might not see a cut down PPC only version of 10.6 for the G5's, and possibly even for the last fastest dual cpu G4's.

[hmurchison]

Originally Posted by scottkitts

With all the arguments in favor of dropping PPC support with Snow Leopard (disregarding the fact that the G5's were/are 64bit and dual processor equipped), why bother with the 32bit version at all? Seems like a lot of effort just to support some old Mac minis. Why not just do a clean break with the past and go 64bit only? Seems odd to support one kind of legacy hardware and not some others. Or is Snow Leopard more marketing based than technology based?

I think the push will be to do 64-bit even if you feel like your app in no way benefits from it. I think if Apple attempted to ship 64-bit binary support only they'd run into problems with the inevitable developers that won't or can't move their codebase to 64-bit and consumers would scream.


I have a Yonah system but just today my 2Ghz Merom chip came so I'll be on Yonah for a couple more weeks at the most.

[solipsism]

Originally Posted by scottkitts

With all the arguments in favor of dropping PPC support with Snow Leopard (disregarding the fact that the G5's were/are 64bit and dual processor equipped), why bother with the 32bit version at all? Seems like a lot of effort just to support some old Mac minis. Why not just do a clean break with the past and go 64bit only? Seems odd to support one kind of legacy hardware and not some others. Or is Snow Leopard more marketing based than technology based?

There seems to be a few reasons.

1) Compiling for PPC and x86 seems to be a lot more work than updating some drivers which will need to be updated anyway to move to 64-bit.

2) While there are PPC machines in use that are all much older (in computing terms) than the last of the 32-bit HW Macs.

3) If you do need a driver that is only 32-bit, unlike with Windows, you'll be able to still use it by running the entire system in 32-bit. This is more than just the CPU.

[walueg]

If I see "Cupertino based Mac maker" one more time, I think I'll scream! It's Apple! Using that other name is clumsy and adds nothing to the conversation. I know they say to use stuff like that in Journalism 101, but that's for dealing with entities that are unfamiliar to the general reading audience.

[MShock]

I have a feeling the iPhone 3.0 software will be a more unified look, and SL will also resemble that. Bye Bye Aqua... say hello to the iPhone's see through black scroll bars. Or at least that will be an option. If they put the pause on cosmetics, then I bet there will be only simple alterations like that.

With a new kernel, I wish there was some news about ZFS and its integration with the 64-bit kernel. It works on 32-bit very well, and with a new Finder, I would presume work would be underway to integrate ZFS with the rest of the system. I hope it is an option on the client, at least. Full migration can happen in 10.7 as long as I have better data integrity and compression now. My guess on what's holding up ZFS news... integration with Filevault and Time Machine. Combined with an NDA no one wants to break.

[gmcalpin]

Originally Posted by walueg

If I see "Cupertino based Mac maker" one more time, I think I'll scream! It's Apple! Using that other name is clumsy and adds nothing to the conversation. I know they say to use stuff like that in Journalism 101, but that's for dealing with entities that are unfamiliar to the general reading audience.

It's also because when you're talking about Apple's upcoming Apple products at an Apple news website, you don't end up having the word "Apple" every other word. Apple.

Trust me, Apple as a survivor Apple of Writing 101 Appleclasses (if not Apple Journalism 101 Apple classes), Apple synonyms Apple are Apple a Apple Apple good Apple thing.

[mcarling]

I just want Resolution Independence.

[ltcommander.data]

Originally Posted by solipsism

3) If you do need a driver that is only 32-bit, unlike with Windows, you'll be able to still use it by running the entire system in 32-bit. This is more than just the CPU.

Do you mean it'll be flexible enough that you can reboot the OS and kernel in 32-bit or 64-bit mode for the same installation with just a restart? That would be amazing although I would guess keeping things coherent would be really difficult.

While it would be nice, I'm not optimistic for switching between 32-bit and 64-bit to be so easy. I'm guessing Apple is providing 32-bit Snow Leopard so that people who have devices or drivers that aren't 64-bit ready or may never be 64-bit ready even if their Mac has 64-bit compliant hardware can still use Snow Leopard in 32-bit mode. As an added benefit, original 32-bit Core Duos will be supported too. Making Snow Leopard 64-bit only would definitely slow adoption of Snow Leopard, which isn't what Apple wants. Snow Leopard will probably default to installing 32-bit to avoid problems, but there will be a 64-bit kernel option as well.

[melgross]

Originally Posted by ltcommander.data

Do you mean it'll be flexible enough that you can reboot the OS and kernel in 32-bit or 64-bit mode for the same installation with just a restart? That would be amazing although I would guess keeping things coherent would be really difficult.

While it would be nice, I'm not optimistic for switching between 32-bit and 64-bit to be so easy. I'm guessing Apple is providing 32-bit Snow Leopard so that people who have devices or drivers that aren't 64-bit ready or may never be 64-bit ready even if their Mac has 64-bit compliant hardware can still use Snow Leopard in 32-bit mode. As an added benefit, original 32-bit Core Duos will be supported too. Making Snow Leopard 64-bit only would definitely slow adoption of Snow Leopard, which isn't what Apple wants. Snow Leopard will probably default to installing 32-bit to avoid problems, but there will be a 64-bit kernel option as well.

The entire concept is clumsy at best. I doubt people will want to do it.

[adisor19]

Originally Posted by mcarling

I just want Resolution Independence.

That makes 2 of us. I'm eager to see if there's any change in regards to this in this build cause so far things are NOT looking good.

Adi

[solipsism]

Originally Posted by ltcommander.data

Do you mean it'll be flexible enough that you can reboot the OS and kernel in 32-bit or 64-bit mode for the same installation with just a restart? That would be amazing although I would guess keeping things coherent would be really difficult.

Actually, that is what it means. Right now, only the XServe will boot into the 64-bit kernel by default because very few drivers are needed for it. Most other 64-bit machines are capable of using the 64-bit kernel of SL but use the 32-bit kernel by default, for now. To switch between kernels at startup you simply boot the Mac while holding down the '3' and '2' keys or '6' and '4' keys, for 32-bit and 64-bit, respectively.

[uni]

You need the $500 Developer package to get access to the seeds, right?

[melgross]

Originally Posted by uni

You need the $500 Developer package to get access to the seeds, right?

Why would you want them unless you are going to develop something?

You surely wouldn't want to run with them.

[solipsism]

Originally Posted by italiankid

10.6 betas see to be coming so often, yet, 10.5.7 has taken over a month of betas... must have tons of issues... and Apple released Safari 4 Beta 1 over a month ago. Come on Apple, start focusing on these two current platforms. It seems they are rushing out 10.6 to run head to head with Microsoft Windows 7. Windows 7 is fierce. Probably Microsoft's best OS to date. I love it and can't wait for release.

Apple has a lot to do to win customers over or to keep afloat.

You logic doesn't make sense. You state that the more frequent SL betas mean that Apple is focusing more on their beta SW than their current SW, but then you mention the 10.5.7 which has had many more betas seeded is a shorter time frame which blows away your previous statement.

You also state that Apple should focus on current platforms and seem to imply that Apple shoudl focus more on Safari 4 beta. Which is a beta regardless of it being public or not. That Beta 1 was in development for at least 6 months as Safari 4. Granted, they changed up the front end in many ways, but the back end is the nearly similar to the previous Safari 4 beta.

Finally, Apple is in absolutely no risk or going under as you suggest. They will not be closing their doors or declaring bankruptcy.

[ltcommander.data]

Originally Posted by solipsism

Actually, that is what it means. Right now, only the XServe will boot into the 64-bit kernel by default because very few drivers are needed for it. Most other 64-bit machines are capable of using the 64-bit kernel of SL but use the 32-bit kernel by default, for now. To switch between kernels at startup you simply boot the Mac while holding down the '3' and '2' keys or '6' and '4' keys, for 32-bit and 64-bit, respectively.

Really? That's pretty impressive.

Will Apple be requiring all 64-bit drivers, plugins and extensions be compiled as Universal Binaries with a 32-bit code path as well for backwards compatibility? I think that would be wise otherwise you could have disappearing devices and preference planes when you switch between booting the 32-bit and 64-bit kernel which could be confusing and unintuitive.

On a side note, I wonder if Apple is going to enable compiling to SSSE3 as the default for all 64-bit apps? I believe SSE2 is the compiling target for all Intel applications right now, but since all Core 2 Duo and up chips that support x64 already also support SSSE3, Apple might as well enable it. Intel's compiler for Mac already does this. I'd think there would be some performance improvements to be had from autovectorization and SSSE3 since it's a superset that includes SSE3 which contains instructions meant to help optimize code for Hyperthreading processors, which with Nehalem, are the future. Even Atom's that are 64-bit capable have SSSE3 and so do AMD's latest processors so it's not like it'll limit Apple's processor selection. If Apple is going to enable SSSE3 as the default target for 64-bit apps, they might as well do it now before 64-bit apps become common since there would no doubt be more complaints if they changed it later forcing retesting.

[kim kap sol]

Originally Posted by italiankid

apple has a lot to do to win customers over or to keep afloat.

o rly!?

[melgross]

Originally Posted by ltcommander.data

Really? That's pretty impressive.

Will Apple be requiring all 64-bit drivers, plugins and extensions be compiled as Universal Binaries with a 32-bit code path as well for backwards compatibility? I think that would be wise otherwise you could have disappearing devices and preference planes when you switch between booting the 32-bit and 64-bit kernel which could be confusing and unintuitive.

As you know, Universal Binaries refers to Intel/PPC code. For the sake of clarity, I suggest that you not use that term for this. Just say 32/64 code.

On a side note, I wonder if Apple is going to enable compiling to SSSE3 as the default for all 64-bit apps? I believe SSE2 is the compiling target for all Intel applications right now, but since all Core 2 Duo and up chips that support x64 already also support SSSE3, Apple might as well enable it. Intel's compiler for Mac already does this. I'd think there would be some performance improvements to be had from autovectorization and SSSE3 since it's a superset that includes SSE3 which contains instructions meant to help optimize code for Hyperthreading processors, which with Nehalem, are the future. Even Atom's that are 64-bit capable have SSSE3 and so do AMD's latest processors so it's not like it'll limit Apple's processor selection. If Apple is going to enable SSSE3 as the default target for 64-bit apps, they might as well do it now before 64-bit apps become common since there would no doubt be more complaints if they changed it later forcing retesting.

Good question. Of course, the new chips use SSE4, or even 4.2.

[ltcommander.data]

Originally Posted by melgross

As you know, Universal Binaries refers to Intel/PPC code. For the sake of clarity, I suggest that you not use that term for this. Just say 32/64 code.

I guess I was drawn in by Apple's talk of UB's supporting 4 architectures: 32-bit PPC, 64-bit PPC, x86, and x64.

Originally Posted by melgross

Good question. Of course, the new chips use SSE4, or even 4.2.

Well SSE4.1 or SSE4.2 of course couldn't be used as the default compilation option in 64-bit without by default excluding the many Merom based Macs.

It's actually interesting that Apple's latest compiler for XCode is based on GCC4.2 which if I'm not mistaken doesn't support SSE4. It might not even support SSSE3. I believe Apple's version of GCC4.2 recognize SSSE3 and SSE4, but seeing GCC4.3 specifically mentioned adding SSE4 support, GCC4.2 probably doesn't really optimize for it. Seeing GCC4.2 for XCode was recently released, it doesn't seem likely that Apple will release yet another compiler so soon, so I guess some performance benefits of the new chips will be left on the table for now.

[iansilv]

Originally Posted by mcarling

I just want Resolution Independence.

Yes! I could not agree more!

[melgross]

Originally Posted by ltcommander.data

I guess I was drawn in by Apple's talk of UB's supporting 4 architectures: 32-bit PPC, 64-bit PPC, x86, and x64.


Well SSE4.1 or SSE4.2 of course couldn't be used as the default compilation option in 64-bit without by default excluding the many Merom based Macs.

It's actually interesting that Apple's latest compiler for XCode is based on GCC4.2 which if I'm not mistaken doesn't support SSE4. It might not even support SSSE3. I believe Apple's version of GCC4.2 recognize SSSE3 and SSE4, but seeing GCC4.3 specifically mentioned adding SSE4 support, GCC4.2 probably doesn't really optimize for it. Seeing GCC4.2 for XCode was recently released, it doesn't seem likely that Apple will release yet another compiler so soon, so I guess some performance benefits of the new chips will be left on the table for now.

I'm not suggesting that it be used as a default compilation. But support is up to the software developers anyway. If they want to support 4 and above, they can.

[hohlecow]

Originally Posted by melgross

As you know, Universal Binaries refers to Intel/PPC code. For the sake of clarity, I suggest that you not use that term for this. Just say 32/64 code.

Universal Binary is just a marketing term for fat Mach-O binaries. It doesn't matter if its Intel/PPC, 32/64, ARM/ia32/x86-64/ppc32/ppc64/Hobbit/68k. NeXTSTEP supported this, and there are currently 4 architectures Xcode will allow you to build and package binaries for (PPC32/PPC64/ia32/x86-64).

Since a Universal Binary can contain any subset of PPC/x86 32/64 bit binaries (and maybe more in the future, and a few more in the past), it seems silly to place artificial limit on the term.

[arteckx]

Originally Posted by AppleInsider

Other software faces less urgency in moving to 64-bit, as the Snow Leopard 64-bit kernel has no problem running 32-bit software outside of the kernel; it just can't run 32-bit kernel drivers. Other 64-bit processes similarly can't run 32-bit plugins or extensions, so developers of "pref pane" modules that get installed in System Preferences will need to release 64-bit versions of those items to allow users to run the 64-bit version of System Preferences.

I'm surprised this is still an issue. Those super-geniuses are supposed to laugh and tell us it's only normal for us to conclude that this would be a problem. Then they'll write a few lines of code which send the kernel to any-bit land and everything will just work.

[GregAlexander]

Originally Posted by scottkitts

With all the arguments in favor of dropping PPC support with Snow Leopard, why bother with the 32bit version at all? Seems like a lot of effort just to support some old Mac minis. Why not just do a clean break with the past and go 64bit only?

Originally Posted by solipsism

3) If you do need a driver that is only 32-bit, unlike with Windows, you'll be able to still use it by running the entire system in 32-bit. This is more than just the CPU.

I think that makes a LOT of sense.

ie: All things being equal, they might well have abandoned 32bit Intel. But they know that some people will need to run Snow Leopard in 32bit mode anyway to handle their devices... so if they're going to allow that then they may as well allow 32bit Intel hardware at the same time.

[wessan]

I personally hope there are some more languages coming in SL. Czech localization is available for years from third party, but it disables software updates and you have to uninstall it, update and then reinstall, which is not really a mac-like experience. I'm thinking about getting a Mac for my parents, but missing localization is a huge obstacle.

[melgross]

Originally Posted by hohlecow

Universal Binary is just a marketing term for fat Mach-O binaries. It doesn't matter if its Intel/PPC, 32/64, ARM/ia32/x86-64/ppc32/ppc64/Hobbit/68k. NeXTSTEP supported this, and there are currently 4 architectures Xcode will allow you to build and package binaries for (PPC32/PPC64/ia32/x86-64).

Since a Universal Binary can contain any subset of PPC/x86 32/64 bit binaries (and maybe more in the future, and a few more in the past), it seems silly to place artificial limit on the term.

Don't be too technical. We all refer to it as Intel/PPC code, and that's how people understand it.

I'm willing to bet that 99% of the people here don't care about that explanation, and would just like to have a simpler usage for it.

Once the PPC OS is gone, no one will be referring to 32/64 Intel code as a universal binary.

[palegolas]

I must say, I don't REEAALLY get this 32/64 bit thing. The way it's described it sounds like if OS X is booted in 64 bit mode it will still be able to run 32 bit code, albeit probably a little slower in a sort of "virtual 32 bit mode"?

Will users have to know anything about this? Are there gonna be stories where software suddenly is running much slower when upgraded to 10.6 running in 64 bit? Say, for instance CS4, I bet most CS4 apps are 32 bit. Would the user be adviced to boot the whole OS in 32 bit mode for optimal use?

I guess my question is: What does all this mean to the end user?

[lfmorrison]

Originally Posted by palegolas

I must say, I don't REEAALLY get this 32/64 bit thing. The way it's described it sounds like if OS X is booted in 64 bit mode it will still be able to run 32 bit code, albeit probably a little slower in a sort of "virtual 32 bit mode"?

Will users have to know anything about this? Are there gonna be stories where software suddenly is running much slower when upgraded to 10.6 running in 64 bit? Say, for instance CS4, I bet most CS4 apps are 32 bit. Would the user be adviced to boot the whole OS in 32 bit mode for optimal use?

No, 32-bit code will still run at virtually the same speed as they would have on a native 32-bit processor. That is because the CPU's complete 32-bit environment exists as a subset of its 64-bit operation mode.

Also, keep in mind that Leopard already has a mixture of 32-bit applications and 64-bit applications in its userspace, even though Leopard's kernel is 32-bit. When it's running on 64-bit hardware, user applications that have been compiled to operate in 64-bit mode already do so.

[BigPhotos]

As a professional photographer, all I want is for Apple, Epson, and Adobe to get together and make a path for using more than 3 GB of RAM in Photoshop - and then printing prints that are more than 90 inches long on wide-format Epson printers.

Is that too much to ask? Snow Leopard and PS CS5 - with new Epson drivers.

Dick

[shadow]

Originally Posted by melgross

Once the PPC OS is gone, no one will be referring to 32/64 Intel code as a universal binary.

Everyone will be referring to 32/64 Intel code as a universal binary. That's what it is: a binary which contains executable code for more than one architecture.

Even if SL is not supported on PPC, even the new 10.5 compatible applications will use PPC code as well

Originally Posted by palegolas

I must say, I don't REEAALLY get this 32/64 bit thing. The way it's described it sounds like if OS X is booted in 64 bit mode it will still be able to run 32 bit code, albeit probably a little slower in a sort of "virtual 32 bit mode"?

There are several issues here.
First, the jump to 64 bit kernel should be made at some point, and now seems to be a right time.
Second, specific to Intel architecture, the 64-bit applications will benefit from the additional registers available when running in this mode, which translates to some performance improvement.
Third, with the move to 64-bit kernel and OS many low-level components should be re-compiled/re-written, which makes it possible for some modernization on the way, e.g. improvement in the Cocoa run-time architecture.
Forth, the additional address space available allows the implementation of some modern security-related concepts, which benefits the end-user as well.

There is no "virtual 32 bit mode", it is native. But the process is either 32-bit or 64-bit. Plug-ins are loaded by the parent process, thus the issue with the plugins and preference panes. The preference panes are loaded as plugins. If a particular pane is 32-but only, the system Preferences application first restarts itself in 32-bit mode.

Regarding the drivers discussion above:
I think that the 32/64 bit problem does not apply to the printer drivers, more specifically, to the CUPS printer driver architecture, introduced alongside 10.2. It won't hurt if the drivers are 64 bit, of course.

Some clarifications, to avoid misconception:
Even if the kernel is booted in 32-bit mode it is perfectly OK to run 64-bit apps and vice-versa. As far as I remember, there were leaks suggesting that you can select a certain app to load in 32-bit mode, much like the "Launch using Rosetta" option. BTW, I expect the 64-bit mode to be the default for all 64-bit hardware.

[m2002brian]

Originally Posted by melgross

Don't be too technical. We all refer to it as Intel/PPC code, and that's how people understand it.

I'm willing to bet that 99% of the people here don't care about that explanation, and would just like to have a simpler usage for it.

Once the PPC OS is gone, no one will be referring to 32/64 Intel code as a universal binary.

Because you think something means something to you, that's what it should mean to everyone? Right! I had a girlfriend who liked to make her own definitions of real words. Kind of frustrating when somebody says "that's not what it means to me" and then you go read the word right out the dictionary to her. So whatever you think Universal Binary means is probably wrong. Don't tell somebody they're wrong because "people here don't care." In fact I do care, and was happy to know I had learned something I didn't know earlier. I will forever remember now, that, Universal Binary is exactly what the name implies. I'm sure with a little work you'll someday learn to enjoy others ways of thinking instead of wanting them to think like you.

[kim kap sol]

I'm gonna have to side with melgross here. Calling 32/64 binaries Universal Binaries would bring too much confusion.

People will download the Universal Binary thinking they can run it on their PPC Mac.

Sorry but m2002brian and shadow but calling 32/64 binaries UB simply won't work unless it also contains the PPC binary considering people have grown to associate the UB meaning to a PPC/x86 fat binary. You guys can keep calling 32/64 binaries UB but you'd be doing yourself and everyone around you a great disfavor. And if developed apps and called your 32/64 app a Universal Binary, you'd be getting sued by customers still on PPC Macs that bought the app on the premise that it would work on their PPC Mac.

UB means PPC/x86 fat binary. Period. Any other definition given to UBs would be misleading.

http://www.apple.com/universal/

When you see the Universal symbol on Mac applications, that means they’re made to run on both Intel- and PowerPC-based Mac computers.

Of course, this doesn't mean you can't have UBs that contain 32/64 x86 support...but it must also contain the PPC binary for it to be called a UB.