Journal LehiNephi's Journal: Did Microsoft miss their big chance to improve Windows? 1
As I sat on an early-morning flight this morning, I started thinking about the difficulties Microsoft is facing in encouraging adoption of Vista. I thought about all the big complaints I have read, and then it hit me:
Why don't Microsoft follow Apple's lead and build the next version of Windows on a BSD foundation?
Now, I've only toyed with Vista a little bit while browsing through the local Fry's and fiddling with friends' computers, I've gotten a fair impression of what it's like from a User's perspective. And it seems to me that for billions of dollars worth of investment, there's not much from a user's POV that drives sales. Sure, it might be a little more secure under the hood, and the driver model is new, but neither of those affects (or should affect) the user experience. Yeah, there's some eye candy, but certainly nothing to justify the amount of development. And now we have a whole mountain of relatively new code in which to find bugs and security vulnerabilities.
Now let's do a bit of speculation. What if Microsoft had built Vista on a BSD core? Well, on the good side, they would start off with mature, complete, pretty-darn-secure code, which would save them an enormous amount of time and money. It would also have improved compatibility and interoperability with the rest of the world, although the cynic in me would say that this would act as a reason for Microsoft not to do it. Also on the minus side side we have application incompatibility. Microsoft, however, is a Grand High Master at handling this problem. In addition, most programs (setting aside games for now) work pretty well in Wine. Microsoft could even create an API analogous to Apple's Carbon to allow developers to easily write code for the old and new versions of Windows.
What about hardware? Well, considering the paucity of drivers at Vista's release, and considering the fact that most common hardware actually work out of the box under Linux, I don't think this one is as large an issue as it initially appears, even if much of the code is written by independent developers.
Now, of course there are other "soft" issues that would follow such a transition. First of all, there's a whole ecosystem of developers who know how to code for Windows but not for anything else. This includes pretty much all of Microsoft. Consider this, though: there were six years between the release of XP and Vista. How long do you think an experienced Windows programmer would take to become competent at writing code for a BSD-based OS? Would a year of full-time training and practice be enough? Two years? And if the remaining four (or five) years were spent on writing the new version of Windows, would it be enough?
One could certainly write a book on this subject, and I've only scratched the surface, but there's one point I'd like to put forth. What about this: write the next version of Windows on a BSD core, and run every single old application in an emulator, or on a compatibility layer, or something similar. It may seem drastic, but here's my thought: breaking backwards compatibility can be a good thing. I've heard stories upon stories of patches, quirks in windows, extra execution paths, and special application-detecting code that have made their way into the windows codebase in order to ,a href="http://dansdata.com/gz070.htm">make a specific, single application run right. Break the yoke of backwards-compatibility and make it all run in its own space, and let Windows be an OS and window manager.
Before I get off rambling, I'll end it here. Comments?
Why don't Microsoft follow Apple's lead and build the next version of Windows on a BSD foundation?
Now, I've only toyed with Vista a little bit while browsing through the local Fry's and fiddling with friends' computers, I've gotten a fair impression of what it's like from a User's perspective. And it seems to me that for billions of dollars worth of investment, there's not much from a user's POV that drives sales. Sure, it might be a little more secure under the hood, and the driver model is new, but neither of those affects (or should affect) the user experience. Yeah, there's some eye candy, but certainly nothing to justify the amount of development. And now we have a whole mountain of relatively new code in which to find bugs and security vulnerabilities.
Now let's do a bit of speculation. What if Microsoft had built Vista on a BSD core? Well, on the good side, they would start off with mature, complete, pretty-darn-secure code, which would save them an enormous amount of time and money. It would also have improved compatibility and interoperability with the rest of the world, although the cynic in me would say that this would act as a reason for Microsoft not to do it. Also on the minus side side we have application incompatibility. Microsoft, however, is a Grand High Master at handling this problem. In addition, most programs (setting aside games for now) work pretty well in Wine. Microsoft could even create an API analogous to Apple's Carbon to allow developers to easily write code for the old and new versions of Windows.
What about hardware? Well, considering the paucity of drivers at Vista's release, and considering the fact that most common hardware actually work out of the box under Linux, I don't think this one is as large an issue as it initially appears, even if much of the code is written by independent developers.
Now, of course there are other "soft" issues that would follow such a transition. First of all, there's a whole ecosystem of developers who know how to code for Windows but not for anything else. This includes pretty much all of Microsoft. Consider this, though: there were six years between the release of XP and Vista. How long do you think an experienced Windows programmer would take to become competent at writing code for a BSD-based OS? Would a year of full-time training and practice be enough? Two years? And if the remaining four (or five) years were spent on writing the new version of Windows, would it be enough?
One could certainly write a book on this subject, and I've only scratched the surface, but there's one point I'd like to put forth. What about this: write the next version of Windows on a BSD core, and run every single old application in an emulator, or on a compatibility layer, or something similar. It may seem drastic, but here's my thought: breaking backwards compatibility can be a good thing. I've heard stories upon stories of patches, quirks in windows, extra execution paths, and special application-detecting code that have made their way into the windows codebase in order to
Before I get off rambling, I'll end it here. Comments?
Simple Answer: Loss of control (Score:1)
This would never happen for one simple reason: control. Secret API's have been one of Microsoft's principle trump cards since the beginning. It is the reason that their benchmarks on Windows compete with other vendors. Other vendors have to code to the published Win32 API's that run on top of the ntdll.dll while Microsoft can code their products directly to the unpublished NT kernel interface. They literally can control the desired performance difference into ntdll.dll exactly when, where, and how they want