Windows: A Software Engineering Odyssey | Hacker News Reader

Windows: A Software Engineering Odyssey

danluu.com

47 pointsBrajeshwar19 comments

"Defects occurring in the boot or test phase must be corrected before the build is "released" for stress testing"

Currently having issues with this at works. Teams are pressured by their PM to release at certain time, and breaking thr pipleline and sending back bad code creates you lots of enemies from top to bottom.

Sometimes you just know the project is doomed by looking at how the organisation handles failure.

> Currently having issues with this at works. Teams are pressured by their PM to release at certain time, and breaking thr pipleline and sending back bad code creates you lots of enemies from top to bottom.

I really had to think deeply to actually "get" your point because my experience differs a lot:

Recently I reimplemented some convoluted feature, which is somewhat critical for some business processes. The tester found a (surprising) bug in my implementation - I indeed did something subtly wrong. After this, a next round of testing came - it looks like another class of errors was found.

Honestly, I am very thankful for these errors that were found. The test cases that the testers provided help me to make my code much better and robust.

(just to be clear: of course, normally I write code that is mostly free of errors, but this feature is, as mentioned, quite convoluted with a complicated history behind; I already warned the testers beforehand that they better test very comprehensively).

Back to topic: Sending code back to me with a clear indication where it fails will for sure not make me an enemy, because this nearly always leads to improvement in my code, which is what I actually want (on the other hand: office politics might easily make me an enemy ... ;-) ).

The reason you don't make enemies with QA is because you have been able to express your earnestness. If you instead, however, sent bad code on purpose, or carelessness, because of a deadline. Then you would make enemies.

It's fascinating how the Windows kernel is the only mainstream desktop or server kernel that stood the test of time without being either a Unix system or derived from a Unix clone.

That alone makes it a great case study. Of course it stood on the shoulders of giants too. But today it stands alone with many design decisions. Some turned out great, some less so. But the design philosophy and quality of the kernel is very solid (something I wouldn't say about the userland work Microsoft did over the last two decades)

Interesting how staff numbers climbed at a 50% to 140% rates between kernels. I wonder how many devs Win 10 and 11 had. How do you even coordinate projects with thousands of people working on the same code?

  Product  Devs Testers
  =======  ==== =======
  NT 3.1    200     140
  NT 3.5    300     230
  NT 3.51   450     325
  NT 4.0    800     700
  Win 2K   1400    1700

NT wasn't "all new code" , " built from the ground up" : Dave Cutler, designer of DEC's VMS, re-used heavily many VMS concepts.

So much was borrowed from VMS that with a little bit of changed terminology, you could use the VMS Internals book to program NT. see: https://www.itprotoday.com/server-virtualization/windows-nt-...

NT was in fact all new code written from the ground up - there is no code from VMS (or the later MICA project at DEC which more closely resembled NT than VMS). Any serious study of VMS' architecture will show that there are considerable differences between NT and VMS.

There is plenty of reporting, contemporaneous with the events, that state the similarities. See https://techmonitor.ai/technology/dec_forced_microsoft_into_...

Both can be true. The design is clearly VMS influenced, but that doesn’t mean they took code from VMS, which DEC clearly would have had a say about. I think Mark’s point in the slide is to emphasize they didn’t take code from older versions of Windows.

While Microsoft may have been "dragged kicking and screaming" to the specific $105 million figure mentioned in this article, a co-marketing arrangement that resulted in DEC endorsing Windows NT as a migration path for its significant but declining install base of UNIX and VMS server and workstation customers sounds like a win for Microsoft, not DEC.

It also reminds me of the settlement of the DEC v. Intel lawsuit the next year that resulted in Intel buying out DEC's semiconductor operations and DEC endorsing IA-64.

If nothing else, the DEC/Microsoft alliance eventually resulted in a promotional copy of OpenVMS and Windows NT Integration for Dummies[1] showing up in my mailbox, which as I recall was both amusing (the book's name) and informative (its contents) at the time.

[1] https://archive.org/details/openvmswindowsnt0000jimm/mode/2u...

There are similarities commensurate with the fact that Cutler and other former DEC engineers designed NT. Overall, they are quite different operating systems. The idea that NT is some kind of rewrite of VMS is seriously overstated.

If you write new code, it's new code. Doesn't matter if you have reused concepts and ideas to write that code

Sourcedepot was still in use when I was there 2008-2011. It was a fork of perforce. I heard they replaced it with git in the mid 2010s.

Reply on news.ycombinator.com