@Jon Galloway: I repeatedly hear the argument that Vista was delayed because of backwards compatibility constraints. Far from it. The problem was in the other direction: that various teams in user mode were trying to write their new components (e.g. Explorer, Sidebar) on top of Avalon, which was in itself on top of .NET 2.0. These components were never stable enough to know whether a bug was in your code or in your dependencies. Eventually a halt was called to this morass of shifting sands. This isn’t a reflection on the quality of .NET at all - just that trying to develop on top of a developing runtime is practically impossible. Microsoft may use new C++ compilers with new releases of Windows, but they’ve got literally twenty years of working code in there and can revert to an older version if there’s a problem.
In the two years since then, they’ve tried to get what features they can implemented on top of the old Win32 API so they have something to ship.
Vista may have been a five-year project but three of those years were largely wasted. Some components, particularly the kernel, had few dependencies and could be accepted straight into the new source tree, so do have effectively five years of development in them over Windows XP.
I recall reading this from Larry Osterman (http://blogs.msdn.com/larryosterman/) but can’t find a link. Larry mentions the ‘Longhorn reset’ in this article: http://blogs.msdn.com/larryosterman/archive/2005/08/23/455193.aspx. Unfortunately he doesn’t go into details. It’s possible he actually mentioned it on the Channel 9 forums: good luck finding it over there.
I cannot imagine the amount of engineering required to completely throw away Windows and start again, and to do so would be foolish in the extreme. In a much smaller way, throwing away FogBugz would be pretty silly too. BTW, it’s not ‘six-year-old VBScript code’. Some of it would be six years old at the time of making the decision, but you probably couldn’t point to any section and say, ‘that’s six years old.’ Instead, a lot of it would have been edited recently to support new features. It would be six years of working around bugs and implementing new requirements.
If you have code that works for a particular scenario, you keep it. Throwing it away loses you years of development time with no guarantee that you will not incur the same bugs and workarounds that you had to deal with last time.
I have an eight-year-old codebase in Visual Basic 6.0, and it’s starting to hit the limits of scalability (the lack of multithreading in a standalone EXE is starting to hurt). I don’t envision writing a VB6 compiler as I’d hit those same limits - and I don’t have even Joel’s resources. This probably has hit time for a rewrite, as what I can do by extending it with C++ COM components is pretty limited. I’m going to have to be very careful not to introduce more problems than I fix.