The burden of the past isn't really as big as he makes it out to be.
Apple made Rosetta to run older apps and Windows 7 includes Windows XP in a virtual machine in business SKUs.
Also, Intel chips haven't really implemented x86 instructions for a very long time. Most of the chip runs micro-instructions that are derived for a x86 to micro-instruction translation layer.
Apple hasn't just done Rosetta, they have a consistent pattern for "the burden of the past". A new technology bridges back to the old architecture or API, and then cuts it off after a transition period:
Universal Intel & PowerPC binaries
Carbon & "Classic mode" on OS X
Fat Binaries (68k & PowerPC)
AFAIK Microsoft only really adopted this approach more recently, in the Windows 7 tech you mention. Prior to Windows 7 you had the backwards-compatibility burden sometimes running all the way back to Windows 95, maybe even Windows 3.1+Win32s.
The Windows XP for Windows 7 isn't even really required -- Windows 7 will still happily run most Windows 95 applications and even 3.1 apps (if not running 64bit).
I think if Microsoft mostly targeted consumers, rather than businesses, they would take the same approach to compatibility as Apple. But a large amount of Windows sales results from selling to corporations that have hundreds of critical legacy applications. They simply won't upgrade if their apps won't run. However, on my desktop, I doubt I'm running a single application that's more than 3 years old.
I see, thanks. It always seemed odd to me that they took that approach to solve the problem. Simply because so many minor tweaks to APIs do cause problems with old apps, or cause massive headaches when various quirks have to be maintained for decades.
Whereas a "Classic mode", "WINE", or "Virtual Machine" style mode would seem to solve the backwards compatibility thing in a much more containable way - apps still run, the old APIs stay frozen in the custom environment but deprecated/removed outside, new developments can use new APIs without being saddled with the old.
Even though the compatibility environments have to be kept around forever, now you've only got a few API interfaces to renovate (connecting the classic environments to whatever new Windows APIs exist), instead of thousands.
> "Microsoft only really adopted this approach more recently"
Microsoft shifted away from backwards compatibility with Windows XP Professional x64 (ok actually the Itanium version). With Vista, 16bit code was broken (ie some Win9x and WinMe).
Microsoft's current approach to backward compatibility is radically different from Apple's. Microsoft allows Windows to run in virtual machines. If you want to run Windows 95, just fire up your favorite virtual machine (Virtual PC, VMware, etc), create a machine, and load Win95 from your CD.
Microsoft released the first version of Virtual PC several years ago at no cost. It runs under all versions of XP, Vista, and Seven. Windows Seven Professional includes a built in copy along with XP so that an existing licensed copy of XP isn't required.
Microsoft had broken 16bit code earlier with their 64bit implementations of Windows XP, even though the effects were not wide spread and were unfelt at the consumer level. For the consumer, the biggest effect of breaking 16bit code was with hardware drivers. The long cycle was largely due to the development of NT for commercial use with the intent of long support.
Allowing virtualization is very much a customer focused strategy, but one which Apple deliberately avoids at the consumer level with OSX. It doesn't help them in their core business of selling branded hardware with a three year support lifecycle.
What hasn't been explored is virtualization as a high level organizational feature of a desktop operating system. I currently reference a legacy application which relies on 16bit code. Running it in a virtual machine is fabulous because I can save the state and come back to the exactly the same point two months later.
I have another VM which runs Ubuntu. I used it to sign up for Facebook and that's all I use it for. It appears to sidestep the commercial byproducts of Facebook use.
> Microsoft had broken 16bit code earlier with their 64bit implementations of Windows XP
It's AMD/Intel that has broken 16bit compatibility with 64bit, not Microsoft. If you put your CPU in 64bit mode, it will no longer be able to run 16bit code.
> the backwards-compatibility burden sometimes running all
> the way back to Windows 95, maybe even Windows 3.1+Win32s.
Chen's wonderful blog (the Old New Thing) talks about this, like the backward compatibility hack in windows 95 to support BUGS in 3d party DOS/win3.1 programs like Lotus 1-2-3 or SimCity. No doubt many of those hacks have been ported to following windows versions.
Apple made Rosetta to run older apps and Windows 7 includes Windows XP in a virtual machine in business SKUs.
Also, Intel chips haven't really implemented x86 instructions for a very long time. Most of the chip runs micro-instructions that are derived for a x86 to micro-instruction translation layer.