5 ms·

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 t

by angusgr 16y ago

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.

texel 16y ago
Not only that, but they have a pretty consistent system of deprecating then dropping outdated APIs, at least in Cocoa.
wvenable 16y ago
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.
- angusgr 16y ago
  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. I guess it's not as simple as that, though.
brudgers 16y ago
> "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.
- angusgr 16y ago
  With Vista, 16bit code was broken (ie some Win9x and WinMe). This is the thing, though: it took until 2007 to break support for code written as far back as 1993. Microsoft allows Windows to run in virtual machines To me, this definitely seems like a smart strategy.
  - brudgers 16y ago
    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.
wazoox 16y ago
> 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.

by angusgr 16y ago

texel 16y ago

Not only that, but they have a pretty consistent system of deprecating then dropping outdated APIs, at least in Cocoa.

wvenable 16y ago

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.

angusgr 16y ago
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. I guess it's not as simple as that, though.

brudgers 16y ago

> "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.

angusgr 16y ago
With Vista, 16bit code was broken (ie some Win9x and WinMe). This is the thing, though: it took until 2007 to break support for code written as far back as 1993. Microsoft allows Windows to run in virtual machines To me, this definitely seems like a smart strategy.
- brudgers 16y ago
  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.

wazoox 16y ago

> 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.