Windows NT Turns 20

An anonymous reader writes with a link to the observation from ZDNet's Mary Jo Foley of Windows NT's 20th birthday (it came out on July 27th, 1993): ""In 1993, Microsoft launched Windows NT 3.1. It was followed up by NT 3.5, 3.51 and 4.0. Microsoft's Windows releases still rely on NT-inspired numbering conventions. Windows 7's build numbers commenced with 6.1; Windows 8's with 6.2; and Windows 8.1 with 6.3." The article also reminds us that "NT's not ancient history, in spite of its age. The NT 'core' is what's inside Windows 8, Windows Server 2012, Windows Phone 8, Windows Azure and the Xbox One.""

Comments

Lesson One

[Anonymous Coward]

The article also reminds us that "NT's not ancient history, in spite of its age. The NT 'core' is what's inside Windows 8, Windows Server 2012, Windows Phone 8, Windows Azure and the Xbox One.

Indeed. No matter how structurally sound your operating system may be, UI developers (receiving messages from on high) can still make it look like trash.

Re:Lesson One

[Anonymous Coward]

How's the kernel you wrote doing these days? Easy to criticise others i guess.

Re:Lesson One

[Jeremiah Cornelius]

The kernel is not structurally flawed.

It's just as sound as it was, the day Dave Cutler's team built an experimental port of VMS to CMU Mach. It's just as sound a kernel, as the day Microsoft ripped-off VMS from DEC.

It is the perversion of microkernel VMS by a flawed loadable driver model, and the .DLL nightmare that really sucks, and introduces "unpredictable" behaviors.

"Hey! PDP-11? Ask me how!"

Re:Lesson One

[goombah99]

BSD is the core of OSX and it's even older.

Re:Lesson One

[EvanED]

You don't need to have done something better to be able to determine whether something is good or bad.

Now that said, the NT kernel itself is pretty solid.

Re:Lesson One

[epyT-R]

Actually the NT kernel is probably the most well engineered component of modern windows. hell, it is what gave windows things like preemptive multithreading, proper memory protection, and hardware abstraction. The win32 base runtime sits on top of this, and pretty much everything else microsoft has released over the years acted as a wrapper for it. Windows 95 was the attempt to squeeze win32 into 4MB of ram for consumer machines while keeping hardware ports accessible by dos applications. These two goals were fundamentally in conflict with stable and reliable software. The reason we don't have to reboot windows every few hours anymore is due to the windows NT kernel.. As bad as you may think windows to be, it's A LOT better than the days of 3.x/9x.

Re: Lesson One

[jeffasselin]

DLL hell wasn't as bad in 2k and XP and is almost entirely gone now since Vista thanks to SxS.

http://en.wikipedia.org/wiki/Side-by-side_assembly

Re:Lesson One

[benjymouse]

Interactive services can expose system-level access to users - a design flaw shich should not be allowed.

This was deprecated in Windows 2000/XP (and you had to explicitly allow a service to interact with the user) and it was disallowed in Windows Vista and has been ever since.

The problem was that a service which typically runs with some form of elevated rights (at least to some resources) could expose those rights/permissions if there was a flaw in the interactive part that communicated with the user.

Your complaint is interesting, because the risk is very much the same posed by sudo (and every other SUID root) utility: The user is allowed to directly interact with a process which has higher privileges than the user.

Windows eliminated it. What about SUID root tools, which have historically *many* vulnerabilities and actual exploits and system compromises on its conscience?

I also remember when Vista moved graphics processing into user mode, so that the usual BSOD from graphics drivers famous in XP would simply be an abnormal termination. Reading suggests this was reversed in 7 because of the slowness this added.

Sorry, but this is BS. You need to cite sources for that "reading" you have done.

WDDM is still very much a split driver model where the driver author has to create a (small) kernel mode part and a user model part. The graphics subsystem is still much more stable on Windows than Linux. And even when the driver or hardware fails (e.g. overheated) it merely resets and comes back up, *without* killing any processes, clipboard or services.

If graphics - fundamentally the way the OS communicates with the user, since the command-line is supposed to be a second resort - has to be so close to the metal it can't be in user space without slowing it down, this is not good.

Wrong on all counts. Windows allow multiple ways to "communicate with the user". Core versions of the servers, for instance, does not use GUIs. And it is your BS claim that it "is slowing it down". All benchmarks I have seen strongly suggests that Linux has a very hard time keeping up with Windows in this area - even when Windows uses a compartmentalized (and more stable) driver model.

But if the intent is to provide a windowing environment, and the method of doing so is not secure, maybe the kernel has exceeded its usefulness.

1998 called. This is not the 9X kernel. The Windows kernel of today runs services in a ''seperate session'' from the users session.

I should also say that a lot of uninformed people parrot the idea that the kernel is well designed, siply because it flies in the face of all the Microsoft hate. The original nerd hipster, who likes something - or believes that something can be good - even if the masses hate it. Or just because the masses hate it.

So far you have offered nothing but speculation and outdated myths. Talk about uninformed.

