10.7 Lion drops support for PowerPC applications
9to5mac.com
9to5mac.com
Windows is a pain to program for and use largely because it's filled with assumptions and code that date back to the eighties. It is very difficult to innovate with the boat anchor of the past shackled to your ankle.
Think how much easier it would be for Microsoft to improve security if, for example, they could remove the assumption that it's okay for apps to blithely write stuff to the \Windows directory. Well, Mac OS X has done exactly that. Most of its system directories are tightly locked down.
In fact, Apple has completely chucked their entire operating system from the eighties and started over. The result is a much more modern OS that is far more pleasant to use. Yes, there was a real fear there that, since people had to chuck OS9, they might move to something else entirely, but that didn't happen, for the most part.
Think about it this way. Which customers would you rather have: the people who are willing to buy new computers and software every few years, or the guy who is stubbornly holding on to his DBASE app from 1984? For me, the choice is obvious.
There was one fellow who hemmed and hawed at having to use Windows 2000. He wanted to stick with Windows 95. He ended up migrated, but he spent a furious amount of time getting the Windows 3.1 File Manager working. Apparently on his Windows 95 laptop he had brought it over as well.
He also was using a release of SideKick from 1992.
-----
How is this relevant? I recently talked to someone who does provide IT support for that same company. That same person? Still running SideKick. Still complains about not having File Manager. Also is hemming and hawing about having to upgrade from Windows XP to Windows 7.
Company is also still on 10Mbps networking. The owner still refuses to use copper, since they're a fiber optic distributor (multimode fiber is run to each and every desk).
* 'Classic' support enabled Mac OS 9 apps to run on OS X for many years.
* Rosetta allowed for apps written for a completely different processor architecture to run on Intel (until 10.7, aparently).
Apple also made these moves before the bulk of 3rd-party applications were running natively on the new systems/architectures. The fact that Apple has been able to change low-level OS & processor architectures over the past 10 years is quite a feat.
Product quality tends to degrade (sometimes significantly) because more often than not it's necessary to compromise design, which in turn complicates code and causes more bugs. It has an engineering cost because it takes longer to develop the product. And perhaps most importantly, it can severely restrict how aggressively you can push your platform forward in each new version.
Having the freedom to move OS X (and iOS) forward aggressively is an important reason why Apple focuses its business model on selling products to consumers. Consumers tend to be looking for the latest and greatest, and each individual consumer makes her own buying decision. On the other hand, if an IT manager can't keep his VB6 internal clunkware running on your new OS, he's not going to buy 10,000 seats.
That said:
Microsoft's backwards-compatibility policies are great for businesses, who naturally have many special considerations when it comes to legacy applications.
Apple's policies, on the other hand, seem to be more geared towards improving the experience for the user. They deprecate libraries and functions of the OS that are no longer relevant to how computing gets done (or how they want it to get done) on the Mac. This helps to ensure that applications keep up with the times.
Microsoft don't have this philosophy at all, and so Windows 7 often feels like an arbitrary mash-up of the last 25 years of PC operating systems. There are many many applications in W7, for example, where buttons and interface elements still have a Windows 95-ish feel to them, because they haven't been updated to the new system themes. A famous example in Vista (corrected now in W7) was the 'Add Font' dialogue, which had been exactly the same since Windows 3.1. Another example is mIRC, where (if i remember right) some decades-old Unicode work-around forces the application to use non-Aero title bars.
At the risk of sounding like a snob, the whole experience -- to a consumer who appreciates good user interfaces -- just feels kind of amateur-ish, really.
I'm not sure where Apple got this reputation for poor backward compatibility. They've jumped platforms multiple times and have gone to heroic lengths to preserve backward compatibility as well as cross-platform and cross-architecture compatibility.
That said, the removal of Rosetta support seems uncharacteristically premature for Apple.
Apple does go through heroic lengths to preserve backward compatibility, but only for as long as it makes sense. If the backwards compatibility is going to harm moving the OS forward, then they are prepared to drop it, as in this case. Microsoft has always been too afraid to drop backwards compatibility (mostly because as soon as they do, many users will probably jump switch to Mac OS if they are forced to upgrade everything anyway), forcing them to remain stuck with legacy Windows code while Apple has continued to push forward. The jump from Mac OS 9 to OS X was a huge one that Microsoft still hasn't been able to take, even with Windows 7.
Hardly. They could easily provide backward compatibility if desktop versions of OSX were easily virtualized and doing so officialy supported - which is the primary route by which Microsoft has provided backward compatibility (i.e code dependent on 16 bit libraries under x64 and legacy applications under Vista and 7).
Microsoft in Windows 7 for legacy applications allow the users to select a target OS, at that point it is not virtualising that OS but having certain system calls act like they would in those older versions of Windows. As far as I am aware as a developer nothing gets "virtualised", it is a compatibility shim. See this wikipedia article:
http://en.wikipedia.org/wiki/Windows_on_Windows
This is how Windows provided support for 16 bit on Windows 32 bit, and how Windows provides support for 32 bit on Windows 64. Clever piece of code.
What you are suggesting is almost impossible on Mac OS X without also emulating an entire different instruction set ALA qemu. Running OS9 on x86 just isn't in the cards, Rosetta provided support for PowerPC on x86, and Apple apparently has looked at the download stats for Rosetta and figured it was time to let it go. Most apps have been PowerPC + Intel for a long time now.
Sure, any ARM NetBook or tablet. But they're fixing that.
Apple is sliding forward the lower bound on software that can be expected to run on a newly-purchased computer by several years. There's no indication to the average user which of their applications will stop working on their next computer, and there are oodles of copies of PowerPC applications out there in the wild.
You should better whish for your employer to switch to something that can be readily used with onboard methods.
For what it's worth, the website (www.derlien.com) for this project still calls the universal binary version "beta," but it's been that way since 2006 and has worked just fine.
2) compiled AppleScript scripts - a certain number of those were compiled, and generated PPC binaries, and not UB. beware.
2) Applescripts do not compile to machine code.
Combine that with requiring CS5, and Lion will be a very expensive upgrade for many people.
http://en.wikipedia.org/wiki/Microsoft_Office_2008_for_Mac#R...
If you didn't use Terminal to install Office, then you must have either upgraded Snow Leopard instead of doing a clean install, which would allow you to use Office without running the installer again, or you have Rosetta installed without realizing it.
I wonder though, if Apple were to transition to their A4 chips for Macbooks whether we'll see Rosetta come back in an ARM compatible flavour.
I wish it were possible that we could say goodbye to Rosetta and Universals Binaries yesterday. However, there are a good number of "Universal" pieces of software out there in common use, that have vestigial PowerPC components. I just ran into one yesterday, on a business critical piece of software at my company - supposedly UB software, that has a command-line utility that is compiled for PowerPC, and that in the most current version of the software. Quite a number of times, I have run into software that is UB, and yet part of the install process relies on Rosetta.
Oh, and I have to run Acrobat 7 for a couple business-critical websites, because we make templates using an old build of PDFLib, and since it's legacy software, we won't be upgrading to a newer build.
I believe I will have to setup an instance of Snow Leopard in Parallels, if I move to Lion.
Well, I don't fault Apple for this. Perhaps it will force this nonsense to stop sooner than later.
Other OS vendors can carry decades of cruft and baggage for reasons of compatibility with older applications, and that really slows down development, and the testing costs scale upward for whatever you can't retire. You end up implementing the Windows XP box in Windows 7, the pain that has been IE6 replacements and upgrades, and various other forms of API and run-time and source-code compatibility, and translators.
Some of this zombie software lives on ten and twenty years past expectations, and longer.
Apple throws features and hardware under the bus when it gets in the way of their skating to where they think the puck will be.
On the other hand, 10.5 runs fine on ppc. As a poster above noted, your old OS does not magically stop working after release of new version.
My Dell netbook is still running 10.6 because 10.6.2 broke support for Atom processors. Yeah, it's annoying not to have the latest version of 10.6, but 10.6 still works.
You could be worried about developers creating intel-only apps, which you won't be able to run, but that already happens on a big scale because almost nobody uses PPC macs anymore. This has nothing to do with Lion.
The bigger problem with Lion may be the dropping of 32-bit macs. Most people don't really know if their mac is 64-bit (Core 2 and up) or 32-bit only (Intel Core's, which is mostly the early Mac Mini's, iMacs and Macbooks I think). It's good for developers who want to write 64-bit only apps though, because once Lion has been adopted and SL support is dropped, they can just say 'Requires Lion', instead of the somewhat awkward 'Requires Snow Leopard on a 64-bit Mac' right now.