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.
That's a pretty big oversimplification of the matter. Basically, David Cutler left Digital after DEC decided to ax a project he was working on to build a new chip and an OS to go along with it, Microsoft offered him a job to work on the chip and the OS, and Cutler managed to recruit most of his dev team from DEC for the new MS squad.
:-)
So saying that NT is just VMS part II isn't really accurate, but the same guilty parties are involved. If you can find it, there was a book called _ShowStopper! The Breakneck Race to Create Windows NT_ that does a pretty good job of chronicling the history of NT during its early days.
Know thy enemy, and all that.
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).
>> John Carmack and the rest of the gaming industry started bitching Microsoft out for pushing Direct3D over the clearly superior OpenGL.
Rest of the gaming industry? From my viewpoint it was Carmack alone.
Clearly superior OpenGL? Depends what you're using it for. OpenGL certainly wasnt (and still isnt in many cases) faster on consumer level cards. Direct3D was developed alongside consumer level hardware supporting features that actually exist, OpenGL was designed on paper.
By and large 3D gaming was being written for glide, and developers absolutely loved an open api specifically targetted for game development.
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.
I remember reading an article in 1992 where Bill Gates said "Windows NT will be a better Unix than Unix". So I don't think the vision was limited to Dave Cutler. I am still wondering how Bill could say that when Windows NT/2000 has minimal Posix support (1000.3 System Calls), is single user multitasking (unless you use Terminal Services, another Microsoft product you pay through the nose for), and has the worst scripting language ever! I guess that is why MKS (MKS Toolkit), Interix (OpenNT), and Cygwin are around, to fill the gaping holes in the "vision" of Bill and Dave and bring Unix to Windows because Microsoft can't or won't do it!
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.
IBM quality
You never tried running DOS apps in OS/2 1.0, did you. To say it was buggy was an understatement...
OS/2 development speed wasn't so bad
As long as you weren't waiting for applications which ran on your shiny new requires-4MB-of-RAM-costing-to-boot OS/2? Whatever happened to OfficeVision again ;-)
The real problem is that MS wanted to push forward the stupid MS Win16 API inherited from MS Windows 1.0 for the IBM-PC/XT
No, the real problem was that the marketplace didn't want OS/2: even when Microsoft were fully committed to it (the period thru' mid-89) and pushing it as the best thing since sliced bread, no-one (outside IBM fiefdoms) bought it. If you want to blame anyone for this state of affairs, blame the clone makers who had no interest in handing control of the PC marketplace back to IBM. IIRC, at the time and with all of DOS's flaws, and with both IBM and Microsoft telling the market that DOS was dead and OS/2 was the way forward, DOS was outselling OS/2 by a ratio of about 200:1.
Oh, and targetting the 286 was a bad idea from the get go, but IBM didn't want to eat into sales of their (expensive) AS/400 line.
while IBM would have made it interoperable
documented
As long as you were prepared to fork over $3000 for said documentation
and stable
I get it: you never used OS/2, did you. Because if you did, you'd know perfectly well that when OS/2 shipped it was so flakey it made Windows Me look like a beacon of system stability. Maybe by OS/2 3.0 it had become moderately usable, but OS/2 1.0, 1.1, 1.2 and 1.3 sucked in so many different ways and had uptimes measured in minutes. Datapoint: a customer at the time had about 500 PS/2 Model 60s running OS/2 1.3 w/ Presentation Manager, one in each store. At the time, this was an investment, in hardware alone of about $3 million, plus about another third of a million in OS licences (yes, only ten years ago $700 was considered a very reasonable pricepoint for a desktop operating system licence - if you were IBM...) They were shockingly unusable - as in the store manager would be entering that day's sales into a dBase app and running the numbers and they'd be able to enter stuff successfully about one time in three - the other two, OS/2 or one of the apps running under it would crap itself, lock the queue and once that happened it was goodnight Vienna.
Cheers
Jon
No, it means they run a clean automated daily build, which is common practice for most projects. Incremental builds are great for devs, but the official build is most always done clean.
Even as a dev, I try to run a clean build of my systems when I leave Friday. I can't tell you how many times a weird bug has been caused by some missed dependancy that the make system wasn't rebuilding.