WinSuperSite has the first two of a three part series of articles looking at the internal workings of the Windows development/build/ship process. Part One: The Early Years looks a the history of Windows NT, while Part Two: Developing Windows looks at the current build and “War Room” process.
“There are no other software projects like this,” Lucovsky said, “but the one thing that’s remained constant [over the years] is how long it takes to build [Windows]. No matter which generation of the product, it takes 12 hours to compile and link the system.” Even with the increase in processing horsepower over the years, Windows has grown to match, and the development process has become far more sophisticated, so that Microsoft does more code analysis as part of the daily build.
Interesting reading, but one quote I found interesting was…
On the day I attended, one feature group had four of its bugs punted to Longhorn because they had failed to shown up for War Room. When someone argued that they should be given another day, Wanke simply said, “F#$% ‘em. If it was that important, they would have been here. It’s in Longhorn. Next bug.”
They’re seriously taking bugs and punting them back to Longhorn (next version of Windows)?? Punt it to SP1 maybe, but the next version? Which perhaps makes sense in the when you consider this quote (from a different section of th article)…
customers made it clear that they wanted bug fixes only [in service packs]. That leads to an interesting question, though: What, exactly, is a bug? Is a missing feature a bug?
Deliberately excluding a minor deature, or punting it to the next version might be acceptable, but punting real bugs?
Freedom.org has a good collection of resources on the SQL Server worm which is currently circulating.
CERT has a KB article on the vulnerability it uses to spread. EEye Security has a short explanation of how it works, and the disassembled code.
Gert Lombard offers some advice on how to Secure VNC project on SourceForge but despite the “heavy development for the next 2-3 months” promise, there’s been no activity in 18 months.
If we had an encrypted VNC we’d use it for remote support at work and ditch our current commercial product.
MSKB article describing a fix for the VB6 SendKeys problems we’ve encountered at times.
In The .NET Guy comments on Cringley’s idea of building Windows on top of Linux.
Robert X. Cringley chimes in with his thoughts on why Microsoft should build Windows on top of Linux. Specifically, this quote caught my attention:
Now back to Microsoft putting Windows on top of Linux. Linux is better, faster, stronger than whatever is living underneath XP now, right? Performance would improve.
Eh, I don’t buy it. The Windows kernel is a highly tuned machine. The performance differences at the kernel level would favor, if anything, Microsoft. Besides which, they’d likely choose one of the BSD variants. 
Nobody (sane) likes the GPL.
The Windows kernel is pretty good at what it does, recent comparisons by IBM developerWorks actually showed Windows was faster for some operations, so I doubt there’d be a major performance difference there.
I’m not sure there’d be a stability gain either, because most of the crashes I’ve seen in recent times are in the user space applications that are part of windows (ie. Explorer, IE, etc), and these are exactly the apps we’re talking about running on top of Linux.
For licencing reasons, they’d more likely pick a BSD variant anyway because any kernel level changes wouldn’t need to be open sourced. Given time, Microsoft chould “break” its BSD variant to make it incompatible with the original code.
Finally, while the Windows on top of DOS argument may have been true for the 9x series (ie. 95, 98, 98SE and ME), the NT series (ie. NT 3.x, NT 4.x, 2000 and XP) were built from the ground up as graphical, multitasking operating systems. There was never a DOS under the NT series GUI’s. It might be possible to port the GUI portion of the 9x series operating systems onto a linux kernel, there’d be serious API differences to overcome which would mean either a major re-write, or an intermediate “DOS emulator” to make it all work. Given that the 9x series is finally dead anyway, a rewrite is unlikely, and a DOS emulation leyer would have to kill any performace gained from the kernel changed in the first place.
