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*
This book, from around '95 I think, was a great read. I don't know how much overlapit has with the articles mentioned above, but I enjoyed it.
0 29 356717/103-3105313-8496655?vi=glance
http://www.amazon.com/exec/obidos/tg/detail/-/0
Also available at your local library!
Sorry, but I think that's Waddle, the Beanie Buddy (a larger version of Waddle, the Beanie Baby). Penguins are cool to a lot of folks - and not all stuffed penguins are Tux.
I see a lot of complaining in the article about how some architectures were not ready for NT on a timely basis (Intel i860, PowerPC), but I see no mention how they were so slow to bring NT to the Alpha. I recall that DEC actually ended up porting VMS to the Alpha because they were waiting on MS for their promised NT release. I'm a bit curious to hear from the developers about their perspective on that.
I've used both NT and VMS on the Alpha (as well as a Unix varient). NT is sooooo slow.
-Jennifer
It is interesting how incrementing each of the letters in VMS gives WNT. It is something similar to IBM and HAL.
Winsupersite is, for the most part, a very pro-microsoft website...however, even if their reviews and previews may be slanted a bit they still get very early releases of different products and write decent reviews of them...with lots of screenshots!
Passing IRP's (IO request packets) between drivers creates a much more well-defined interface that a bunch of globally namespaced functions just calling each other (like some other OSes we all know). It also lends itself to a layered driver model (Bus Driver, Physical Driver, Functional Driver) much better.
I really like the NT Kernel. What driver developers do with it isn't the kernel's fault.
Nothing is so smiple that it can't get screwed up.
And while you're right that this article is a very happy view of NT, it's interesting from the standpoint of how a project grows and new versioning control systems are added to handle such growth. Sure, the articles are heavy on fluff and light on details - but Microsoft is closed source. They're not going to give you much more. I honestly am not sure why you're so upset with these articles.
I hate liberals. If you are a liberal, do not reply.
I still remember all the programs all over the internet you could use to grab NetWare passwords, so its not like MS was the only one with holes.
What is a difference, however, is that people are still using NT4, whereas none of its contemporary OSs are around anymore (or at least, not around in a significant installed base).
Manipulate the moderator system! Mod someone as "overrated" today.
I have had this thought myself, more often lately. I have come to the conclusion that it's probably not an active conspiracy by MSFT. Instead, I think it is a passive effect of a monopoly system.
My example:
Reviewer A writes a technical summary of some new MSFT product. Reviewer A invested months learning this new product and how it fits into MSFT's overall strategy. Reviewer A runs a consulting firm that specializes in MSFT products. That firm has invested time in training its people to know the new MSFT product. Reviewer A is probably not conciously being unethical, but he needs people to use this new MSFT product so his firm can make money helping companies solve the new problems that this product created. He writes a review/book that highlights the good points and downplays the bad points.
So, his review is biased, but it's not exactly a conspiracy by MSFT.
I think that they were forgetting about that orher large-scale software engineering task, in which thousands (tens of thousands?) of people crunch out code and compile software every day.
What's that called?
Linux.
What I am amazed at is that in the history of Windows NT Dave Cutler was cut so little space. He was mentioned twice. Once at the beginning of the article and then in the timeline.
And from what I remember about the hoopla, etc. Dave Cutler was fairly important in the first version of Windows NT.
But you know it shows just how little MS remembers the people who got it there in the first place!
"You can't make a race horse of a pig"
"No," said Samuel, "but you can make very fast pig"
I was an employee with Microsoft for sometime and was there when the RTM march was on for Windows XP and I can definitely tell you that war team during the last few weeks before escrow is a lot more than just inconsequential bugs. Its staggering how many bugs that are punted to the next release are actually rather serious in the grander scheme of things beyond the "ship windows" horizon. This is a very happy and flowery view Paul has given but it is not very accurate.
[---snip---] /usr/src/linux | wc -l
tanzarian:/$ grep -r ' goto '
1543
[----snip---]
that's from 2.4.19
I laughed out loud over the assertion that the Win32 API is easy to work with. I guess you can get away with lying when you know your audience won't go and check.
Go get a complete listing of the API function reference sometime. It looks like 12 different groups of developers came with 12 different coding styles (few of which could be described as elegant; or even safe for that matter) and got in a fist-fight. They were all beat up and too tired to fix it at the end of the day, so they just shipped the mess that is Win32.
Wonder why they re-invented all the ANSI C functions. The new functions do the same things, but with different names.
NT was a great operating system until 1990, then it went to hell from there.
A. Penguin User
"to me rebuilding libX throws another wrench into the fire."
Exactly!
If rebuilding libX is going to cause you problems, then you want to know about that NOW and fix it. I don't see any benefit to waiting to address build issues. Do you seriously think you're going to improve your productivity?
Actually MS stabbed IBM in the back by breaking the agreement (MS-W16 never to get 32 bits or a DOS virtual machine, OS/2 forever) without warning by launching MS-W3.1. This effectively killed OS/2 and made going from OS/2 3.0 NT to MS-WNT a no-brainer for MS.
You mean IBM quality, not speed. OS/2 development speed wasn't so bad; in fact, they decided to go for a command-line only, i286 version initially in order to ship early.
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, and IBM knew it was garbage. Also MS realised it could get more money by selling a product without any interoperability or standardisation, while IBM would have made it interoperable, documented and stable -- as they still do with the current IBM OS/2.
Leandro Guimarães Faria Corcete DUTRA
DA, DBA, SysAdmin, Data Modeller
GNU Project, Debian GNU/Lin
"my software is being updated, but libX isn't, then i wouldn't want to recompile libX"
I guess it depends on exactly how much you trust the software that decides what depends on what and what's changed. Can you honestly tell me you've never had a problem that doing a "make clean" fixed?
All I'm saying is that for the groups I've worked in, the cost of having the automated script do a "make clean all" as opposed to "make all" each night is considered acceptable for the peace of mind that knowing that absolutely every change is accounted for and there's no possible dependencies that got dropped in by make.
Not representing or approved by my company or anybody else.
Actually, I think it's "Tux Rux" (second entry under Penguin -- compare the grandparent's photo with TR's photo). They were selling these two years ago at our local Safeway supermarket, and I got one as a Christmas present then. When you push his belly, he will alternate with "Hi! I'm Tux Rux" and a very disturbing growl/purr that I can only assume is the sound that a very irate poked penguin would make.
Without you I'm one step closer to happiness without violence.
It is hard to tell. Bugs are filed for the obvious (software errors) but also things like new features desired, performance enhancements to be had, and occasionally things like rearchitecture needed (say, redo horribly confusing UI to something better).
It is true though, when the war room meets you have to have somebody there to vouch for any fixes checked in to resolve bugs. Mostly the war room wants to hear about impact, if the fix was tested, any issues that arose from the testing (regressions and/or new problems), and if the fix is really needed.
What is a branding issue bug?
Unlike some doomed attempts to make a "better" Windows clone *cough*Freedows*cough* that degenerated into a puff of vaporware, the fine people at ReactOS have been keeping their noses to the grindstone and quietly worked away at getting an NT clone working. It's still a long way from replacing NT, as this screenshot of the one and only GUI application shows.
But if you want a free and open look at Inside the development of [a] Windows NT [clone], ReactOS is a good place to look.
They've done a number of things right:
Did I mention they spend thankless hours coding?
Let's see if I've got this right:
"This late in the development process, bugs are often passed along, or "punted," to the next Windows release--Longhorn--if they're not sufficiently problematic."
"The atmosphere in War Room is intimidating, and I spent most of my time in the room, silent and almost cowering, praying that Wanke wouldn't turn his attention to me or my group.... The most virulent treatment, naturally, is saved for those foolish enough to blow off a War Room meeting. 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."
So... in this macho atmosphere, reeking of testosterone... the punishment for not being that the bug meet is that... YOU DON'T HAVE TO FIX YOUR BUGS UNTIL THE NEXT MAJOR RELEASE?????????
Words fail me...
"How to Do Nothing," kids activities, back in print!
If they're really that fix-crazed, how come outlook has had the same bug (overly persistent and reappearing send/receive dialog box) for years now? I first got that bug on Outlook Express on Windows 95. Fast forward 5 years, and I have that bug on Outlook on Windows 2000.
I had heard that when Microsoft released MS-DOS to IBM originally, it didn't work and IBM had to all but rewrite it( PC-DOS ). I'm sure there where many at IBM who knew how bad a coding Microsoft was/is but they "partnered" on OS/2 anyway.
I had also heard that another big fracture between IBM and Microsoft was in the design of the OS itself. Microsoft wanted the application with focus to get most of the CPU and IBM wanted a tight kernel so that all apps got an appropriate amount of CPU time. It took almost 10 years before Microsoft came out with an OS( W2K ) which had decent multitasking for the DESKTOP. Of course THE DESKTOP was now a 700MHz machine with 128MB of RAM while OS/2 still ran great on a 300MHz machine with 64MB of RAM.
It's all about marketing though and that's what Microsoft is, a marketing company. The ultimate snake oil salesman award goes to Bill Gates and Steve Balmer. IMO.
LoB
"Anyone who stands out in the middle of a road looks like roadkill to me." --Linus
(of the anti-trust case)
Microsoft is pushing awfully hard to sell their version of NT's history. The fact is, that even if someone was on Microsoft's payroll to tinker with some "new technology" since 1989, there was no NT product until 1996, when Windows NT 3.5 came out. It was a flop, because it still had the old Windows 3.1 GUI, and everyone was enarmoured with Windows 95's look and feel. Their official "NT 3.5" was actually just a bolted on netware client to windows for workgroups (16 bit.) NT 4.0 was just a GUI upgrade, but wasn't really usable for a couple of service packs. NT started having "server" functionality around 1997, and that was really just back office -- whose main feature was a network printer driver!
Yeah, both of them keep a ton of stuff in kernel-mode code, such as file sysstems, network stacks, etc.. They're not microkernels much like, say, QNX, however.
Microsoft C actually does support structured exception handling with _try/_except (along with termination handlers using _finally), which is vital to the design of the NT kernel. I think it was added to the MS C compiler specifically for NT, but I'm not sure. Anyway, the proper use of C exception handling in kernel-mode NT code (e.g. device drivers) is explained in the NT/Windows DDK docs.
A related point is that I do recall that MS tried to get exception handling added to C some years back (for the C89 standard, IIRC), but failed. It didn't make it into C99 either, unfortunately, although I don't know if MS bothered trying to get it in again. (And people wonder why MS so blithely ignore standards.)
As for gotos, I agree there's nothing wrong with them. Even when exceptions are available as an alternative, gotos can be considerably more efficient in certain cases (e.g. where you know exceptions will never be thrown).
I'm not surprised. Dijkstra's "Goto Considered Harmful" paper isn't gospel. Lots of programmers disagree with it, including core developers of Linux. In fact, I only ever find first year uni students quoting the paper and that includes myself back when I first read it :-/