A rant about some of the nice things in the NT kernel
neosmart.net
neosmart.net
That's not to say that NT doesn't have benefits. Linux is still catching up with implementing some features that Windows has had for some time (and multiple GPU support is actually a great example of that), but so far there's no real evidence that these disparities are because of architectural differences.
Really, a worthwhile comparative analysis requires someone who has a deep understanding of the kernels they're comparing. I'm pretty familiar with Linux but know almost nothing about NT, so I'm a bad choice. But "Take the recent Linux arguments about the HardLocks code that is giving Linux trouble with multi-processor granularity"? That's not someone who knows Linux, otherwise they'd be using words that I recognise. "You call BSD a kernel, it technically is a set of APIs"? That's not someone who knows BSD either. This isn't an in-depth analysis of benefits that one kernel has over another. It's a handwavy justification of some NT design decisions without any reasoned comparison to Linux design decisions in the same area.
I'd love to read an in-depth comparison of the benefits of NT over Linux. This isn't it. Is there one?
> ...won't let closed source drivers use shared memory with open source code or somesuch out of their belief that it would violate the GPL.
http://linux.slashdot.org/story/12/10/11/1918251/alan-cox-to...
http://www.phoronix.com/scan.php?page=news_item&px=MTIwO...
Footnote: I don't believe I first read it on slashdot. That was just the first hit when I googled and it seems to summarize the debate fairly well.
I don't think there can be one. Even if one existed, its value would be questionable since the rest of us are unable to prove or disprove the claims therein, seen as we don't have access to the nt kernel code. We're stuck with uninformed rants by microsoft's evangelists, unfortunately.
Object-oriented? Linux is partially object-oriented (e.g. file systems). Modularity? Linux does have modules and you can put substantial amounts of functionality in them. If you need or want to is another question. Client-Server? The discussion of micro- vs monolithic kernel is not completely settled, but so far Linux does pretty well despite theoretical and academic arguments against its architecture.
Elegance is nice, but at the end of the day it is the features and the performance which matter to the user. NT claims better flexibility, however it is Linux, which can be used from Cloud to Cluster to Desktop to Mobile to Small-embedded devices.
Even though it got settled in a couple of years, the agreement was then secret and BSD was still under a legal cloud. And legitimately so, the settlement was eventually made public and had this gem:
"7. Further Participation in Litigation. The University agrees that it will not actively assist or support BSDI's defenses or counterclaims in the Federal Action or the efforts of any other party who asserts in any action the right to copy, use, or disclose to non-licensees of USL any of the material contained in the Restricted Files or the invalidity of USL's proprietary rights in the UNIX System. However, nothing in this provision shall prohibit the University from responding to any discovery permitted a third party under federal or state law or from defending any claim that may be asserted against the University or the Individual Regents." (http://www.groklaw.net/article.php?story=20041126130302760).
(In retrospect it turns out SCO was never a real threat, for they didn't have the copyright to UNIX(TM), only the duty to collect fees for a 5% vig, and they knew before the lawsuits that they didn't have it (!!!).)
NT is deployed in all these cases too.
NT's OO is actually very pragmatic. Things such as files, pipes, processes and locks are objects that, because they are global, can be shared across processes and worked on by many different APIs.
Every object has ACLs that are managed by the kernel itself, so you can create a named pipe that is accessible by users with a given role, for example.
You can use synchronization APIs with heterogenous collections of object handles; for example, you can tel the kernel to wake up on the next mutex, file activity or process exit simply by giving those objects to the appropriate wait API. Unix' select() pales in comparison.
(I spoke to someone else who was utterly amazed that NT allowed driver development without requiring that the whole kernel be relinked from object files.)
mjg59, I could not disagree more. Without working drivers what good are working apps? I can run my Radeon x1900 under Windows 7/8 with Windows Vista drivers. Runs StarCraft2 and newer FPS games just fine.
The Linux kernel devs are so determined to break binary compatibility, I haven't been able to run with ATI's proprietary binary drivers for years. While AMD was a good open source citizen and released the specs, the open source drivers for my card are useless for anything other than 2D. That's about as disruptive as it gets.
Well, of course. As long as no one else can use their drivers, they won't get a serious competitor in open source land. Pity about the rot in official drivers, though (e.g. for me, the latest is USB 1.x sound dongles in debian lenny -> squeeze).
Which suggests to me that if I wanted to write a OS that could become really popular I should use Windows device drivers in a microkernel approach where each lives in its own address space and process. Hmmm.
The one thing you will find almost as a theme with Linux design is that there is minimum of "future" it. That applies to most of the Linux user space as well. This is a good thing and a bad thing.
For example multi-gpu systems with multiple outputs were not taken into consideration when both the Kernel and Xorg parts were designed. They took the most common usecase of single GPU, probably made some assumptions around it and coded something that works for that usecase.
Microsoft, on the other hand (almost out of necessity) had to actually design the NT Kernel while making no assumptions - multi GPUs may not have existed when XP was released but none the less MS had to design for the eventual reality when some OEM will stuff 2 GPUs and will have to write drivers for it without Microsoft being able to change the XP kernel design or even implementation in any way. I am sure the same can be said about scalability - when massively multicore CPUs weren't around NT kernel was mostly up for task of supporting them, whereas Linux adopted with lot of scalability related work that followed after the fact. (Remember the early NT vs Linux benchmarks?)
Designing for future is bad because it comes with certain baggage and to an extent added upfront costs. It is good for future compatibility, code maturity and obviously saves rewrite efforts - you don't have to rip off all the code and start over and take care not to break existing software etc. There is less code churn in Windows world I am sure than there is in the Linux world where people are constantly adopting to new realities. This creates an environment ripe for new bugs, instability and only with the amount of volunteer effort the cost factor can be lesser than prohibitively expensive.
Maybe because it is mostly about the "past", bringing enterprise UNIX and mainframe designs into Linux?
It's depressing in a way but that's the best we got when it comes to a hackable Open Source OS that you can somehow run on your hardware and even patch things you don't like.
What new ideas in operating system design has Linux brought, other than being a UNIX clone at zero cost?
You could put 2 or 3 NeXTdimension cards in a NeXT Turbo Cube, for example - each with its own i860 running Display PostScript and something like 32MB of RAM - and use a display attached to each.
And the other workstation vendors had even fancier graphics subsystems and options. You could get real time stereo (LCD shutter) 3D with full Z-buffer and overlay planes for UI use (requiring a few dozen MB of VRAM) for the cost of a sports car. And with some systems use several at once.
Find some old copies of UNIX World or Personal Workstation or BYTE from the era...
Filesystems, TCP/IP stack, Multi core scalability etc are the areas that most benefited from old UNIX design. (Questionable in case of TCP/IP - Alan Cox rewrote it and I am not sure if he was influenced by any older UNIX implementation or not.)
Frankly, I'm still more impressed by a monolithic kernel that did it better, before: Plan 9 (released in 1991). What use is for NT to be object-oriented, if it can't share its objects through a network like Plan?
VMS.
> Frankly, I'm still more impressed by a monolithic kernel that did it better, before: Plan 9 (released in 1991). What use is for NT to be object-oriented, if it can't share its objects through a network like Plan?
Sadly the UNIX crowd decided it was not worth it adopting it.
For example, Solaris has had a stable driver DDI (Device Driver Interface) for years. This is what allowed ISVs to write drivers for ancient versions of Solaris that still work today (assuming the base hardware platform is still supported).
That's also what allows the latest versions of the nVidia driver to generally just work on different releases of Solaris.
The primary difference that remains is that Linux has "evolved" where as NT was "designed". The reason for this is that modern linux has had to work around several shortcomings of the UNIX model. (for e.g. non-async I/O, suid crap, non pre-emptive kernel syscalls etc)
So, what that means is that NT (in design) has specific interface boundaries in the kernel. For e.g. the device driver design has specific interfaces for the I/O Manager, the Power Manager , PnP manager etc. and communication is achieved via I/O request packets in a highly structured way. Linux is much more monolithic in this way (even though both get the job done in the end) I don't have access to the source so I can't say how much this modularity exists in practice. But atleast in theory it means that major changes to the kernel become much more easier.
We don't really get to dictate what they code,we just pick people who are already, to scratch their own itch, coding what we need.
So yes, there is a lot of paid work, but it's got a very individual character to it compared to my job where theoretically I could be coding anything a customer had convinced sales we needed.
Altough, yes, your point was taken, you have a weard definition of community that excludes profit motivated people.
> Anyone that’s ever manually compiled a Linux kernel knows this. You can’t strip ext3 support from the kernel after it’s already built any more than you can add Reiser4 support to the kernel without re-building it.
Even 5 years go (and at least 10 years ago) you could remove ext3 and add add another filesystem without rebuilding the kernel. I know Red Hat at least included a helpful Makefile for precisely this purpose.
Rebuilding entire kernels in order to compile a single kernel module is a well known habit of early Linux uses, following advice from pre 2.x kernel days when loadable modules didn't exist that seems to have stuck around in the collective mind of the Internet.
I don't remember exactly when did initramfs get introduced, but I remember it was a relatively long time before major distros switched to it. TFA is old enough so that might have been the case back then.
It's weird to me that the original blog post put Soma's name in "scare quotes." Soma is the Corporate VP of Developer Division at Microsoft, which means he's in charge of—among other things—Visual Studio, .NET Framework, ASP.NET, the now-dead Expression Studio, and I'm sure a few other things.
He goes by Soma because his full name is Sivaramakichenane Somasegar (really, I looked it up in Headtrax once and remember it, for whatever reason, seven years later). And, let's be honest, that is really hard to spell.
OS X didn't change the world by bringing some great new underlying architecture to the table. In fact, their kernel and filesystem are arguably getting long in the tooth. The value that OS X brought to the table was the fantastic Carbon and Cocoa development platforms. And they have continued to execute and iterate on these platforms, providing the "Core" series of APIs (CoreGraphics, CoreAnimation, CoreAudio, etc.) to make certain HW services more accessible.
There's very little cool stuff to be gained in the windows world by developing a new kernel from scratch. A quantum leap would not solve MS's problem. The problem is the platform. What's really dead and bloated is the Win32 subsystem. The kernel doesn't need major tweaking. In fact, the NT kernel was designed from the beginning such that it could easily run the old busted Win32 subsystem alongside a new subsystem without needing to resort to expensive virtualization (as the original article mentions).
Unfortunately, the way Microsoft is built today it have a fatal organizational flaw that prevents creating the next great Windows platform. The platform/dev tools team and the OS team are in completely different business groups within the company. The platform team develops the wonderful .NET platform for small/medium applications and server apps while the OS team keeps crudging along with Win32. Managed languages have their place, but they have yet to gain traction for any top shelf large-scale windows client application vendors (Adobe, even Microsoft Office itself, etc.) Major client application development still relies on unmanaged APIs, and IMHO the Windows unmanaged APIs are arguably the worst (viable) development platform available today.
What Windows needs is a new subsystem/development platform to break with Win32, providing simplified, extensible unmanaged application development, with modern easy-to-use abstractions for hardware services such as graphics, data, audio and networking.
This is starting to come to fruition with WinRT, but the inertia in large scale apps is unbelievable.
And he dismissed "Shipping Seven" with hysterical handwaving and BS pedantic arguments, that were even wrong. He could not understand what SKUs were, he thought Seven referred to Windows as merely a kernel, like what you build in Linux, and other BS, he made some BS comments that only apply to monolithic kernels and ONLY if you compile extensions instead of loading them as modules...
http://en.wikipedia.org/wiki/OS/2
Its design was supposedly far better than NT
(it initially came on 50 5.25" disks, that was "fun" to install)
I think UPS was the largest user/developer.
You know the company Parallels that made Virtuozzo (and OpenVZ) - well it was initially formed to make virtual environments to run OS/2.
At the kernel level API it wasn't much different than Win32.
I bet if OS/2 had gotten a better future, nowadays we would see rants about it similar to Win32.
The SOM C++ API was quite interesting, a Smalltalk metaclass like system for C++.
Another nice thing was the Visual Age for C++ provided an image like environment for C++, which made compilations quite fast.
I never used, just read about it in DrDobbs back in the day.
If memory serves me right, it imported the C++ code into a database and the editor was able to manipulate the code AST directly, but it consumed lots of memory, both RAM and disk space.
Maybe someone with more knowledge can fill the gaps.
The OS/2 project was a collaboration by Microsoft and IBM. Sometime around 1989-90, the latter was in charge of OS/2 2.0 while Microsoft was working on the next generation. The unexpected success of Windows 3.0 made Microsoft see they could do it on their own without IBM, so NT became the next generation of Windows instead.
IBM's OS/2 2.0-4.0 was a competent 32-bit OS for its era, but NT's design was more modern. The only thing OS/2 had going for it was a smaller footprint (it could run on 8-16MB of RAM while NT practically required 32MB) and a more innovative user interface, but this advantage was basically eliminated when Microsoft ported the superior Win95 UI to NT.
There was no way to do the assisted alignment you actually wanted. They'd pitched a fabulous, malleable, document-centric desktop. Technically it was all there. They didn't quite get it to the user. People who were fluent in C could probably have done some quick fixes and made it hum.
I think this was in version 2.0, and I watched it go unfixed in 2.1, warp. Can't remember if it was broken in 4, think so. Good example of the way OS/2 dev focused on ticking feature checkboxes (3d icons! a different dock! obscure mainframe compatibility features that mainstream users will never care about!) not users.
You could also use the Font panel to drop fonts into any application and it would change the UI font. Some apps actually saved that as a preference and remembered it on next startup but others didn't.
I got eComStation running in a VM a while back and I realized that my nostalgia for OS/2 didn't quite match the reality.
I think the MTA (in NYC) still uses it to process subway fares...
I quite liked it at the time, but to be honest I think the wistful "could have changed the PC world completely" stuff I sometimes hear is just rose tinted nostalgia. It was a very good OS for its time; its main competition then was Windows 95, and there was certainly no contest there. But the NT kernel was a different matter, especially after it got a saner UI in NT4. There were no huge advantages to one or the other there (with one exception, see below). Compared to very different modern OSes such as OSX or Linux, OS/2 and NT4 were close siblings.
OS/2's one real Achilles heel, which gave us endless trouble, was the synchronous input queue, shared by all programs that had a GUI (including the OS desktop). The upshot of this was that, if a user-facing program crashed, it was very likely to freeze up the OS and require a hard reboot. When we switched to NT4, the vast improvement in reliable uptime was a breath of fresh air (if nothing to write home about by modern standards). I gather they partially fixed this in OS/2 4.0, but by then the writing was on the wall. OS/2 faded away before the rise of modern malware had really hit its stride, but I suspect the SIQ problem would also have led to all sorts of security issues. For example, look up "shatter attack"; that was bad enough on Windows, but I'm pretty sure OS/2 would have been even more vulnerable to that sort of technique.
While I certainly wouldn't claim that son-of-NT's victory over OS/2 had anything to do with its technical merits, I do think that, at least between those two lines of development, the (slightly) better OS won.
So there was basically one global event loop for the entire OS? Interesting. I can see how that would make the window system a lot simpler to write -- not unlike the reasons why Node.js and other evented web frameworks have become popular.
At the same time it is, as you mention, an approach that would have been doomed to fail spectacularly by the late '90s when it became commonplace for desktop OSs to run unverified code downloaded from the Internet...
What OS/2 had was multi-threading. If you had to do some operation that might take longer than 1/10th of a second, the guidance from IBM was to put it on it's own thread. So by necessity, OS/2 developers became expert multi-threaders.
I think it was Stardock that had an excellent newsgroup reader for OS/2 -- it was multithreaded, so you could queue-up several requests for your newsgroups (alt.binaries.*, {ahem}) and the UI remained responsive and you could go do other things, like fire up GoldenCompass for your Compuserve fix. ;)
Would you accept to tell us more about what your team did, what were the goals and concerns about your system ?
In Windows 3.x modulo the DOS boxes allowed by 386s and beyond; they and the Win16 subsystem were preemptively scheduled, and a lot of good software targeting Windows deliberately used those boxes running ancient, decrepit DOS.
There were a few approaches - one was multi-threading, the other was to divide your task up into small enough pieces to not violate the 1/10th sec. rule, and the other was to install another product that gave you Message Queueing.
When splitting up your unit of work, you would define your own custom events such that when the event loop came around to processing your events, the granularity was small enough to keep the system responsive. BTW, events were prioritized by the OS, so not all events were treated equally. Same with NT. So you'd think of your application as a state machine, with the transitions being driven by the OS events appearing.
Message Queueing (the current darling of the scalability crowd) has been around a lot longer than people realize. :)
Also understand that for line-of-business applications, once the screen was done painting and you were waiting for user action, the event loop went into "idle" state. So in most cases you only had to worry about timeouts when you were communicating with a server (database or mainframe).
http://www.amazon.com/Showstopper-Breakneck-Windows-Generati...
I haven't seen this edition, but if the comments are correct, try and find an original from 1994 (has a shiny cover with big red letters) to avoid the printing errors.
It's written for a general audience, but still has some technical details in it. It's more interesting from a business and personality standpoint - at that level of software development doing things like kicking holes in your office walls becomes a little more acceptable (that would have gotten me fired at any job I've held)
He got it up, and running, at home, and work. Reported (and I recall agreeing after playing with it) that it was a better environment to run windows / DOS applications than was Windows.
Our employer (the US Marines) was not officially interested in the idea ... and so the idea never went past that.
I used it for a while in the early 1990s as a contractor in an "IBM shop". Literally everything they bought was IBM. From the mainframe to Terminals, printers, PCs, OSes. I remember it being painfully slow.... but the PS/2 PC it was running on was probably underpowered (as is typical, contractors got the oldest hand-me-down workstations).
The NT kernel had been shipping for about 10 years by the time XP was released. Windows NT 3.5 and earlier didn't have any kernel-level graphics (though they did have kernel-level drivers); kernel-level GDI came in NT 4 (1995-1996) for performance.
Windows NT was also used by some graphics workstation vendors like Intergraph and SGI, whom I presume did support multiple GPUs like most workstation vendors did.
Macs also had actual GPUs (not just frame buffers, but real QuickDraw accelerators) and supported multiple GPUs in the late 1980s - on System 6!
All it really takes is a reasonable display abstraction model/API, and an ability for that to interface reasonably with hardware drivers. Seems Linux could've handled that too - and it wouldn't surprise me if it did, at least theoretically.
I didn't follow Linux's initial development as 386BSD had already come out. I do remember the first accelerated X11 for 386BSD supporting some card with a number like 911. I don't recall that it required explicit kernel support, other than perhaps a bunch of ioctl calls or something like that.
http://www2.cs.uregina.ca/~hamilton/courses/330/notes/memory...
Ummm.. Kernel modules anyone?
Or do I have something wrong here? Have I taken something out of context?
At some point in time, NT (3.1) was apparently shipped in source form: there was no binary distribution for the first 4 and 8 processors systems back then and you had to compile your kernel yourself on the target machine (after installing the vanilla NT first).
"During the development of Xen 1.x, Microsoft Research, along with the University of Cambridge Operating System group, developed a port of Windows XP to Xen — made possible by Microsoft's Academic Licensing Program. The terms of this license do not allow the publication of this port, although documentation of the experience appears in the original Xen SOSP paper."
MinWin (affecting Kernel32.dll) has nothing to do with the NT kernel.
Care to elaborate why, instead of just accusing?
FYI, MinWin is completely a user-mode library change; it has nothing to do with the kernel. Even Wikipedia explains the misconception: https://en.wikipedia.org/wiki/MinWin#cite_ref-14
On the other hand, there is such a think called "MinKernel", which is related to the kernel itself: http://cdn-static.zdnet.com/i/r/story/70/00/013290/minwinmin...
Well, I made sense of it using only public information, and yet you claimed "You have no idea what you're talking about".
Obviously that means you must know better than me, so care to share where I made a mistake?
This single fact is enough to make it clear that it's a piece of shit.
Windows first shipped with UCS-2 at a time when the rest of the world was stuck with ASCII and various random codepages, then switched over to UTF-16 at around the same time UTF-8 was picking up speed; UTF-16 had the unique advantage of being (mostly) backwards-compatible with UCS-2, whereas UTF-8 would have broken everything. I prefer UTF-8 myself, but that doesn't make UTF-16 a bad choice.
In fact, while for the default ASCII range of characters UTF-16 consumes one extra byte over UTF-8's single-byte encoding, once you get into the "normally-used range" of international characters, UTF-8 quickly jumps to 3 bytes while UTF-16 remains at two.