The Backwards Compatibility Jenga Tower
How many layers of software are currently between your latest app and the hardware it runs on? Let's count, making an assumption you're using Silverlight. (If you're using Java, WinForms, or anything else, you may not start out in the same place, but your stack will look just as disgusting.)
- Silverlight
- Internet Explorer
- .Net Framework/COM
- Windows Kernel/Win32 API
- BIOS, Intel's segment/offset memory, and "AMD x64" emulation
The Attempted Solutions
Solving this problem has been tried before, of course, at many different levels. The .Net Framework is intended to replace COM... yet COM lives on. RISC processors from Motorola et al, and Intel's Itanium "real" 64-bitness tried to change the foundation, but those are virtually dead. We've seen the claims that taking a different architecture from the bottom would cut a lot of fat out of the middle and allow that tower to be streamlined and double, triple, or quadruple effective FLOPS.
Why didn't those attempts work? Some, like .Net, won't truly "work" because they can't automatically upgrade older apps that use COM - COM is still required, which means all it's lower layers are required. .Net may streamline that "layer" while providing more flexibility and usability, but it cut out the requirement to still have COM in Windows. Rearchitecting the lower layers (chipset) failed miserably because it shook the very foundation of the tower, causing ripples of instability in "ported" OSes and applications, and lack of availability of drivers and compatible apps. Enterprises don't deal well with instability, or systems with one-dimensional support.
So We've Stuck With This Sh*t?
I'm hoping not. Virtualization technology could be the way out. Up to now, it's been used to consolidate servers, and run "old" OSes that may not accomodate newer hardware advancements.
What I'm looking forward to is what I see as the inevitable conclusion to this trend that "XP Mode" seems to be the first step of. Wouldn't it be great if Microsoft could cut the Win32 API and COM entirely out of Windows? At the same time, they'd have to rework the .Net Framework to plumb deeper/closer to the hardware. But wait, doesn't that put us in the same place as prior failed attempts, screaming coming from enterprises that run ten year old software? Not with seamless virtualization, it doesn't. If Microsoft can get that "seamless" part right - and that why I'm sure it will take a couple versions - then an "old" application requiring COM running on Windows 8+ that doesn't have it will simply start up a virtual host with a Windows OS that does. Sure, we've just added (at least) one more layer that old application has to fight through to perform - but we're seeing results today where the virtualization layer isn't that onerous a burden, and there's always the continuous progress on the hardware side that should more than make up for the added fat. (And who needs great performance from old apps? Rewrite them if you do! :P)
I See a Win/Win/Win Situation
If Microsoft can pull that off, they suddenly open the door for much faster current generation applications that use the best framework/interface/whathaveyou that Microsoft's put in Windows for us to use. And they've guaranteed backwards compatibility for old apps until virtually forever, and given themselves an upgrade path for radical reworking of those layers in the future.
If Microsoft can demonstrate this new "backwards compatibility" architecture as reliable and relatively efficient, they'll get plenty of buy in and interest from other "layers" in the computing supply chain. They'll be able to work with the motherboard/chip manufacturers to rework those layers to benefit the "new", while only having to "maintain" backwards compatibility for one application - virtualization.
What do you think?
No comments:
Post a Comment