> And then isn't there some lore about the reason Windows Vista took so long to release was due to them trying to write the entire OS in C# or something and then having to redo everything?
It seems like you're confusing a few different things there.
The 'redo' step that you're talking about happened because in the early 2000s Microsoft was getting blasted by security breaches left and right.
Pretty much every senior developer in the Windows org was pulled to work on security patches. An in between update to the consumer version of Windows (codename Longhorn) was planned to hold customers over until the team had the time to do a proper iteration on the next OS.
As the senior devs were wrapping up their security fixes and coming back to see about shipping Longhorn they decided that it wasn't up to their standards and more importantly they didn't think it was moving in the right direction because it didn't include all the security fixes they had been doing.
Longhorn had essentially 'forked' XP pre-security fix and it was decided that it would be easier to throw out all of the Longhorn code and start fresh then to try and port all the security fixes over.
So they just that: they threw out everything that had been worked on, 'reset' the project to be based on the latest code with all the security fixes present, and then started the development of Vista fresh.
What you are talking about was called the Windows Security Push and this is how it worked. Basically, every developer (not just the senior ones) had to help review every line of code in Windows. First, we were shown presentations which explained why security was important, where Microsoft products had failings, what were common security bugs and how to look for them. I think the presentations were done my Michael Howard. They were very good.
Then we were given a copy of Writing Secure Code to read. It enumerated all of the know types of security vulnerabilities and told us how to fix them. It also taught us how to write a threat model, validate input from untrusted sources, reduce our attack surface, use the principal of least privilege, etc.
Finally, we spent three months reviewing Vista's code. Each team was responsible for reviewing its own code. We filed bugs as we found them and then they were fixed.
Note that porting the security fixes to Longhorn from Windows XP took very little work. Windows had one code base and you could move changes from release A to release B (Windows XP and Windows Vista in this case).
Also, Longhorn was reset at some point but all of the work was not thrown out. Basically, some teams reduce the scope of their work (i.e. cut features) and some projects were cancelled. The reset did not occur because the security fixes were missing. It ocucred because Longhorn was an out of control project which had been going on for 2 to 3 years and was not close to shipping.
> Longhorn had essentially 'forked' XP pre-security fix and it was decided that it would be easier to throw out all of the Longhorn code and start fresh then to try and port all the security fixes over.
Microsoft internal emails from Jim Allchin (who ran Windows at the time) to Bill Gates reveal that the issue was performance.
> LH is a pig and I don’t see any solution to this problem.
Eventually, the solution was to drop the use of a garbage collected runtime (desired for memory safety) and go back to C/C++ (necessary for performance).
Now they are moving to a language that gives you the memory safety without taking the performance hit.
Longhorn was slow but I doubt garbage collection was the main cause for its poor performance. First, it was mostly written in C and C++ (remember, Microsoft does not rewrite Windows, it evolves it). Second, the reason it was slow was some teams checked in code which was not ready. What I mean is the code was buggy, had exceptionally poor performance, etc. The code should never have been shared with the entire Windows organization.
Note teams could have private source code repositories and Windows builds. Changes did not have to be shared with the entire Windows team. The better teams shared their changes when they worked and were ready. On Vista, a lot of teams shared things which were far from ready. Note that this was unusual and did not happen on Windows XP.
> Longhorn was slow but I doubt garbage collection was the main cause for its poor performance.
Longhorn was refereed to as Cairo.net, as a callback to a previous Cairo project from the 90's that failed to ship and as a reference the drive to improve security through the use of memory safe garbage collected code.
I never heard that term internally (it's possible it was used in some parts of the organization, but it was not used in my part). I know some new APIs used .NET and I suspect that there were some apps which used .NET/C#, VB, etc. However, I do not think that accounted for the performance problems or the massive increase in memory use (from about 128 mb to 1-2 GB).
If you are going to claim garbage collection caused performance problems, you need to state what part of the operating system used .NET or GC and why using those technologies caused problems.
> I suspect that there were some apps which used .NET/C#
Several of the tentpole features of Longhorn were based on .NET and managed code.
> First and foremost, while Windows Server 2003™ embraced managed code by being the first operating system to ship with the .NET Framework preinstalled, Longhorn is the first operating system whose major new features are actually based on the .NET Framework.
... Microsoft appears to have concentrated their development effort in Vista on native code development. In contrast to PDC03LH, Vista has no services implemented in .NET and Windows Explorer does not host the runtime, which means that the Vista desktop shell is not based on the .NET runtime. The only conclusion that can be made from these results is that between PDC 2003 and the release of Vista Beta 1 Microsoft has decided that it is better to use native code for the operating system, than to use the .NET framework.
It seems like you're confusing a few different things there.
The 'redo' step that you're talking about happened because in the early 2000s Microsoft was getting blasted by security breaches left and right.
Pretty much every senior developer in the Windows org was pulled to work on security patches. An in between update to the consumer version of Windows (codename Longhorn) was planned to hold customers over until the team had the time to do a proper iteration on the next OS.
As the senior devs were wrapping up their security fixes and coming back to see about shipping Longhorn they decided that it wasn't up to their standards and more importantly they didn't think it was moving in the right direction because it didn't include all the security fixes they had been doing.
Longhorn had essentially 'forked' XP pre-security fix and it was decided that it would be easier to throw out all of the Longhorn code and start fresh then to try and port all the security fixes over.
So they just that: they threw out everything that had been worked on, 'reset' the project to be based on the latest code with all the security fixes present, and then started the development of Vista fresh.