The thing is that efficiency and production are not at odds with humanity. A standard of living costs resources that have to come from somewhere. If production is not valued, then there will exist no means to provide humanity. It's nice to say that there are people who are too rich, earning far more than they produce while others languish in poverty and that those resources should be diverted by force. Those people would be equalized-- for a while. Tomorrow when the productive people realize that their personal rewards for productivity can and will be plundered by force if and when they become too successful, they'll become disaffected (to say the least).
This is all part of a larger system, the best one we know about for maximizing production (along with quality of life). Sure, it's got ugly parts and cases where it fails, but until a better system is shown to work, we'll have to live with this one.
If a person is guaranteed a minimum standard of living regardless of output, what's to prevent that person from doing absolutely no work? What if the standard is high enough that a majority of people decide it's good enough, greatly lowering total production (and with it resources available for living)?
NT does have an "everything is an object" metaphor, at least for things exported from kernel to user mode. The Object Manager defines a class for such objects, of which object types are subclasses. Kernel mode components are free to define their own object types. The Object Manager defines the interface for common object functions and the owner of each specific object type defines an interface for specific functions (usually by way of syscalls).
Each object type has a set of function pointers for optional methods that the object type (the object class) can choose implement to override the standard object behavior. Every object has an optional name in the unified hierarchical object namespace, and can choose to become an extension of that namespace by implementing the Parse method. Every object has a security descriptor, which the Object Manager can handle automatically, or the object itself can handle when the Security method is implemented. An object can also be synchronized against (have a thread wait for signalling) by using an appropriate dispatcher header, or not by always denying SYNCHRONIZE access. The Object Manager also provides a unified method of sharing objects between processes by way of duplicating handles, which the object type can participate in by implementing the Open and Close methods.
As for subclassing, the object type would have to provide its own support. The IO Manager can do this in a way with device and file objects. A device object is backed by a layered set of drivers that implement different functions by passing a user request (an IRP) down the device stack where each driver can modify or split the request as necessary. Each driver in the stack could represent different classes, with the bottommost driver being the base class and the topmost driver the most derived class, free to override any operation. With the device as the class, the files created from it are the objects, and the functions IOCTLs. Constructor arguments can be implemented by the filename or with extended attributes (like TDI does it). With some conventions, it would be possible to implement a full class-object system in this way.
Um, device drivers certainly DO NOT depend on Win32. Win32 is an environment subsystem that sits on top of the NT native API, which combined with other kernel mode functions, are what device drivers use. Up until NT4, Win32 was implemented entirely in user mode; drivers couldn't call into Win32 then and they don't now. There is no interface to call Win32 functions from kernel mode; there are no Win32 headers in the DDK. The new UMDF is designed for code written in C++ using COM. Win32 is supported, but IDK if using the CLR (i.e..NET) is possible.
You're right that there is a huge dependency on Win32, though. All user-mode software in and for Windows depends on Win32 except the Session Manager, autochk and a few third-party boot time defragmenters. I, too, had once hoped that Win32 with its ugliness could become depreciated, secondary to something better such as.NET. Technically, this would be possible by creating a.NET environment subsystem independent of Win32, and moving core components over to the.NET subsystem. The performance of graphics and sound systems needn't suffer; they'd just go through an API translation layer (like the one that has always existed from Win32 to the native api). Unfortunately, at this point Microsoft seems to have invested so much into Win32 that it'll probably stay where it is for the lifetime of NT.
As for competing VMs like Java, ideally they would each be built inside their own subsystem independent of either Win32 or.NET, each using the same interfaces for system services. Realistically, they'd continue to use Win32 plus some extra functions. Reactos is planning a real Java subsystem, however.
When the seperate common and user specific program shortcuts were introduced in NT 3.1, the different types of program groups did in fact have different icons. Fig 1. When the new "Chicago" Win95 shell was created (originally 95 didn't even support multiple profiles) that concept was lost, even when multiple profile support was eventually added and the shell was ported to NT4.
It's inconvenient, but you can find out where the shortcut is located in its general properties (right click).
The main reason there are seperate folders combined at the last minute is for roaming profiles. A user profile contains their personal shortcuts to programs, but those programs may not be installed on every machine the person logs on to. When the local and user shortcut directories are used proprely, the user always sees the correct combination of programs available; the user profile contains only things available anywhere on the network or part of the OS, and the machine's "All Users" profile contains things installed on the computer.
This behavior dates back to NT 3.1 with seperate computer and user program group types and network profiles.
TDI is a set of interfaces; tdi.sys itself is only 20k with some support functions. I guess it's possible that the interface style could be getting in the way of performance, but I'm not quite sure how. TDI operations are just IOCTL IRPs with a common header and pre-defined functions (e.g. listen and send-datagram).
Maybe the problem is having buffering seperate from the TCP stack; in the TDI model, buffering is done above TDI, currently in the kernel-mode socket layer afd.sys. I was under the impression that AFD would continue to serve the same functions as before, including buffering, however. This diagram[1] seems to support that position; AFD is still between user mode and NGTCP/IP.
Technical details seem to be a little hard to come by, but the pages I could find are all about performance tweaks (mostly more automatic tuning) and new functionality, all at what TDI would consider the transport level (now broken into transport, network (addressing) and framing layers in NGTCP/IP). TDI doesn't care about how tcpip.sys is implemented internally, which is what these changes seem to be all about.
I did notice that afd.sys is now dependent on a new file: netio.sys, which is dependent on the new msrpc.sys. RPC in the kernel? That's new; it's been a required service since NT4 but implemented in user mode until now. The new tcpip.sys is also directly dependent on these new drivers. As expecetd, tcpip.sys is no longer uses tdi.sys, and user processes no longer hold TCP device handles for TDI context; everything goes through AFD now. I think there may be more going on under the covers than simple performance and management improvements.
Focusing solely on what's actually used is part of the degradation of NT that's been going on for years [...]
Well put. I'm a bit saddened that some of NT's elegant, innovative (and largely unknown) design features are being steamrolled for the sake of expediency, but I can see the reasoning from the perspective of actually selling the OS.
Unlike some other operating systems, the Windows NT and Windows 2000 transport protocols do not have a sockets-style interface which applications can use to talk to them directly. Instead, they implement a much more general API called the Transport Driver Interface (TDI). The generality of this API keeps the subsystems of Windows NT from being tied to a particular flavor-of-the-decade network programming interface. The Winsock kernel mode driver provides the sockets emulation (currently implemented in AFD.SYS). This driver is responsible for the connection and buffer management needed to provide a sockets-style interface to an application. AFD.SYS, in turn, uses TDI to talk to the transport protocol driver.
Ironically, it's TDI that's being replaced for something more sockets-like.
I think this is yet another example of Microsoft not understanding code that was previously written by someone no longer available, causing the new developers to misunderstand the original design, who then feel the only option is a rewrite. I've yet to hear any technical comparisons between TDI and "Next Generation TCP/IP", showing how the TDI architecture could never do those things. I bet TDI can support these new features with some new code, but it just wouldn't be as glamorus that way.
To adapt an old saying about LISP and UNIX, "Those who fail to understand NT are doomed to reimplement it. Poorly"
If you're asking for a queue arrangement, how about shared memory for data transfer and an IO completion port for synchronization? IOCPs are great for async IO as well, and can schedule a set number of active threads, even taking into account the number currently sleeping.
Actually, alt. file streams ARE used for extra summary data. Right click on some file from the shell, open properties, and click on the Summary tab. Each of the data fileds you see are stored in their own alternate file stream.
I remember that one of the promised features of Windows 2000 was a great increase in metadata; this is one of the few surviving remnants. Since 2000, Windows has shipped with a file indexing service with the same end goal of Spotlight in OSX. Some of the summary fields, i.e. the keywords field, were obviously meant to aid the indexer. I'm pretty sure it's possible to define your own tags as well, somehow.
Yeah, sorry. Looking back, I went over the top a bit. You're absolutely right about Microsoft not following their own best practices in many cases. Microsoft's marketing likes to say that Windows is highly integrated, but it's actaully many different pieces, of different quality levels, done by different people that don't really understand each other's components. This is just one of the many cases where Microsoft puts in a good backend but botches the last mile; the security features are there but the shell people don't undestand how the system is supposed to work. I'd also have to agree that the shell (of which IE is a part) is one of the least secure subsystems.
I've used multiple desktops before, but usually to insulate something less trusted from my main desktop. Winlogon uses a seperate desktop for the logon screen and one for screen savers. Every non-interactive service gets its own desktop as well. Otherwise, I'm not aware of anything that uses multiple desktop objects.
In the olden days when NT's security system was designed (same for classic UNIX security), users were given access rights; the user's processes got those rights because they were trusted to represent the user faithfully. Now with application vulnerabilities on the Internet and users that run software they shouldn't be trusting, users are finding that they need to be protected from their own applications. This was not seriously considered in the old model.
Yes, you're right: Microsoft already created a new, modern OS to fix otherwise basic design problems in the old one. Unfortunately, the only supported API on that OS, Win32, was based very heavily on Win16 (it even boasted almost full source-level compatibility with Win16 if you followed the rules) and brought obsolete, harmful conventions with it that Microsoft still can't get rid of. It also didn't help that a subset of Win32 was ported to the old OS line in Windows 95, and was THE Microsoft consumer OS line until 2001.
What came with Win32 were single-user conventions that don't include any local security or discrete users. There are lots of pieces of software for Win32 that require the system to go into single-user emulation mode, requiring administrator access all the time and the use of only one user profile. Most programs just ignore the new SecurityDescriptor, DesiredAccess etc. parameters of Win32 create functions-- the security parameters that Win16 didn't have, and Win95 doesn't implement.
Win32 also brought the old and quirky windowing system where parameters are packed into type-unsafe blobs, multiple messages represent the same thing slightly differently, messaging order is often strange but preserved for compatibility (i.e. WM_MINMAXINFO being sent before WM_NCCREATE or WM_CREATE), and many other inconsistencies. Not to mention that just having two applications of different privilege levels display windows on the same desktop represents a security vulnerability, again for historical reasons predating Win32.
Creating NT was certainly a clean break from the earlier OS line. IMO, it's an architecture worth keeping. Win32 as an operating environment compared to Win16, wasn't revolutionary and IMO needs to go. Half-implementations of Win32 didn't help any; the Win95 implementation level of Win32 still needs to be phased out.
Any application program can send messages to any other application program. There is nothing in the Win32 interface that provides any type of protection.
Bzzzt, wrong. As I said before, desktop objects are the security barrier between windows (and their messages). Every window is owned by a thread; messages to the window are posted to that thread's message queue. Every thread that can participate in window messaging is associated with a desktop object. A thread can only send or recieve messages to and from windows on the same desktop it is associated with. A window message cannot be sent without a destination window on a specific desktop. A thread can only be associated with a desktop if that desktop has been opened with sufficient access. The process of opening a desktop includes a check against the desktop's security descriptor. Microsoft guidelines have always warned against putting windows of different privilege levels on the same desktop because of the possibility of the harmful interaction it allows. As long as apps are following those guidelines, there is no way for a unprivileged malicious program to send arbitrary messages to a privileged process.
The most a process could be expected to be tolerant of is arbitrary user input, but even then the security model doesn't require a user's applications running with that user's authority to be protected from the user himself. The only programs that need to be immune to user input are ones that are trusted by the OS, yet interact directly with the user. Winlogon is the only process that fits that description. (Note that Winlogon has its own desktop to protect itself from any messages coming from the user's processes.)
There's no argument that Win32's messaging system is old and quite ugly, but to say it's an inescapable security hazard isn't true. When used properly, there's no vulnerability. Win32 is not X-Windows. Look up shatter attacks. It's the same idea, and they're inaccurate for the same reasons.
A few choice quotes:
Messages can be sent only between processes that are on the same desktop. In addition, the hook procedure of a process running on a particular desktop can only receive messages intended for windows created in the same desktop. Desktops
Warning There is a significant security risk for any service that opens a window on the interactive desktop. By opening a desktop window, a service makes itself vulnerable to attack from the logged-on user, whose application could send malicious messages to the service's desktop window and affect its ability to function. SetThreadDesktop
For the Windows user interface, the desktop is the security boundary. Any application that is running on the interactive desktop can interact with any window that is on the interactive desktop, even if that window is not displayed on the desktop. This behavior is true for every application, regardless of the security context of the application that creates the window and regardless of the security context of the application that is running on the desktop. The Windows message system does not allow an application to determine the source of a window message.
Because of these design features, any service that opens a window on the interactive desktop is exposing itself to applications that
MacOS/X has a much more stable and mature core Operating System base (Mach). Mach is MUCH older (circa 1985) than the windows NT core (circa 1993), and has been changed less. For example NextStep, released in 1989, was based on Mach, and already did much of what MacOS/X does.
If you want to go back to the OSes NT and OSX are based on, the NT core is based on VMS's design (almost as much as OSX from Mach, though OSX actually uses code from Mach, whereas NT has VMS's developers) and VMS was first released in 1978. Since NT was released, its core has undergone almost no changes. The biggest one was with Plug+Play supplementing device detection and power management.
Mach (the underlying OS) was designed with security in mind. Note however, the Mach layer doesn't define security policy, it just gives you tools with which to implement such policies.
NT was designed with security in mind. Note that the NT core itself doesn't define a security policy, it just gives you the API to implement such policies. I'll admit that Microsoft has been known to have somewhat crappy defaults for security and sometimes bad tools for fixing it. This isn't really a design problem in the OS, though.
Contrast that with Windows which has serious design flaws in its interprocess communication mechanism.
There are 3 places (at most) that applications can put their files in order to be following the rules that Microsoft has been publishing since at least NT 3.1:
The application directory. Since Win95, the standard location for these are in <system drive>\Program Files, before that <system drive>, but otherwise wherever the user picks.
The user's profile (or home directory pre Win95) for the user's own files.
Optionally, the system directory (<windows>\System32) for shared libraries. These can also go in the app directory (but won't be shared).
This is similar to the unix policy, except that unix usually specifies a specific dir for application binaries. I don't see how this is 'all over your system'. Doesn't OSX have any shared libraries? How are these installed? Besides, since at least the year 2000, the Windows Installer has been the standard (and recently the only MS sanctioned way) to install, which hides all these details, and allows unprivileged installation. Domain admins can even publish.msi packages on the domain which unprivileged users can install at their option (that or the admins can make installation mandatory and unattended). IIRC, the designed for Vista logo will only be possible for apps that can install unprivileged (unless they are administration type tools useless to normal users). If the article is referring to misbehaving apps, then that's hardly Microsoft's fault. Microsoft has long published 'designed for' logo requirements that are not unreasonable for their OSes.
I'm not sure how installation conventions are related to inter-process communication, though. Processes create named objects for IPC and specify their own security descriptor at that time. Any other process that wants to open that named object must be granted access according to the SD specified by the object's creator. Every type of IPC is ultimately protected by a security descriptor. Even windows, which recieve window messages exist in a desktop object which the calling process must be granted access to according to t
Windows NT and its derivatives (2000, XP) have always had a properly seperated user/admin security model. It's just that a all the momentum of programming in a single-user environment like DOS or Win9x has been letting devs and users flaunt the principles of privilege seperation. For example, the games that insist on installing a kernel mode driver for the sake of copy protection just to run an application, something that non-idiot unix users would never permit. Sony's rootkit wouldn't work without admin privileges on Windows either. Many users run as admin all the time just out of expedience; it's too much work (if th user even knows how) to coddle the bad apps by elevating their privileges all the time.
This is a cultural problem (with its momentum), not a technical one.
Just a simple example, in Unix a tape streamer behaves just like a file, the handful of file-related system calls, each with just a few parameters, apply to many devices including tapes. VMS has special system calls for tapes, for disks, for files, for terminals etc. etc.
NT doesn't have special syscalls for tapes. Disk files (local and remote), disk volumes, tape volumes, sockets, devices (even sound and video), busses, pipes, and mailslots (text terminals aren't handled in the kernel; they're a Win32 construct) are all implemented with the same file objects that have the same semantics and use the same syscalls. The relevant syscalls are NtCreateFile, NtOpenFile, NtReadFile, NtWriteFile, NtDeviceIoControlFile, NtFsControlFile, NtLockFile, NtUnlockFile, NtSetInformationFile, NtQueryInformationFile, NtNotifyChangeDirectoryFile, NtQueryDirectoryFile, and NtClose. What's so awful about that?
Objects exported from kernel mode to user mode all use the same handle system for reference tracking. Each object has its own type that has both common attributes with all types and its own unique behavior. These types include files as above, processes, threads, events, mutexes, semaphores, jobs, shared memory sections, LPC ports, registry keys, object directories and object symlinks. Every object has common object attributes, including security descriptor with the same functions for setting, getting and making access checks against them. Every object can have a name (some types don't require their objects to be named) in a unified single root namespace. Every object type has its own functions for creating and opening objects, with whatever special requirements for each. Each object type that has properties has set and query functions for that type, with one information class number and structure for each property.
Every syscall uses the same basic datatypes and returns the same NTSTATUS format error/status code. All strings are counted unicode. All times are the same format (Win32 calls it FILETIME). All functions, strutures, enums, etc. use the same naming conventions. All IO operations use the same IO_STATUS_BLOCK structure. All async IO operations allow completion syncronization by waiting on the file object, signalling an event, queueing an APC or IoCompletion. All buffers are allocated by the caller and use byte buffer lengths. Every type of explicit blocking (except LPC ports) has an optional timeout and option to wait alertably.
Even though NT's release was 13 years ago, the core design has never changed, only expanded for new features, because it was done right in the first place. NT never had to tack on security or in-process multithreading or asyncronous IO (like UNIX has) because those things have been there from the beginning.
If you're complaining about the quantity of syscalls, according to arch/i386/kernel/entry.S in Linux 2.6.7, it's 284: 1 less than XP's 285.
The big bang theory has been established for what, 50 years? Yet, Jastrow seems to have already declared failure. Trying to prove that a barrier is unbreakable is the same as proving a negative; it's trying to prove that no method exists to break that barrier. Trying to prove a negative is totally impractical outside of a closed system. This point in the apparent start of the Universe as we know it is a big barrier to going back further in time, and if and until we find a way to look back further, we won't know if it's even possible. Not knowing if it is possible isn't the same thing as knowing it to be impossible. Until we know everything about the nature of time, we aren't going to know if looking past the big bang is feasible. I agree that it does seem insurmountable right now, but Earth's gravity seemed that way at one point, too.
Yeah, I guess in the same way that believing the world to be flat or not are the only two worldviews possible. It's just one of many belief options that exist in a finite set. So?
How is "two" (and only two) the same as "many"? That's the point -- you don't have any other choices. It's either theism or atheism.
Let me put it another way: it's obvious if you divide people into two sets, one that holds a belief and the compliment set that lacks that belief then each person must belong to exactly one of those sets. Each person has a finite number of possible belief states, in these cases two. Theistic belief vs lack thereof is not special in this respect; there are many other optional beliefs that people can either hold or not hold. I'm not sure what you were trying to say with what is apparently a tautology.
A profoundly true statement (and is one reason why atheism doesn't work -- it isn't consistent, IMO. YMMV, etc.)
Thanks. Though I've heard that particular accusation about inconsistency used by pretty much every side. For instance, Objectivists say that every worldview other than their own is inconsistent.
Therefore, science is not the only route to knowledge. So I can't agree with your definition that the supernatural is hopelessly beyond understanding.
That's a good point; science isn't the only method of gaining knowledge. So, I ask you this: by what process can we learn about that which is outside nature?
It's true that science's universe of discourse is always natural reality. Whenever knowledge is expanded past what is currently considered natural, the definition of nature is extended to include it. The very idea of other dimensions was once considered supernatural, but as our knowledge of QM grows, they are becoming part of what we consider natural.
Science is built upon making predictions out of an understandible and consistent universe. Science and the realm of nature can be extended to include any such things. The supernatural by definition is so hopelessly beyond any understanding, consistency or prediction that science cannot include it because no progress in understanding can be made.
I am of the position that a piece of knowledge that is totally, 100% useless should be ignored. Since every piece of knowledge in the natural world can contribute to extending general knowledge about nature to at least some small degree, only the supernatural fits that requirement. Thus purely supernatural knowledge is not worth having. I'm not sure that it's even possible to have; there's no way to rationalize confidence without consistency.
I think you're making a category error; methods are not the same as the foundations for those methods.
Well, you were saying earlier that belief in a God had been a useful method of furthering scientific progress, such as by inspiring Kepler. Personally, I think that usefulness is an important foundation for choosing a method.
In the end, atheism and theism are the only two worldviews possible.
Yeah, I guess in the same way that believing the world to be flat or not are the only two worldviews possible. It's just one of many belief options that exist in a finite set. So?
Some historians of science have argued that it was because of the idea of a rational God that the idea arose that nature was ordered and could be fathomed, particularly through observation and testing.
I won't argue against the idea that religion and even belief in a God could've been quite useful in the history of science. Still, just because something was useful in the past does not mean that it is still as useful today; it doesn't mean that there aren't better alternatives available now. Dictatorial monarchies used to be quite popular, and they also did a lot to further civilization with stability (such as with the amortization of military cost and control). Religious monarchies also gave their rulers a kind of legitimacy (in the eyes of their subjects) that force alone could not. Nowadays, such a system would be considered inefficent and harmful to its citizens because we've found better ways. Todays methods have their own problems and should be replaced in the future when we've discovered something better.
One of the main foundations of science is that there is a constant search to replace old (but necessary) assumptions with new more correct ones and to augment old theories with new ones to expand their reach. The idea is that everything is under constant scrutiny; nothing is so holy as to be beyond question. One major clash with religion is that religions seem to put themselves above this scrutiny, i.e. that God is not to be questioned or tested. This represents an artificial dead end that does not exist in any other system of knowledge. To accept some religious interpretation without that process of endless questioning and progress would be a disaster in scientific terms since it is a point, beyond which, no progress can be made.
I'll go so far as to argue that denying the existence of God is actually hindering science. Why? Because atheism a priori denies the existence of an intelligence far greater than man's and therefore denies the possibility of design in nature.
The problem is that all the strongly monotheistic religions place God not as "far greater than man" but as infinitely greater. Some people have a problem with an entity that is infinitely anything. Personally, I'm a weak atheist, i.e. open to the possibility of some greater power existing but have yet to find any reason to believe. I can't say more about this because you haven't been very clear about what you mean by "God"; I'm afraid that there are many different definitions, each with its own varied level of depth.
There's no evidence for [aliens] yet the search goes on.
The whole idea of a search is to explore a possibility. If we were certain that a specific alien society existed, we wouldn't need SETI. Since it'd be impossible to prove that aliens didn't exist (or even be confident of that without much more knowledge of the Universe) the only logical option remaining is to explore the possibility as a contingency.
Makes me wonder if we are near the edge of what humans can know. Growing up, I took it on fiath that it was just a matter of time before we knew it all. Now, I am not so sure. Perhaps our monkey brains simply can't conceive of the true nature of reality.
Yeah, I suppose there is a limit to what our brains can handle. Still, the limiting factor for all of human history hasn't been our own minds nearly as much as our society and pre-existing knowledge (including educational methods). Human biology was the same, say 1000 years ago, but we're making progress at a MUCH faster rate today than we did then.
Even when we've refined our processes such that our brains (as they are now) actaully become the limiting factor, I'm sure that workarounds will become available, such as genetic engineering, implants or AI.
As for knowing EVERYTHING, wouldn't the storage required for that be no less than the entire state of the Universe, and so be the same as the Universe? i.e. knowing everything will always be an unreachable goal. As interconnected and deep as everything in the Universe is, the "true nature of reality" may be no less complex. The question is if we still have avenues of progress available, and I think the answer is yes.
Colonizing space means abandoning a perfectly serviceable planet to pursue a simple-minded superstitious belief: that it is physically feasible and statistically likely to find one or more places that are better than earth, and transport significant numbers of people at an affordable cost.
I don't think anyone's suggesting we abandon the Earth (i.e. leave no one behind) unless there was some kind of enormous disaster.
Personally, I think if we are going to be living somewhere other than the Earth, it's not going to be on planets but in space stations. Planets and such will be useful for their raw materials, which can be extracted in an automated way. Due to the lack of gravity, construction materials will be much lighter than terrestrial buildings. Although we'll have to maintain the entire environment where people will be living explicitly, the volume of that environment will be much smaller. One problem I can see is radiation: the Earth's magnetic field and atmosphere blocks a lot of radiation that a space station would be exposed to.
The pollution that is causing problems on Earth will be a non-issue since the sheer volume of space available out there will make dumping easy; the tragety of the commons problem we have right now in the environment would essentially go away. Space (with virtually unlimited volume) would be the only unavoidable common left.
At the moment, it cannot be done.
No, I don't think the technology exists today either. Still, even going into space was impossible some 50 years ago. As I see it, there are two major hurdles that need to be fixed before living in space becomes an option: we need be able to build closed living systems that don't need outside support; every attempt of building one that I know of has failed in some way, and we need to make overcoming the Earth's gravity considerably cheaper.
As for why, I think that hedging against some kind of catastrophe (possibly caused by us) that endangers our survival but wouldn't affect people living offworld. An alternative to this, sealed underground vaults should also be considered (although the closed system problem would still have to be fixed).
People who believe in terraforming are implicitly claiming that even though we cannot maintain sustainable conditions on a planet with plenty of water, oxygen, plant and animal species, and free energy from the sun, we can build a similar environment elsewhere that would require interplanetary transport of enormous quantities of water, nitrogen, soil, plant and animal species, building tools and materials etc.
I don't think you'd want any animals out there, except as a luxury. They don't provide any net production. Plants, yes. Bacteria, yes. I would think that the water, oxygen, nitrogen, carbon, etc could be mostly recycled. Energy would certainly come from the sun.
I think the idea is that such a system could exist outside because many of the irrational issues we have here that are causing sustainability problems could be avoided up there. Population could be carefully controlled. Survivial would be everyone's problem and doing it wrong would manifest very quickly and predictibly, unlike here.
At the source level, technically NT's security subsystem is just one module among many. There is an opaque SECURITY_DESCRIPTOR structure that describes access control on all securable objects, and an opaque token system to confer identities and privileges to a process or thread. Modifying these and making access checks with them are done through opaque functions. If one had the source code for Windows available, it probably would be possible to change the security system quite a bit and recompile; then the only issue would be compatibility and cleanup of code that incorrectly depends on the current implementation. Unfortunately, with only the binaries available, it'd be really hard to make more than small changes since a lot of code depends on at least the size of those structures. However, I would think that patching the standard functions for token management and access checks would make some modest changes feasible. As others have said, if file access is your main focus for security, a filesystem filter is the right choice. It won't work for any other type of object, though.
That said, NT's security model since 2000 is actually quite flexible-- much moreso than Microsoft takes advantage of itself (although this is beginning to change in Vista). With restricted tokens, you can give a process an intersection of authority, like between a person's authority and an application's. For example, you could give your e-mail client only the access that you have personally AND that e-mail applications have (such as mailbox directories).
Software restriction policies can be used to create a white or blacklist of allowed binaries, either by path, hash or signature. One thing I've done for clients in the past is to prevent execution for any binaries (regardless of permissions assigned to the files) in their own profile and possibly any location they can write to. This cuts down on virus attachments a lot, since your own profile is where the files download to by default.
If you're really ambitious, you could create your own environment subsystem whose processes have no security identity (and so are unable to open objects directly), using your own server process to proxy all authorization requests however you want, thus avoiding the kernel's security mechanisms.
In closing, I'm afraid NT was never designed to have a pluggable authorization system. LSA does support pluggable authentication packages, though.
It stayed the same up to 2003 and has now changed a tiny bit; somebody took the time to add a little font preview box, but didn't bother to actually update the ancient file picker. Note that you have to enable the "classic menus" option to even reach this dialog box. The vista dialog is also much slower: the font preview box shows a progress bar while it loads the system font directory, whereas the one in 2003 seems to do the same thing instantly.
When Microsoft moved GDI and much of the windowing system out of winsrv.dll in user mode and into win32k.sys in kernel mode, performance was a big reason, but simplification of the design is arguably an even bigger reason. NT has a lightweight (though undocumented) local procedure call facility for processes like csrss to communicate with their clients that uses double buffering for small messages (240 bytes or less) and shared memory for larger ones. NT 3.51 even implemented Quick LPC with scheduling control similar to Solaris doors (see EventPairs). Even so, communicating the state of one process to another requires quite a bit of marshalling. Every piece of data you need to send has to be known about ahead of time, and has to be either small, pre-packaged in or copied into a shared memory section.
When NT 4.0 moved most of that into kernel mode, all of that marshalling became unnecessary because the code in win32k could now reach directly into the caller's memory, same addresses and everything. In its place only some basic security against invalid addresses and memory change races were neessary. In 3.51, winsrv.dll was the largest file in the OS at almost 1.4MB. Even with NT4's new featuers the size of win32k.sys was only 1.2MB with winsrv.dll now only 150KB. Microkernels tend to have more performance overhead, but they also tend to have more development and code overhead that CAN be much more expensive in the long term.
Fittingly, the next NT release, Windows NT 4.0, became known as the Shell Update Release (SUR), another challenging task that would once again prove the benefits of NT's module architecture. "We wanted to build a desktop that had the 95 shell but used NT technology," Lucovsky told us. "We eventually moved the Win32 GUI components and hosted them as an in-process driver. Performance was one side effect. We had had problems taking that API and running it in a different process. So moving the code to the same context as the runtime solved a lot of issues. We didn't have to do dead lock detection for GDI and USER. It was significant work, but it solved a lot of headaches." NT 4.0, a watershed release for the product, shipped in July 1996.
It depends on the state, but 47 require some kind of liability insurance. Hereare a couple of articles about it from the Insurance Information Institute. Some states allow a bond or CD of about $50k instead of insurance, but that involves tying up a lot of money.
Since Windows NT 3.51, desktop objects have been the security barrier for USER and GDI objects like the window objects required for a shatter attack. Each desktop has a security desciptor which makes them fully securable. Microsoft documentation clearly specifies that privileged processes shouldn't create windows on the default interactive desktop. According to the design, it is a security error to put two windows on the same desktop which belong to processes of different privilege levels, the exact situation that a shatter attack requires to work. The fact that many pieces of software choose to disregard this is not a problem with the design of Windows's security system.
Since Windows 2000, the JOB_OBJECT_UILIMIT_HANDLES job restriction can be used to put unprivileged processes into a UI sandbox on a desktop where privileged processes have windows open. Shatter attacks won't work when the malicious process can't get a handle to the target window.
Slashdot Mirror
The thing is that efficiency and production are not at odds with humanity. A standard of living costs resources that have to come from somewhere. If production is not valued, then there will exist no means to provide humanity. It's nice to say that there are people who are too rich, earning far more than they produce while others languish in poverty and that those resources should be diverted by force. Those people would be equalized-- for a while. Tomorrow when the productive people realize that their personal rewards for productivity can and will be plundered by force if and when they become too successful, they'll become disaffected (to say the least).
This is all part of a larger system, the best one we know about for maximizing production (along with quality of life). Sure, it's got ugly parts and cases where it fails, but until a better system is shown to work, we'll have to live with this one.
If a person is guaranteed a minimum standard of living regardless of output, what's to prevent that person from doing absolutely no work? What if the standard is high enough that a majority of people decide it's good enough, greatly lowering total production (and with it resources available for living)?
NT does have an "everything is an object" metaphor, at least for things exported from kernel to user mode. The Object Manager defines a class for such objects, of which object types are subclasses. Kernel mode components are free to define their own object types. The Object Manager defines the interface for common object functions and the owner of each specific object type defines an interface for specific functions (usually by way of syscalls).
Each object type has a set of function pointers for optional methods that the object type (the object class) can choose implement to override the standard object behavior. Every object has an optional name in the unified hierarchical object namespace, and can choose to become an extension of that namespace by implementing the Parse method. Every object has a security descriptor, which the Object Manager can handle automatically, or the object itself can handle when the Security method is implemented. An object can also be synchronized against (have a thread wait for signalling) by using an appropriate dispatcher header, or not by always denying SYNCHRONIZE access. The Object Manager also provides a unified method of sharing objects between processes by way of duplicating handles, which the object type can participate in by implementing the Open and Close methods.
As for subclassing, the object type would have to provide its own support. The IO Manager can do this in a way with device and file objects. A device object is backed by a layered set of drivers that implement different functions by passing a user request (an IRP) down the device stack where each driver can modify or split the request as necessary. Each driver in the stack could represent different classes, with the bottommost driver being the base class and the topmost driver the most derived class, free to override any operation. With the device as the class, the files created from it are the objects, and the functions IOCTLs. Constructor arguments can be implemented by the filename or with extended attributes (like TDI does it). With some conventions, it would be possible to implement a full class-object system in this way.
See:
Object Manager, Microsoft Windows Internals (Fourth Edition)
Um, device drivers certainly DO NOT depend on Win32. Win32 is an environment subsystem that sits on top of the NT native API, which combined with other kernel mode functions, are what device drivers use. Up until NT4, Win32 was implemented entirely in user mode; drivers couldn't call into Win32 then and they don't now. There is no interface to call Win32 functions from kernel mode; there are no Win32 headers in the DDK. The new UMDF is designed for code written in C++ using COM. Win32 is supported, but IDK if using the CLR (i.e. .NET) is possible.
.NET. Technically, this would be possible by creating a .NET environment subsystem independent of Win32, and moving core components over to the .NET subsystem. The performance of graphics and sound systems needn't suffer; they'd just go through an API translation layer (like the one that has always existed from Win32 to the native api). Unfortunately, at this point Microsoft seems to have invested so much into Win32 that it'll probably stay where it is for the lifetime of NT.
.NET, each using the same interfaces for system services. Realistically, they'd continue to use Win32 plus some extra functions. Reactos is planning a real Java subsystem, however.
You're right that there is a huge dependency on Win32, though. All user-mode software in and for Windows depends on Win32 except the Session Manager, autochk and a few third-party boot time defragmenters. I, too, had once hoped that Win32 with its ugliness could become depreciated, secondary to something better such as
As for competing VMs like Java, ideally they would each be built inside their own subsystem independent of either Win32 or
When the seperate common and user specific program shortcuts were introduced in NT 3.1, the different types of program groups did in fact have different icons. Fig 1. When the new "Chicago" Win95 shell was created (originally 95 didn't even support multiple profiles) that concept was lost, even when multiple profile support was eventually added and the shell was ported to NT4.
It's inconvenient, but you can find out where the shortcut is located in its general properties (right click).
The main reason there are seperate folders combined at the last minute is for roaming profiles. A user profile contains their personal shortcuts to programs, but those programs may not be installed on every machine the person logs on to. When the local and user shortcut directories are used proprely, the user always sees the correct combination of programs available; the user profile contains only things available anywhere on the network or part of the OS, and the machine's "All Users" profile contains things installed on the computer.
This behavior dates back to NT 3.1 with seperate computer and user program group types and network profiles.
Maybe the problem is having buffering seperate from the TCP stack; in the TDI model, buffering is done above TDI, currently in the kernel-mode socket layer afd.sys. I was under the impression that AFD would continue to serve the same functions as before, including buffering, however. This diagram[1] seems to support that position; AFD is still between user mode and NGTCP/IP.
Technical details seem to be a little hard to come by, but the pages I could find are all about performance tweaks (mostly more automatic tuning) and new functionality, all at what TDI would consider the transport level (now broken into transport, network (addressing) and framing layers in NGTCP/IP). TDI doesn't care about how tcpip.sys is implemented internally, which is what these changes seem to be all about.
I did notice that afd.sys is now dependent on a new file: netio.sys, which is dependent on the new msrpc.sys. RPC in the kernel? That's new; it's been a required service since NT4 but implemented in user mode until now. The new tcpip.sys is also directly dependent on these new drivers. As expecetd, tcpip.sys is no longer uses tdi.sys, and user processes no longer hold TCP device handles for TDI context; everything goes through AFD now. I think there may be more going on under the covers than simple performance and management improvements.Well put. I'm a bit saddened that some of NT's elegant, innovative (and largely unknown) design features are being steamrolled for the sake of expediency, but I can see the reasoning from the perspective of actually selling the OS.
[1]Next Generation TCP/IP Stack in Windows Vista and Windows Server "Longhorn"
Performance Enhancements in the Next Generation TCP/IP Stack
Windows Vista Networking
From the October 2000 MSDN magazine, "Windows Sockets 2.0: Write Scalable Winsock Apps Using Completion Ports" Ironically, it's TDI that's being replaced for something more sockets-like.
I think this is yet another example of Microsoft not understanding code that was previously written by someone no longer available, causing the new developers to misunderstand the original design, who then feel the only option is a rewrite. I've yet to hear any technical comparisons between TDI and "Next Generation TCP/IP", showing how the TDI architecture could never do those things. I bet TDI can support these new features with some new code, but it just wouldn't be as glamorus that way.
To adapt an old saying about LISP and UNIX, "Those who fail to understand NT are doomed to reimplement it. Poorly"
If you're asking for a queue arrangement, how about shared memory for data transfer and an IO completion port for synchronization? IOCPs are great for async IO as well, and can schedule a set number of active threads, even taking into account the number currently sleeping.
Actually, alt. file streams ARE used for extra summary data. Right click on some file from the shell, open properties, and click on the Summary tab. Each of the data fileds you see are stored in their own alternate file stream.
I remember that one of the promised features of Windows 2000 was a great increase in metadata; this is one of the few surviving remnants. Since 2000, Windows has shipped with a file indexing service with the same end goal of Spotlight in OSX. Some of the summary fields, i.e. the keywords field, were obviously meant to aid the indexer. I'm pretty sure it's possible to define your own tags as well, somehow.
Yeah, sorry. Looking back, I went over the top a bit. You're absolutely right about Microsoft not following their own best practices in many cases. Microsoft's marketing likes to say that Windows is highly integrated, but it's actaully many different pieces, of different quality levels, done by different people that don't really understand each other's components. This is just one of the many cases where Microsoft puts in a good backend but botches the last mile; the security features are there but the shell people don't undestand how the system is supposed to work. I'd also have to agree that the shell (of which IE is a part) is one of the least secure subsystems.
I've used multiple desktops before, but usually to insulate something less trusted from my main desktop. Winlogon uses a seperate desktop for the logon screen and one for screen savers. Every non-interactive service gets its own desktop as well. Otherwise, I'm not aware of anything that uses multiple desktop objects.
In the olden days when NT's security system was designed (same for classic UNIX security), users were given access rights; the user's processes got those rights because they were trusted to represent the user faithfully. Now with application vulnerabilities on the Internet and users that run software they shouldn't be trusting, users are finding that they need to be protected from their own applications. This was not seriously considered in the old model.
Yes, you're right: Microsoft already created a new, modern OS to fix otherwise basic design problems in the old one. Unfortunately, the only supported API on that OS, Win32, was based very heavily on Win16 (it even boasted almost full source-level compatibility with Win16 if you followed the rules) and brought obsolete, harmful conventions with it that Microsoft still can't get rid of. It also didn't help that a subset of Win32 was ported to the old OS line in Windows 95, and was THE Microsoft consumer OS line until 2001.
What came with Win32 were single-user conventions that don't include any local security or discrete users. There are lots of pieces of software for Win32 that require the system to go into single-user emulation mode, requiring administrator access all the time and the use of only one user profile. Most programs just ignore the new SecurityDescriptor, DesiredAccess etc. parameters of Win32 create functions-- the security parameters that Win16 didn't have, and Win95 doesn't implement.
Win32 also brought the old and quirky windowing system where parameters are packed into type-unsafe blobs, multiple messages represent the same thing slightly differently, messaging order is often strange but preserved for compatibility (i.e. WM_MINMAXINFO being sent before WM_NCCREATE or WM_CREATE), and many other inconsistencies. Not to mention that just having two applications of different privilege levels display windows on the same desktop represents a security vulnerability, again for historical reasons predating Win32.
Creating NT was certainly a clean break from the earlier OS line. IMO, it's an architecture worth keeping. Win32 as an operating environment compared to Win16, wasn't revolutionary and IMO needs to go. Half-implementations of Win32 didn't help any; the Win95 implementation level of Win32 still needs to be phased out.
Bzzzt, wrong. As I said before, desktop objects are the security barrier between windows (and their messages). Every window is owned by a thread; messages to the window are posted to that thread's message queue. Every thread that can participate in window messaging is associated with a desktop object. A thread can only send or recieve messages to and from windows on the same desktop it is associated with. A window message cannot be sent without a destination window on a specific desktop. A thread can only be associated with a desktop if that desktop has been opened with sufficient access. The process of opening a desktop includes a check against the desktop's security descriptor. Microsoft guidelines have always warned against putting windows of different privilege levels on the same desktop because of the possibility of the harmful interaction it allows. As long as apps are following those guidelines, there is no way for a unprivileged malicious program to send arbitrary messages to a privileged process.
The most a process could be expected to be tolerant of is arbitrary user input, but even then the security model doesn't require a user's applications running with that user's authority to be protected from the user himself. The only programs that need to be immune to user input are ones that are trusted by the OS, yet interact directly with the user. Winlogon is the only process that fits that description. (Note that Winlogon has its own desktop to protect itself from any messages coming from the user's processes.)
There's no argument that Win32's messaging system is old and quite ugly, but to say it's an inescapable security hazard isn't true. When used properly, there's no vulnerability. Win32 is not X-Windows.
Look up shatter attacks. It's the same idea, and they're inaccurate for the same reasons.
A few choice quotes:
If you want to go back to the OSes NT and OSX are based on, the NT core is based on VMS's design (almost as much as OSX from Mach, though OSX actually uses code from Mach, whereas NT has VMS's developers) and VMS was first released in 1978. Since NT was released, its core has undergone almost no changes. The biggest one was with Plug+Play supplementing device detection and power management.
NT was designed with security in mind. Note that the NT core itself doesn't define a security policy, it just gives you the API to implement such policies. I'll admit that Microsoft has been known to have somewhat crappy defaults for security and sometimes bad tools for fixing it. This isn't really a design problem in the OS, though.
There are 3 places (at most) that applications can put their files in order to be following the rules that Microsoft has been publishing since at least NT 3.1:
This is similar to the unix policy, except that unix usually specifies a specific dir for application binaries. I don't see how this is 'all over your system'. Doesn't OSX have any shared libraries? How are these installed? Besides, since at least the year 2000, the Windows Installer has been the standard (and recently the only MS sanctioned way) to install, which hides all these details, and allows unprivileged installation. Domain admins can even publish .msi packages on the domain which unprivileged users can install at their option (that or the admins can make installation mandatory and unattended). IIRC, the designed for Vista logo will only be possible for apps that can install unprivileged (unless they are administration type tools useless to normal users). If the article is referring to misbehaving apps, then that's hardly Microsoft's fault. Microsoft has long published 'designed for' logo requirements that are not unreasonable for their OSes.
I'm not sure how installation conventions are related to inter-process communication, though. Processes create named objects for IPC and specify their own security descriptor at that time. Any other process that wants to open that named object must be granted access according to the SD specified by the object's creator. Every type of IPC is ultimately protected by a security descriptor. Even windows, which recieve window messages exist in a desktop object which the calling process must be granted access to according to t
Windows NT and its derivatives (2000, XP) have always had a properly seperated user/admin security model. It's just that a all the momentum of programming in a single-user environment like DOS or Win9x has been letting devs and users flaunt the principles of privilege seperation. For example, the games that insist on installing a kernel mode driver for the sake of copy protection just to run an application, something that non-idiot unix users would never permit. Sony's rootkit wouldn't work without admin privileges on Windows either. Many users run as admin all the time just out of expedience; it's too much work (if th user even knows how) to coddle the bad apps by elevating their privileges all the time.
This is a cultural problem (with its momentum), not a technical one.
Objects exported from kernel mode to user mode all use the same handle system for reference tracking. Each object has its own type that has both common attributes with all types and its own unique behavior. These types include files as above, processes, threads, events, mutexes, semaphores, jobs, shared memory sections, LPC ports, registry keys, object directories and object symlinks. Every object has common object attributes, including security descriptor with the same functions for setting, getting and making access checks against them. Every object can have a name (some types don't require their objects to be named) in a unified single root namespace. Every object type has its own functions for creating and opening objects, with whatever special requirements for each. Each object type that has properties has set and query functions for that type, with one information class number and structure for each property.
Every syscall uses the same basic datatypes and returns the same NTSTATUS format error/status code. All strings are counted unicode. All times are the same format (Win32 calls it FILETIME). All functions, strutures, enums, etc. use the same naming conventions. All IO operations use the same IO_STATUS_BLOCK structure. All async IO operations allow completion syncronization by waiting on the file object, signalling an event, queueing an APC or IoCompletion. All buffers are allocated by the caller and use byte buffer lengths. Every type of explicit blocking (except LPC ports) has an optional timeout and option to wait alertably.
Even though NT's release was 13 years ago, the core design has never changed, only expanded for new features, because it was done right in the first place. NT never had to tack on security or in-process multithreading or asyncronous IO (like UNIX has) because those things have been there from the beginning.
If you're complaining about the quantity of syscalls, according to arch/i386/kernel/entry.S in Linux 2.6.7, it's 284: 1 less than XP's 285.
Science is built upon making predictions out of an understandible and consistent universe. Science and the realm of nature can be extended to include any such things. The supernatural by definition is so hopelessly beyond any understanding, consistency or prediction that science cannot include it because no progress in understanding can be made.
I am of the position that a piece of knowledge that is totally, 100% useless should be ignored. Since every piece of knowledge in the natural world can contribute to extending general knowledge about nature to at least some small degree, only the supernatural fits that requirement. Thus purely supernatural knowledge is not worth having. I'm not sure that it's even possible to have; there's no way to rationalize confidence without consistency. Well, you were saying earlier that belief in a God had been a useful method of furthering scientific progress, such as by inspiring Kepler. Personally, I think that usefulness is an important foundation for choosing a method. Yeah, I guess in the same way that believing the world to be flat or not are the only two worldviews possible. It's just one of many belief options that exist in a finite set. So?
One of the main foundations of science is that there is a constant search to replace old (but necessary) assumptions with new more correct ones and to augment old theories with new ones to expand their reach. The idea is that everything is under constant scrutiny; nothing is so holy as to be beyond question. One major clash with religion is that religions seem to put themselves above this scrutiny, i.e. that God is not to be questioned or tested. This represents an artificial dead end that does not exist in any other system of knowledge. To accept some religious interpretation without that process of endless questioning and progress would be a disaster in scientific terms since it is a point, beyond which, no progress can be made.The problem is that all the strongly monotheistic religions place God not as "far greater than man" but as infinitely greater. Some people have a problem with an entity that is infinitely anything. Personally, I'm a weak atheist, i.e. open to the possibility of some greater power existing but have yet to find any reason to believe. I can't say more about this because you haven't been very clear about what you mean by "God"; I'm afraid that there are many different definitions, each with its own varied level of depth.The whole idea of a search is to explore a possibility. If we were certain that a specific alien society existed, we wouldn't need SETI. Since it'd be impossible to prove that aliens didn't exist (or even be confident of that without much more knowledge of the Universe) the only logical option remaining is to explore the possibility as a contingency.
Even when we've refined our processes such that our brains (as they are now) actaully become the limiting factor, I'm sure that workarounds will become available, such as genetic engineering, implants or AI.
As for knowing EVERYTHING, wouldn't the storage required for that be no less than the entire state of the Universe, and so be the same as the Universe? i.e. knowing everything will always be an unreachable goal. As interconnected and deep as everything in the Universe is, the "true nature of reality" may be no less complex. The question is if we still have avenues of progress available, and I think the answer is yes.
Personally, I think if we are going to be living somewhere other than the Earth, it's not going to be on planets but in space stations. Planets and such will be useful for their raw materials, which can be extracted in an automated way. Due to the lack of gravity, construction materials will be much lighter than terrestrial buildings. Although we'll have to maintain the entire environment where people will be living explicitly, the volume of that environment will be much smaller. One problem I can see is radiation: the Earth's magnetic field and atmosphere blocks a lot of radiation that a space station would be exposed to.
The pollution that is causing problems on Earth will be a non-issue since the sheer volume of space available out there will make dumping easy; the tragety of the commons problem we have right now in the environment would essentially go away. Space (with virtually unlimited volume) would be the only unavoidable common left.
No, I don't think the technology exists today either. Still, even going into space was impossible some 50 years ago. As I see it, there are two major hurdles that need to be fixed before living in space becomes an option: we need be able to build closed living systems that don't need outside support; every attempt of building one that I know of has failed in some way, and we need to make overcoming the Earth's gravity considerably cheaper.
As for why, I think that hedging against some kind of catastrophe (possibly caused by us) that endangers our survival but wouldn't affect people living offworld. An alternative to this, sealed underground vaults should also be considered (although the closed system problem would still have to be fixed).I don't think you'd want any animals out there, except as a luxury. They don't provide any net production. Plants, yes. Bacteria, yes. I would think that the water, oxygen, nitrogen, carbon, etc could be mostly recycled. Energy would certainly come from the sun.
I think the idea is that such a system could exist outside because many of the irrational issues we have here that are causing sustainability problems could be avoided up there. Population could be carefully controlled. Survivial would be everyone's problem and doing it wrong would manifest very quickly and predictibly, unlike here.
At the source level, technically NT's security subsystem is just one module among many. There is an opaque SECURITY_DESCRIPTOR structure that describes access control on all securable objects, and an opaque token system to confer identities and privileges to a process or thread. Modifying these and making access checks with them are done through opaque functions. If one had the source code for Windows available, it probably would be possible to change the security system quite a bit and recompile; then the only issue would be compatibility and cleanup of code that incorrectly depends on the current implementation. Unfortunately, with only the binaries available, it'd be really hard to make more than small changes since a lot of code depends on at least the size of those structures. However, I would think that patching the standard functions for token management and access checks would make some modest changes feasible. As others have said, if file access is your main focus for security, a filesystem filter is the right choice. It won't work for any other type of object, though.
That said, NT's security model since 2000 is actually quite flexible-- much moreso than Microsoft takes advantage of itself (although this is beginning to change in Vista). With restricted tokens, you can give a process an intersection of authority, like between a person's authority and an application's. For example, you could give your e-mail client only the access that you have personally AND that e-mail applications have (such as mailbox directories).
Software restriction policies can be used to create a white or blacklist of allowed binaries, either by path, hash or signature. One thing I've done for clients in the past is to prevent execution for any binaries (regardless of permissions assigned to the files) in their own profile and possibly any location they can write to. This cuts down on virus attachments a lot, since your own profile is where the files download to by default.
If you're really ambitious, you could create your own environment subsystem whose processes have no security identity (and so are unable to open objects directly), using your own server process to proxy all authorization requests however you want, thus avoiding the kernel's security mechanisms.
In closing, I'm afraid NT was never designed to have a pluggable authorization system. LSA does support pluggable authentication packages, though.
Here's the "Add Fonts" dialog from NT 3.1.
And for Vista.
For reference, Server 2003.
It stayed the same up to 2003 and has now changed a tiny bit; somebody took the time to add a little font preview box, but didn't bother to actually update the ancient file picker. Note that you have to enable the "classic menus" option to even reach this dialog box. The vista dialog is also much slower: the font preview box shows a progress bar while it loads the system font directory, whereas the one in 2003 seems to do the same thing instantly.
When NT 4.0 moved most of that into kernel mode, all of that marshalling became unnecessary because the code in win32k could now reach directly into the caller's memory, same addresses and everything. In its place only some basic security against invalid addresses and memory change races were neessary. In 3.51, winsrv.dll was the largest file in the OS at almost 1.4MB. Even with NT4's new featuers the size of win32k.sys was only 1.2MB with winsrv.dll now only 150KB. Microkernels tend to have more performance overhead, but they also tend to have more development and code overhead that CAN be much more expensive in the long term.
From Windows Server 2003: The Road To Gold Part One: The Early Years: (emphasis added)
It depends on the state, but 47 require some kind of liability insurance. Here are a couple of articles about it from the Insurance Information Institute. Some states allow a bond or CD of about $50k instead of insurance, but that involves tying up a lot of money.
Since Windows NT 3.51, desktop objects have been the security barrier for USER and GDI objects like the window objects required for a shatter attack. Each desktop has a security desciptor which makes them fully securable. Microsoft documentation clearly specifies that privileged processes shouldn't create windows on the default interactive desktop. According to the design, it is a security error to put two windows on the same desktop which belong to processes of different privilege levels, the exact situation that a shatter attack requires to work. The fact that many pieces of software choose to disregard this is not a problem with the design of Windows's security system.
Since Windows 2000, the JOB_OBJECT_UILIMIT_HANDLES job restriction can be used to put unprivileged processes into a UI sandbox on a desktop where privileged processes have windows open. Shatter attacks won't work when the malicious process can't get a handle to the target window.