I have personally used a Shatter attack to expose passwords masked by asterisks. There is a single byte in the window definition that says "replace every character with this one because this is a password box". If it is not filled in, the text box is normal. If it is filled in, it's a password box. Most apps that display a password set the password style (by default filling that byte with an asterisk) and put the password up.

I don't know a single application that pre fills password boxes with the current password. Would you care to elaborate on that?

Since Windows Vista, applications running with medium integrity level *cannot* freely send messages to other processes' windows. UAC integrity levels mandate that in order to send

Re:NT 3.51 was the best kernel

[Anonymous Coward]

I didn't see the source but could definitely tell. I remember NT 3.51 being very responsive even when a program was misbehaving. If I recall I had it run 16-bit programs in their own memory so they didn't affect each other. NT 4.0 did seem like PnP was just crammed in along with the Windows 95 interface. I feel old.

DLL nightmare

[ArchieBunker]

I have yet to experience this DLL nightmare you speak of. I've had way more dependency hell on Linux than anything. Say you find a great program that does exactly what you need. Well the author based it off some obscure library that needs a dozen other dependencies. One of those said dozen fails to compile. I'm not a CS major so the story pretty much ends there.

The only DLL issue I've had was getting some of the cygwin tools. It needed some DLL and their site was useless for supplying it. I just need the one file, not their installer giving me the entire dev environment. In the end I searched for the filename and "index of" and found a copy that way.

I still don't understand how VMS can be compared to NT. They don't even seem remotely similar.

Re:DLL nightmare

[benjymouse]

Fortunately, 'apt-get install great-program' always works for me.

Talk about a flawed model. Instead of dealing with the problem (reference management), Linux repositories sweeps the problem under the rug.

Instead of coming up with a solution which can actually *both* allow shared libraries to be used *and* support a heterogeneous software environment, Linux repositories forces an artificially homogeneous environment.

Instead of a software package supporting d distros and v versions by virtue of an OS supported library broker, you are forced to create d*v versions of the software package. This is the reasons so many drivers and applications break between versions: Nobody can test every distro and every (supported) version of every distro. The software authors typically will only test a few of the most popular distros and often only the most recent version. Compatibility errors crop up, but the exercise of finding them is left to the users.

The basic idea of a software repository with signed packages is sound. (Mis)using software repositories by cloning them to address the problem with dependency hell is stupid. The model does not scale. And it *still* does not solve the problem. Step outside of the distro and version specific (!) software repository and you are back in dependency hell, knee-deep. Software repositories are the Matrix. It is a dream world that has been created to disguise the ugly problem which still exists in Linux: Dependency hell.

Contrary to the ignoramuses still beating the DLL hell drums, the problem has been solved the right way in Windows: Side by side assemblies (SxS). From "Windows Internals":

Fusion (SxS) Redirection. Fusion (also referred to as side-by-side, or SxS) is an extension to the Windows application model that allows components to express more detailed binary dependency information (usually versioning information) by embedding binary resources known as manifests. The Fusion mechanism was first used so that applications could load the correct version of the Windows common controls package (comctl32.dll) after that binary was split into different versions that could be installed alongside one another; other binaries have since been versioned in the same fashion. As of Visual Studio 2005, applications built with the Microsoft linker will use Fusion to locate the appropriate version of the C runtime libraries.

Basically, as an application developer you have two choices which both avoid dependency hell: Ship the specific version of the DLL with your application (but do *not* install in Windows/System32) or request the installer installs the DLL as a SxS assembly and then reference it from your application manifest. The SxS cache can hold multiple versions of the same DLL and the manifest can describe the policy for brokering the version (whether the app always wants the latest or a specific version, for instance). This allow patching to be performed on the central SxS cache instead of each application with separate libraries.

There is a reason GP has not experienced "DLL nightmare". It doesn't exist any more. These days it is but a myth that detractors desperately want to keep alive.

I remember the good old days

[WaffleMonster]

When every new release of NT brought with it new and useful features at least I was always excited to upgrade from 3.5 on till about 2K8.

Now nobody seems to care about technology anymore... It is all politics, marketeering and guarding the table to ensure no excess value is ever left upon it. Innovation is now measured by games with shells, errecting walled gardens and fresh paint of questionable quality. Sad to see so much potential go to waste.

Last revolutionary M$ product

[michaelmalak]

NT was the last revolutionary product put out by Microsoft. VB3 came out the same summer, and was also revolutionary. Excel 4.0 and Word 2.0 were the only other two revolutionary Microsoft products, and those came out the year previous.

All of these products are essentially unchanged over the past 20 years, with even the same codebase, with the exception of VB 3.0, concepts of which continue in the 2nd generation Visual Studio product (based on the late-90's Visual Interdev platform, chucking the highly responsive 1st generation that ended with Visual Studio 6.0).

Re:Seriously?

[peragrin]

It takes a lot of skill to keep windows running for 20 years.

a 24 year old could have run slackware for the last 20 years.