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*
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 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.
[---snip---] /usr/src/linux | wc -l
tanzarian:/$ grep -r ' goto '
1543
[----snip---]
that's from 2.4.19
"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?
"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.
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!