Slashdot Mirror
Inside The Development of Windows NT
mrpuffypants writes "Winsupersite has a 3 part series this month about the history and development of Windows NT all the way up through Windows Server 2003. The author goes fairly in-depth describing how Windows is developed, managed, and how all 50 million+ lines are compiled daily. Part One covers the history of NT from its early days at Microsoft and Part Two discusses how the deployment of the forthcoming server version of Windows is coordinated daily." *shiver*
GameTab - Game Reviews Database
No. Dave Cutler, who was lead developer for NT, was previously one of the lead developers for VMS. I don't think that MS actually took any of the source code from VMS for NT, however.
I thought the initial NT "heavily borrowed" (MS tradition) from the Digital Equipment Corp (now part of HP) VAX operating system. Then it gradually incorporated parts of the evolving Windows/DOS OS.
That would be VMS (some VAXen ran Ultrix, poor things). IBM and MS started a collaboration called OS/2, then later decided to part ways. Whatever MS's other motives were in the split, MS was staking its entire future on what was to IBM a toy project, so MS wasn't entirely enthusiastic about development at IBM speed. IBM kept the OS/2 name, MS hired Dave Cutler from DEC, Cutler dubbed the new fork WNT: that's the letters after VMS, and any expansion is entirely a backronym.
NT does include some of VMS's heritage, including strong async I/O support throughout. The DOS stuff is really a matter of emulating the interface -- a whole lot of work went into making drive letters and backslashes work everywhere, believe it or not. Not surprisingly, it tends to share more in common with OS/2, with the supervisor design and the object manager for starters.
I've finally had it: until slashdot gets article moderation, I am not coming back.
Yeah. NT on the UDB was actually pretty tolerable. I ran NT4 Server on a 166 MHz 21066 (first generation Alpha). I found it to be quite usable. I didn't keep NT4 on the Alpha for all that long, as this was just an experiment. I had the NT4 disc, I had a UDB, and I had some time to waste.
You have to remember that NT4 was a 32 bit operating system, even on the Alpha. Therefor, you didn't really gain much by going to the Alpha, except for some nice speed boosts (it was definitely the fastest CPU on the market for years).
It was similar to running NT4 on a Pentium Pro 166 or 200.
The biggest problem I had was finding software. However, everyone's favorite telnet app, putty, comes compiled for NT4/Alpha.
The Register previously offered Windows 2000 for the Alpha, if you asked them for it. I never did, since my UDB was seriously underpowered (128MB RAM, 166 MHz).
If you look at other large projects of this type (eg Mozilla), both clean builds and dep builds using make are done on automated build systems. The two types of builds will find different types of issues.
In the same article, it mentions the changes with the graphics subsystem in NT 4.0. IIRC, NT 4.0 only supported i386 and Alpha, while NT 3.51 those, plus ppc and mips.
They moved the graphics subsystem into the kernel, and it ceased to be a microkernel. When pretty much everything lives in userland, portability is pretty easy. In fact, you can essentially write a new kernel (with the same external interfaces) for each architecture if need be. You also get neat features like being able to restart networking or the graphics system if they crash, without bringing down the system.
The problem that you have on i386 is that context switching is expensive (read: slow as a dog). On other platforms (sparc, ppc), it's not that big a deal.
Now, Windows doesn't look like a microkernel at all. And it's not at all portable, either. From what I understand, the Itanic port is giving them big headaches, and Intel is none-too-pleased about it.
There was a simmering fight over whether OS/2 should be "Protected Mode Windows" or whether Windows should be "Presentation Manager for DOS". Since neither platform had that many users or developers at the time, it could have gone either way.
While they make this sound like a Gee Whiz revelation, but in fact Microsoft wanted Windows compatibility in OS/2 from the beginning and IBM wanted a unique API.
Since IBM wore the pants, they won the day originally. However this really bit them in the ass with the the subsequent popularity of Windows 3, because it was difficult to target OS/2, so software was either missing or dismissed as a poor Windows port.
Not that Win32 was a huge success in the early years either -- most software had to be run in the Win 3.1 emulation, and even MS themselves only belatedly produced a 32-bit version of Office and not much other software.
Business. Numbers. Money. People. Computer World.
Only the size of the Linux KERNEL is currently about 5 mln lines, while the size of the WHOLE Win NT is about 50 mln. lines. This includes the whole GUI, OLE/ActiveX/COM+/InternetExplorer/OpenGL/DirectX and so on shebang, and also a myriad of printer/camera/scanner/etc drivers included in the default install.
The size of the WinNT kernel is nowhere near the 5 mln lines of code, I believe it is well below 1 mln. lines.
The WinNT is also only compiled for Intel platform, so it does not include code for other platforms.
Well....... maybe.
I seem to recall an MS employee claiming that it was entirely Microsofts fault Windows was so unstable, even though crashes were normally caused by faulty drivers. His theory was that if MS were more open with the kernel code, driver manufacturers could work more closely and easier with them, and the overall stability would go up. Instead what happened (they claimed) was that they would investigate a crash, find that some dodgy driver was screwing about with the kernel and so they'd tighten up the interfaces, get even more secretive with the code. The driver developers, faced with a brick wall, would then invent even more elaborate (and fragile) hacks to do what they want, so the stability went down, not up.
So, you can't really blame the kernel as a thing per se, but perhaps you can blame the management of it. Linux is now facing a similar problem with the growth of binary only drivers - they tend to hook into the ksyms and cause extremely hard to track down bugs, which is why they are no longer allowed to use those hooks.