Mac OS X Lion: Drops PowerPC Emulation, Adds QuickTime Pro Features, Much More

[AidenShaw]

Lets see MS 2008 is screwed by this unless it is already installed. No way to move it over to a new computer. I saw no reason to jump to 2010 and my laptop is still running on 2007 (Windows 7 here).

But Apple knows that the Apple fans will blame Redmond - not Cupertino. We've all seen that happen time after time.

(Office 2007 is damn solid - and in spite of some time on the learning curve I've come to absolutely love the ribbon interface. Only luddites would complain about it, IMO.)

MS provides real time tables for when support is going to be dropped.

And MS enjoys 95% or so market share.

Not a coincidence.

But - a warning - Windows XP support ends in April 2014.

You have 3 years notice - from now. Microsoft announced the April 2014 date in summer 2008 - 6 years before the end of support.

And some Apple fans think that "reading the tea leaves" six months before is plenty of notice?

 

[MrNomNoms]

QuickTime Pro actually only affected the old QuickTime Player application. Any other application, including the Pro apps, can call into any part of QuickTime (including the editing and fullscreeen APIs) without a QTP key.

Also, the old C-based QuickTime API that QuickTime Pro interacted with is on a clear path to deprecation. It's 32-bit only, so it can't be called from 64-bit applications. 64-bit apps need to either use QTKit or AV Foundation, the latter of which comes from iOS to OSX in Lion. The QuickTime Player X that came out with Snow Leopard (and which doesn't say anything about QuickTime Pro) uses QTKit.

Pro was just a way to get QuickTime to pay for itself until iTunes and the iDevices came around. It confused the marketing message and it's good to see it finally going away.

--Chris

Would it be fair to say that AVFoundation has pretty much replaced QTKit with QTKit pretty much being a 'simplified' API sitting on top of AVFoundation (in the case of Lion)? Regarding 64bit applications and 32bit QuickTime, you can execute the 32bit QuickTime (Adobe Media Encoder CS5 creates a bridge to 32bit QuickTime when encoding audio) but there is a performance penalty IIRC.

Regarding what MagnusVonMagnum wrote; removing legacy code isn't bad in and of itself, the lack of direction being laid down is a problem or simply removing old code without the new replacement actually being feature complete. For example, Microsoft has made it clearly known in its documentation that Media Foundation is the future API to replace around 1/2 dozen various video and audio API's that have existed since Windows first came into existence. The key here is that Microsoft has a clear road map. Compare that to Apple where developers are suddenly told 6 months before the release of Lion that AVFoundation is coming over to Lion but nothing said as to its relationship to QTKit, whether developers should hold off for a more feature complete version of QTKit or whether AVFoundation pretty much replaces QTKit. Apple needs to lay out clear roadmaps so that developers can plan ahead knowing that in, for example 2 years time xyz framework is being replaced with foobah, and the following release the old framework will be removed. Will some developers get annoyed? sure but at least they'll have a roadmap to work from rather than guessing base on tea leaf readings.

Regarding Rosetta, there is a penalty; all the components of Snow Leopard require PPC code to he compiled into each binary for PPC compatibility

There is a reason why:

libSystem.B.dylib: Mach-O universal binary with 3 architectures
libSystem.B.dylib (for architecture x86_64): Mach-O 64-bit dynamically linked shared library x86_64
libSystem.B.dylib (for architecture i386): Mach-O dynamically linked shared library i386
libSystem.B.dylib (for architecture ppc7400): Mach-O dynamically linked shared library ppc

That is the situation, because when a PPC application is run, Rosetta pulls in the PPC code from the various libraries the said application relies on and then translates it on the fly.

Someone else moaned about Office 2008 and the PPC based installer, why is it Apple's fault that Microsoft created a universal binary office suit but couldn't be bothered creating a universal installer? maybe the frustration should be vented at Microsoft just as I vented frustration when Adobe pretty much abandoned CS3 users, and CS4 users have been pretty much hung out to dry with updates taking months (Fireworks and crashing on exit bug took months to fix, if it were a bug with CS5 it would have been resolved in days not months).

AidenShaw, you made a very good point regarding Carbon64 - I've done some reading back then and I don't blame third parties getting angry. Had Apple just came out on day one 5 years ago, when the Intel transition was made, that future developments will be based on Cocoa then at least developers would be annoyed but they would have 5 years to make the transition. I fear that in 6 months time we'll Apple announce at WWDC that QTKit will remain a very basic API and that developers should start using AVFoundation moving into the future. One month later Apple will release Mac OS X Lion and then the chorus of Apple fanboys will start claiming that Adobe sucks because they hadn't moved their code to AVFoundation yet :/

If I was Adobe or some other third party, I would use the least amount of features provided by the operating system - it would require re-inventing the wheel at times but at least you'd be on your own time table and not Apple's.

 

[AidenShaw]

Someone else moaned about Office 2008 and the PPC based installer, why is it Apple's fault that Microsoft created a universal binary office suit but couldn't be bothered creating a universal installer?

In the absence of any clear statement from Apple that Apple intended to abandon support for Rosetta and PPC - why would any project manager allocate resources for rewriting a perfectly functional installer (and risk introducing new bugs)?

No one who's shipped a non-trivial application would even ask the question that you ask. You don't fix "what ain't broke".

If Apple decides to break it at the last minute - Apple should answer for that.l

 

[MrNomNoms]

In the absence of any clear statement from Apple that Apple intended to abandon support for Rosetta and PPC - why would any project manager allocate resources for rewriting a perfectly functional installer (and risk introducing new bugs)?

Yet interesting enough the same project manager was able to allocate resources for a re-writing of a perfectly functional installer (and risk introducing new bugs) when it came to Office 2011 - what changed? Apple hadn't said anything publicly or under the cloak of a NDA so what changed? The fact that in Snow Leopard that Rosetta became an optional extra? Why doesn't Microsoft offer a downloadable installer that the end user runs and installs the software from the DVD instead of the user running it directly off the DVD?

 

[cmaier]

In the absence of any clear statement from Apple that Apple intended to abandon support for Rosetta and PPC - why would any project manager allocate resources for rewriting a perfectly functional installer (and risk introducing new bugs)?

No one who's shipped a non-trivial application would even ask the question that you ask. You don't fix "what ain't broke".

If Apple decides to break it at the last minute - Apple should answer for that.l

Better still - they shouldn't have an installer (this is OS X, after all). Of course, someone needs to tell that to Apple, too.

 

[AidenShaw]

What's 11 minus 8?

Yet interesting enough the same project manager was able to allocate resources for a re-writing of a perfectly functional installer (and risk introducing new bugs) when it came to Office 2011 - what change?

But Office 2011 is not Office 2008, so why assume that the Office 2008 installer would work for 2011?

Most product managers would make the call that "if we have to do a major redo of the installer for the new product - pick a different LCD for the installation".

Better still - they shouldn't have an installer (this is OS X, after all). Of course, someone needs to tell that to Apple, too.

For simple apps, dragging and dropping some files into a folder is fine. For more sophisticated apps that internally launch other application, though, you need to tell the OS about those interactions.

 

[MrNomNoms]

Better still - they shouldn't have an installer (this is OS X, after all). Of course, someone needs to tell that to Apple, too.

Good point, I can understand a pkg for system installation but all applications should be simple drag and drop with all the required stuff sitting inside the said application bundle. I'm hoping that with the rise of the AppStore that maybe more vendors will start using it - Apple has started using it but there are some vendors who can't because their applications don't fall into the parameters set by the AppStore guidelines such as not using private frameworks etc.

Btw, Adobe has to be one of the worse offenders, never have I see so much crap sprawled from one end of the hard drive to the other - the only thing worst than Adobe is probably Symantec and their God forsaken Anti-Virus suit that is so horrible it seems to have the hallmark of a virus itself.

But Office 2011 is not Office 2008, so why assume that the Office 2008 installer would work for 2011?

Most product managers would make the call that "if we have to do a major redo of the installer for the new product - pick a different LCD for the installation".

Office 2008 was Microsoft's first universal binary product, why not make the installer a universal binary as they have done with the suite itself? seems to be rather rediculous you bringing up "why assume that the Office 2008 installer would work for 2011" because it is entirely irrelevant. Office 2008 was a package where all the components were universal binaries - why wasn't the installer. How about addressing the issue rather than repeating the same nauseating nonsense over and over again.

 

[AidenShaw]

does the cliché "don't reinvent the wheel" mean anything?

Office 2008 was Microsoft's first universal binary product, why not make the installer a universal binary as they have done with the suite itself?

Why?

Apple didn't say "make all installers 3 architecture universal binaries, because we're going to surprise you by ripping out support for one of the architectures".

 

[kamil97]

Dropping rosetta?!?!?!?! Now i know for sure that im sticking with snow leopard!!!
(when i actually get an intel mac )

 

[MrNomNoms]

Why?

Apple didn't say "make all installers 3 architecture universal binaries, because we're going to surprise you by ripping out support for one of the architectures".

Which fails to address what I said - they went out of their way to create universal binaries for all the 2008 components except the installer? seems rather stupid. Why did they keep it around? for sentimental reasons? its like tearing down a car, redoing it from the ground up but leaving the muffler as a pile of crap for sentimental reasons.

 

[AidenShaw]

It makes perfect sense, if you stop and think

Which fails to address what I said - they went out of their way to create universal binaries for all the 2008 components except the installer? seems rather stupid. Why did they keep it around? for sentimental reasons? its like tearing down a car, redoing it from the ground up but leaving the muffler as a pile of crap for sentimental reasons.

Think for a second or three.

If you have multi-architecture support, you write the installer in the "universal" architecture. The "universal" installer can interrogate the OS for the native architecture, and install the right bits.

Until Apple ripped Rosetta out of Apple OSX, that "universal" architecture was PPC. Now, is the "universal" architecture x86 - or will they rip that out and replace it with x64 this year or next?

If you're a software vendor selling Apple products, it seems like you should plan on spending 50% of your engineering budget doing nothing but tracking what Apple changes from release to release. (And reading the "tea leaves", since Apple will never give you any advance notice of what Apple are doing.)

 

[munkery]

Totally, there is no way that developers can use the early release of the next version of OS X to developers to get their software development tailored to that release of the next version of OS X. Hey, wait a minute.

 

[KnightWRX]

In the absence of any clear statement from Apple that Apple intended to abandon support for Rosetta and PPC - why would any project manager allocate resources for rewriting a perfectly functional installer (and risk introducing new bugs)?

Why would an installer of all things have source that is not just plainly portable between architectures ? Most open source code compiles accross various OSes and architectures without any hiccups, from things like X11 to full desktop environnements, yet Microsoft can't manage to make an installer that compiles accross 2 on the same OS ?

 

[AidenShaw]

Why would an installer of all things have source that is not just plainly portable between architectures ? Most open source code compiles accross various OSes and architectures without any hiccups, from things like X11 to full desktop environnements, yet Microsoft can't manage to make an installer that compiles accross 2 on the same OS ?

I'm talking about the binary images on the kit that you buy - not the source code.

And what's your example of an MS installer that's not compatible across two OS's - or are you criticizing Microsoft's design choice of having separate x64 and x86 kits instead of fat binaries? (Most of which, of course, are common source compiled for both architectures, but separately.)

 

[AidenShaw]

It would seem like a miracle to an Apple user....

Originally Posted by AidenShaw
I started my spare laptop to type this - a Dell that I got with a Yonah processor in early 2006.

It runs Windows 7 x64 just fine.

You might want to get your story straight: Yonah (Core 1) didn't come with 64 bit instructions, so running x64 on it amounts to a miracle.

And you might want to hone your critical reading skills.

As miraculous as it may seem to someone used to Apple's hardware games, just because I got a Dell with a Yonah doesn't mean that it still has a Yonah.

Dell uses sockets for the CPU - so the original T2600 (Core Duo, 2.16 MHz, 2 MiB cache) was swapped for a T7600 (Core 2 Duo, 2.33 MHz, 4 MiB cache) when the prices for Meroms dropped to normal.

In fact, I bought a dozen T7600s from Newegg and upgraded that many Dell Latitude D620 and Lenovo T61p laptops for our engineers who needed to work with either x64 software or needed VT support for virtualization. (Those were the real reasons to upgrade the CPUs - the slightly faster clock and doubled cache were just icing on the cake.)

Both Dell and Lenovo added Meroms as CPU options to their existing product lines for those and many other models - again something miraculous for an Apple user. When they added the options, the latest downloadable BIOS update included support for the x64 CPUs for already purchased systems.

It helped our TCO a lot by not having to replace laptops for the new processor. If we'd bought Apples - the Yonah Apples would be in the toxic waste dump and we would have paid a lot to get a dozen new Apples with Merom CPUs.

 

[MagnusVonMagnum]

What does Rosetta need in/from the operating system in order to function? Would it be possible to copy over the needed parts from Snow Leopard?

An example with Leopard coming from Tiger comes to mind when I ask this. When Leopard came out, it did not include drivers for the ATI Rage 128 my PowerMac Digital Audio had in it at the time and that card ran like molasses under Leopard without a driver, but I read a thread that said you could just copy over the kexts from Tiger and they would work fine in Leopard and sure enough, performance increased by about a factor of 5x once I did that (which at least made Leopard usable with the Rage 128, although still slower than Tiger, but then on the other hand Tiger is still 2x faster for 2D graphics in terms of the user interface even with my ATI Radeon 9800 Pro I added a short time afterward and it does have full Leopard support. The difference is not night and day noticeable with daily operations, but it shows up in the Xbench GUI test.

Given Rosetta is nothing more than an emulator for depreciated code (i.e. nothing that runs under it needs anything newer than Leopard to function at most), it seems like if it had its own little contained environment, it shouldn't really care what version of OSX it's running under. But I'm guessing the difference between it and say a Commodore 64 emulator is that it might need parts of the operating system that have since been replaced with newer code that will not support the functions needed. However, if Apple could set Rosetta to run in a self-contained environment within OSX (and use those libraries, etc. instead), shouldn't it then work in any future OSX variant assuming the primary Intel emulator binary can run in that OS version (i.e. itself being Intel code)? I really don't know how Rosetta is set up and what it needs to function exactly, so pardon my ignorance. It's why I'm asking.

 

[iEdd]

Magnus, that's how I thought Rosetta worked, but after a lot of the posts here, I'm not so sure...

If there is a way to run it self-contained (and it wasn't already), some clever cookie will do it and Lion will have Rosetta within a week of release.

 

[briloronmacrumo]

For more sophisticated apps that internally launch other application, though, you need to tell the OS about those interactions.

I'm not sure what "you need to tell the OS about those interactions" means. Launching another app, whether it is in the bundle of the current app, or installed elsewhere is just a matter of getting a reference to it ( such as CFURLRef ) and calling the framework ( either Carbon or Cocoa ) call for Launch Services ( such as LSOpenCFURLRef() in Carbon). Mac App Store apps must have everything in one bundle and that has meant re-engineering for some developers. Inter-process communication is typically handled at runtime by the applications but not at install time. Anyway, I'm not disputing some installations are complex but launching other applications is not ( or does not have to be ) as complex as the quote suggests.

 

[AidenShaw]

I am the default MP4 player

I'm not sure what "you need to tell the OS about those interactions" means. Launching another app, whether it is in the bundle of the current app, or installed elsewhere is just a matter of getting a reference to it ( such as CFURLRef ) and calling the framework ( either Carbon or Cocoa ) call for Launch Services ( such as LSOpenCFURLRef() in Carbon). Mac App Store apps must have everything in one bundle and that has meant re-engineering for some developers. Inter-process communication is typically handled at runtime by the applications but not at install time. Anyway, I'm not disputing some installations are complex but launching other applications is not ( or does not have to be ) as complex as the quote suggests.

You describe a very simple, static case where app A knows to launch app B to do something.

In a more realistic scenario, app A knows nothing about app B. When app B is installed, it registers with the OS to say that "I am an MP4 player". That registration may or may not include a flag that "I am the default MP4 player".

Later, when app A wants to launch an MP4 window - it does *not* launch "app B". It asks the OS to launch the default MP4 player. It does not know or care which application plays the video.

 

[briloronmacrumo]

... because when a PPC application is run, Rosetta pulls in the PPC code from the various libraries the said application relies on and then translates it on the fly.

Correct. Those "libraries" are the frameworks( i.e. appkit, carbon, etc. ). If those frameworks aren't compiled with PowerPC code ( which presumably is Apple's plan ), Rosetta would have nothing to translate.

 

[briloronmacrumo]

You describe a very simple, static case where app A knows to launch app B to do something.

In a more realistic scenario, app A knows nothing about app B. When app B is installed, it registers with the OS to say that "I am an MP4 player". That registration may or may not include a flag that "I am the default MP4 player".

Later, when app A wants to launch an MP4 window - it does *not* launch "app B". It asks the OS to launch the default MP4 player. It does not know or care which application plays the video.

Are you a developer? Those are very general statements about how inter-process communication works. That might be what the user perceives but it isn't how it works at a lower level.

 

[AidenShaw]

Are you a developer? Those are very general statements about how inter-process communication works. That might be what the user perceives but it isn't how it works at a lower level.

This isn't IPC.

It's one application registering itself with the OS as a provider of (a) particular service(s), for example playing MP4 files.

When a second application needs a service (for example, playing an MP4 file), it doesn't do an IPC to some executable (which in fact may not be running, so an IPC would be quite useless). It asks the OS to launch whatever app is registered with the system as the default MP4 player.

There may be IPCs involved behind the scenes, but app 2 might not even know anything about app 1.

The link is that when app 1 was installed, app 1 told the system that it was to be the default MP4 player. App 2 talks to the OS, not to app 1.

 

[AnonMac50]

Nobody forces you to upgrade, and SL won't magically stop working either.
So much whining.

No one ever said Snow Leopard will stop working. Unless 10.7 final returns Rosetta, I sure am keeping my Snow Leopard. As for upgrading, when Apple refuses to let you run any new programs, saying your computer is unsupported with this OS anymore, and want you to update so that they can repair your computer, yeah, no one is forcing me to upgrade :sarcasm:

 

[kingtj]

re: forced upgrades

Well, to be fair, what computer/OS/application model do you know of where you're NOT "forced to upgrade" every so often? Companies writing these operating systems or applications can't just publish a product once and sit back collecting endless revenue forever on it.

The bottom line really is: As long as you're able to keep a given piece of hardware operating, you can continue using all the programs you have installed on it for as long as you like. However, no, you won't have any guarantee that new versions of those programs will still work ok for you without upgrading everything else.

A year or two ago, I had a client who asked me if I could either get an ancient Epson dot-matrix printer of his repaired, or find him a 100% compatible replacement. I wondered why until I found out he still ran his little shop entirely on Lotus 1-2-3 and WordPerfect under MS-DOS! The printer drivers supported his Epson dot-matrix printer but they (obviously) had no support for many modern inkjet printers, or even non-Postscript compatible laser printers. He was still using an OLD PC, too, backing up data onto floppy disks -- and for him? It was all he wanted/needed. He was an older guy and had no interest in learning a whole new operating system and buying/learning all new software, plus hassles migrating data from the floppies to another format of media, etc. etc.

Apple moves faster with obsoleting old stuff than Microsoft does, but that's also one of the reasons their products run as well as they do. They don't get too bogged down with code that tries to retain "backwards compatibility".

Arguably, sure -- Apple could just keep Rosetta in 10.7. But who knows if that creates extra work for parts of their development team who want to do new things inside OS X that are restricted by making sure Rosetta keeps working 100% properly? Rosetta is really just a band-aid or "bridge" that makes some code work that isn't really supposed to work anymore with the current OS otherwise. Bridges like that always go away sooner vs. later in Apple's world.

No one ever said Snow Leopard will stop working. Unless 10.7 final returns Rosetta, I sure am keeping my Snow Leopard. As for upgrading, when Apple refuses to let you run any new programs, saying your computer is unsupported with this OS anymore, and want you to update so that they can repair your computer, yeah, no one is forcing me to upgrade :sarcasm:

 

[MagnusVonMagnum]

Arguably, sure -- Apple could just keep Rosetta in 10.7. But who knows if that creates extra work for parts of their development team who want to do new things inside OS X that are restricted by making sure Rosetta keeps working 100% properly?

The argument falls completely and utterly flat given Apple's net revenue. Apple could easily afford to hire enough workers to make 10 operating systems viable (and help the economy at the same time). They certainly have demonstrated that they are wholly incapable of keeping OSX up-to-date while working on iOS, causing either or both to suffer as a result. This is purely caused by Steve's psychological problems talked about several months ago where he feels the need to keep a small group and tight control over everything rather than delegating more responsibility to other people so that multi-tasking becomes possible rather than Apple's narrow focus on one item at a time which causes other items to fall behind (e.g. the huge lag in Mac Pro updates, actual useful OSX features, etc.)