Windows NT (New Technology) is Microsoft's operating
system for high-end personal and server use; it is shipped
in several variants that can all be considered the same
for our purposes. All of Microsoft's operating systems
since the demise of Windows ME in 2000 have been NT-based;
Windows 2000 was NT 5, and Windows XP (current in 2003) is
NT 5.1. NT is genetically descended from VMS, with which
it shares some important characteristics.
NT has grown by accretion, and lacks a unifying
metaphor corresponding to Unix's “everything is a file” or
the MacOS
desktop.[33]
Because core technologies are not anchored in a small set
of persistent central metaphors, they become obsolete
every few years. Each of the technology generations — DOS
(1981), Windows 3.1 (1992), Windows 95 (1995), Windows NT
4 (1996), Windows 2000 (2000), Windows XP (2002), and
Windows Server 2003 (2003) — has required that developers
relearn fundamental things in a different way, with the
old way declared obsolete and no longer well supported.
There are other consequences as well:
- The GUI facilities coexist uneasily with the weak,
remnant command-line interface inherited from DOS and
VMS.
- Socket programming has no unifying data object
analogous to the Unix everything-is-a-file-handle, so
multiprogramming and network applications that are
simple in Unix require several more fundamental
concepts in NT.
NT has file attributes in some of its file system
types. They are used in a restricted way, to implement
access-control lists on some file systems, and don't
affect development style very much. It also has a
record-type distinction, between text and binary files,
that produces occasional annoyances (both NT and OS/2
inherited this misfeature from DOS).
Though pre-emptive multitasking is supported,
process-spawning is expensive — not as expensive as in
VMS, but (at about 0.1 seconds per spawn) up to an order
of magnitude more so than on a modern Unix. Scripting
facilities are weak, and the OS makes extensive use of
binary file formats. In addition to the expected
consequences we outlined earlier are these:
- Most programs cannot be scripted at all. Programs
rely on complex, fragile remote procedure call
(RPC) methods to communicate with each other, a rich
source of bugs.
- There are no generic tools at all. Documents and
databases can't be read or edited without
special-purpose programs.
- Over time, the CLI has become more and more
neglected because the environment there is so sparse.
The problems associated with a weak CLI have gotten
progressively worse rather than better. (Windows
Server 2003 attempts to reverse this trend somewhat.)
System and user configuration data are centralized in a
central properties registry rather than being scattered
through numerous dotfiles and system data files as in
Unix. This also has consequences throughout the design:
- The registry makes the system completely
non-orthogonal. Single-point failures in applications
can corrupt the registry, frequently making the entire
operating system unusable and requiring a reinstall.
- The registry creep phenomenon: as the
registry grows, rising access costs slow down all
programs.
NT systems on the Internet are notoriously vulnerable
to worms, viruses, defacements, and cracks of all kinds.
There are many reasons for this, some more fundamental
than others. The most fundamental is that NT's internal
boundaries are extremely porous.
NT has access control lists that can be used to
implement per-user privilege groups, but a great deal of
legacy code ignores them, and the operating system permits
this in order not to break backward compatibility. There
are no security controls on message traffic between GUI
clients, either,[34]
and adding them would also break backward compatibility.
While NT will use an MMU, NT versions after 3.5 have
the system GUI wired into the same address space as the
privileged kernel for performance reasons. Recent versions
even wire the webserver into kernel space in an attempt to
match the speed of Unix-based webservers.
These holes in the boundaries have the synergistic
effect of making actual security on NT systems effectively
impossible.[35]
If an intruder can get code run as any user at all (e.g.,
through the Outlook email-macro feature), that code can
forge messages through the window system to any other
running application. And any buffer overrun or crack in
the GUI or webserver can be exploited to take control of
the entire system.
Because Windows does not handle
library versioning properly, it suffers from a chronic
configuration problem called “DLL hell”, in which
installing new programs can randomly upgrade (or even
downgrade!) the libraries on which existing programs
depend. This applies to the vendor-supplied system
libraries as well as to application-specific ones: it is
not uncommon for an application to ship with specific
versions of system libraries, and break silently when it
does not have them.[36]
On the bright side, NT provides sufficient facilities
to host Cygwin, which is a compatibility layer
implementing Unix at both the utilities and the API level,
with remarkably few compromises.[37]
Cygwin permits C programs to make use of both the Unix and
the native APIs, and is the first thing many Unix hackers
install on such Windows systems as they are compelled by
circumstances to make use of.
The intended audience for the NT operating systems is
primarily nontechnical end users, implying a very low
tolerance for interface complexity. It is used in both
client and server roles.
Early in its history Microsoft relied on third-party
development to supply applications. They originally
published full documentation for the Windows APIs, and
kept the price of development tools low. But over time,
and as competitors collapsed, Microsoft's strategy shifted
to favor in-house development, they began hiding APIs from
the outside world, and development tools grew more
expensive. As early as Windows 95, Microsoft was requiring
nondisclosure agreements as a condition for purchasing
professional-quality development tools.
The hobbyist and casual-developer culture that had
grown up around DOS and earlier Windows versions was large
enough to be self-sustaining even in the face of
increasing efforts by Microsoft to lock them out
(including such measures as certification programs
designed to delegitimize amateurs). Shareware never went
away, and Microsoft's policy began to reverse somewhat
after 2000 under market pressure from open-source
operating systems and Java. However, Windows interfaces
for ‘professional’ programming continued to grow more
complex over time, presenting an increasing barrier to
casual (or serious!) coding.
The result of this history is a sharp dichotomy between
the design styles practiced by amateur and professional NT
developers — the two groups barely communicate. While the
hobbyist culture of small tools and shareware is very much
alive, professional NT projects tend to produce monster
monoliths even bulkier than those characteristic of
‘elitist’ operating systems like VMS.
Unix-like shell facilities, command sets, and library
APIs are available under Windows through third-party
libraries including UWIN, Interix, and the open-source
Cygwin.
824 S. 10th Ave 
Dealer