System Essay, Research Paper
Windows NT vs Unix As An Operating System
In the late 1960s a combined project between researchers at MIT, Bell Labs and
General Electric led to the design of a third generation of computer operating
system known as MULTICS (MULTiplexed Information and Computing Service). It was
envisaged as a computer utility, a machine that would support hundreds of
simultaneous timesharing users. They envisaged one huge machine providing
computing power for everyone in Boston. The idea that machines as powerful as
their GE-645 would be sold as personal computers costing only a few thousand
dollars only 20 years later would have seemed like science fiction to them.
However MULTICS proved more difficult than imagined to implement and Bell Labs
withdrew from the project in 1969 as did General Electric, dropping out of the
computer business altogether.
One of the Bell Labs researchers (Ken Thompson) then decided to rewrite a
stripped down version of MULTICS, initially as a hobby. He used a PDP-7
minicomputer that no was using and wrote the code in assembly. It was initially
a stripped down, single user version of MULTICS but Thompson actually got the
system to work and one of his colleagues jokingly called it UNICS (UNiplexed
Information and Computing Service). The name stuck but the spelling was later
changed to UNIX. Soon Thompson was joined on the project by Dennis Richie and
later by his entire department.
UNIX was moved from the now obsolete PDP-7 to the much more modern PDP-11/20 and
then later to the PDP-11/45 and PDP-11/70. These two latter computers had large
memories as well as memory protection hardware, making it possible to support
multiple users at the same time. Thompson then decided to rewrite UNIX in a
high-level language called B. Unfortunately this attempt was not successful and
Richie designed a successor to B called C. Together, Thompson and Richie rewrote
UNIX in C and subsequently C has dominated system programming ever since. In
1974, Thompson and Richie published a paper about UNIX and this publication
stimulated many universities to ask Bell Labs for a copy of UNIX. As it happened
the PDP-11 was the computer of choice at nearly all university computer science
departments and the operating systems that came with this computer was widely
regarded as being dreadful and hence UNIX quickly came to replace them. The
version that first became the standard in universities was Version 6 and within
a few years this was replaced by Version 7. By the mid 1980s, UNIX was in
widespread use on minicomputers and engineering workstations from a variety of
vendors.
In 1984, AT&T released the first commercial version of UNIX, System III, based
on Version 7. Over a number of years this was improved and upgraded to System V.
Meanwhile the University of California at Berkeley modified the original Version
6 substantially. They called their version 1BSD (First Berkeley Software
Distribution). This was modified over time to 4BSD and improvements were made
such as the use of paging, file names longer than 14 characters and a new
networking protocol, TCP/IP. Some computer vendors like DEC and Sun Microsystems
based their version of UNIX on Berkeley’s rather than AT&T’s. There was a few
attempts to standardise UNIX in the late 1980s, but only the POSIX committee had
any real success, and this was limited.
During the 1980s, most computing environments became much more heterogeneous,
and customers began to ask for greater application portability and
interoperability from systems and software vendors. Many customers turned to
UNIX to help address those concerns and systems vendors gradually began to offer
commercial UNIX-based systems. UNIX was a portable operating system whose source
could easily be licensed, and it had already established a reputation and a
small but loyal customer base among R&D organisations and universities. Most
vendors licensed source bases from either the University of California at
Berkeley or AT&T(r) (two completely different source bases). Licensees
extensively modified the source and tightly coupled them to their own systems
architectures to produce as many as 100 proprietary UNIX variants. Most of these
systems were (and still are) neither source nor binary compatible with one
another, and most are hardware specific.
With the emergence of RISC technology and the breakup of AT&T, the UNIX systems
category began to grow significantly during the 1980s. The term “open systems”
was coined. Customers began demanding better portability and interoperability
between the many incompatible UNIX variants. Over the years, a variety of
coalitions (e.g. UNIX International) were formed to try to gain control over and
consolidate the UNIX systems category, but their success was always limited.
Gradually, the industry turned to standards as a way of achieving the
portability and interoperability benefits that customers wanted. However, UNIX
standards and standards organisations proliferated (just as vendor coalitions
had), resulting in more confusion and aggravation for UNIX customers.
The UNIX systems category is primarily an application-driven systems category,
not an operating systems category. Customers choose an application first-for
example, a high-end CAD package-then find out which different systems it runs on,
and select one. The final selection involves a variety of criteria, such as
price/performance, service, and support. Customers generally don’t choose UNIX
itself, or which UNIX variant they want. UNIX just comes with the package when
they buy a system to run their chosen applications.
The UNIX category can be divided into technical and business markets: 87% of
technical UNIX systems purchased are RISC workstations purchased to run specific
technical applications; 74% of business UNIX systems sold are
multiuser/server/midrange systems, primarily for running line-of-business or
vertical market applications.
The UNIX systems category is extremely fragmented. Only two vendors have more
than a 10% share of UNIX variant license shipments (Sun(r) and SCO); 12 of the
top 15 vendors have shares of 5% or less (based on actual 1991 unit shipments,
source: IDC). This fragmentation reflects the fact that most customers who end
up buying UNIX are not actually choosing UNIX itself, so most UNIX variants have
small and not very committed customer bases.
Operating System Architecture
Windows NT was designed with the goal of maintaining compatibility with
applications written for MS-DOS, Windows for MS-DOS, OS/2, and POSIX. This was
an ambitious goal, because it meant that Windows NT would have to provide the
applications with the application programming interfaces (API) and the execution
environments that their native operating systems would normally provide. The
Windows NT developers accomplished their compatibility goal by implementing a
suite of operating system environment emulators, called environment subsystems.
The emulators form an intermediate layer between user applications and the
underlying NT operating system core.
User applications and environment subsystems work together in a client/server
relationship. Each environment subsystem acts as a server that supports the
application programming interfaces of a different operating system . Each user
application acts as the client of an environment subsystem because it uses the
application programming interface provided by the subsystem. Client applications
and environment subsystem servers communicate with each other using a message-
based protocol.
At the core of the Windows NT operating system is a collection of operating
system components called the NT Executive. The executive’s components work
together to form a highly sophisticated, general purpose operating system. They
provide mechanisms for:
Interprocess communication.
Pre-emptive multitasking.
Symmetric multiprocessing.
Virtual memory management.
Device Input/Output.
Security.
Each component of the executive provides a set of functions, commonly referred
to as native services or executive services. Collectively, these services form
the application programming interface (API) of the NT executive.
Environment subsystems are applications that call NT executive services. Each
one emulates a different operating system environment. For example, the OS/2
environment subsystem supports all of the application programming interface
functions used by OS/2 character mode applications. It provides these
applications with an execution environment that looks and acts like a native
OS/2 system. Internally, environment subsystems call NT executive services to do
most of their work. The NT executive services provide general-purpose mechanisms
for doing most operating system tasks. However the subsystems must implement any
features that are unique to the their operating system environments.
User applications, like environment subsystems, are run on the NT Executive.
Unlike environment subsystems, user applications do not directly call executive
services. Instead, they call application programming interfaces provided by the
environment subsystems. The subsystems then call executive services as needed to
implement their application programming interface functions.
Windows NT presents users with an interface that looks like that of Windows 3.1.
This user interface is provided by Windows NT’s 32-bit Windows subsystem (Win32).
The Win32 subsystem has exclusive responsibility for displaying output on the
system’s monitor and managing user input. Architecturally, this means that the
other environment subsystems must call Win32 subsystem functions to produce
output on the display. It also means that the Win32 subsystem must pass user
input actions to the other environment subsystems when the user interacts with
their windows.
Windows NT does not maintain compatibility with device drivers written for MS-
DOS or Windows for MS-DOS. Instead, it adopts a new layered device-driver
architecture that provides many advantages in terms of flexibility,
maintainability, and portability. Windows NT’s device driver architecture
requires that new drivers be written before Windows NT can be compatible with
existing hardware. While writing new drivers involves a lot of development
effort on the part of Microsoft and independent hardware vendors (IHV), most of
the hardware devices supported by Windows for MS-DOS will be supported by new
drivers shipped with the final Windows NT product.
The device driver architecture is modular in design. It allows big (monolithic)
device drivers to be broken up into layers of smaller independent device drivers.
A driver that provides common functionality must only be written once. Drivers
in adjacent layers can then simply call the common device driver to get their
work done. Adding support for new devices is easier under Windows NT than most
operating systems because only the hardware-specific drivers need to be
rewritten.
Windows NT’s new device driver architecture provides a structure on top of which
compatibility with existing installable file systems (for example, FAT and HPFS)
and existing networks (for example, Novell and Banyan Vines) was relatively easy
to achieve. File systems and network redirectors are implemented as layered
drivers that plug easily into the new Windows NT device driver architecture.
In any Windows NT multiprocessor platform, the following conditions must hold:
All CPUs are identical, and either all have identical coprocessors or none has a
coprocessor.
All CPUs share memory and have uniform access to memory.
In a symmetric platform, every CPU can access memory, take an interrupt, and
access I/O control registers. In an asymmetric platform, one CPU takes all
interrupts for a set of slave CPUs.
Windows NT is designed to run unchanged on uniprocessor and symmetric
multiprocessor platforms
A UNIX system can be regarded as hierarchical in nature. At the highest level is
the physical hardware, consisting of the CPU or CPUs, memory and disk storage,
terminals and other devices.
On the next layer is the UNIX operating system itself. The function of the
operating system is to allow access to and control the hardware and provide an
interface that other software can use to access the hardware resources within
the machine, without having to have complete knowledge of what the machine
contains. These system calls allow user programs to create and manage processes,
files and other resources. Programs make system calls by loading arguments into
memory registers and then issuing trap instructions to switch from user mode to
kernel mode to start up UNIX. Since there is no way to trap instructions in C, a
standard library is provided on top of the operating system, with one procedure
per system call.
The next layer consists of the standard utility programs, such as the shell,
editors, compilers, etc., and it is these programs that a user at a terminal
invokes. They use the operating system to access the hardware to perform their
functions and generally are able to run on different hardware configurations
without specific knowledge of them.
There are two main parts to the UNIX kernel which are more or less
distinguishable. At the lowest level is the machine dependent kernel. This is a
piece of code which consists of the interrupt handlers, the low-level I/O system
device drivers and some of the memory management software. As with most of the
Unix operating system it is mostly written in C, but since it interacts directly
with the machine and processor specific hardware, it has to be rewritten from
scratch whenever UNIX is ported to a new machine. This kernel uses the lowest
level machine instructions for the processor which is why it must be changed for
each different processor.
In contrast, the machine independent kernel runs the same on all machine types
because it is not as closely reliant on any specific piece of hardware it is
running on. The machine independent code includes system call handling, process
management, scheduling, pipes, signals, memory paging and memory swapping
functions, the file system and the higher level part of the I/O system. The
machine independent part of the kernel is by far the larger of the two sections,
which is why it UNIX can be ported to new hardware with relative ease.
Unix does not use the DOS and Windows idea of independently loaded device
drivers for each additional hardware item that is not under BIOS control in the
machine which is why it must be recompiled whenever hardware is added or removed,
the kernel needing to be updated with the new information. This is the
equivalent of adding a device driver to a configuration file in DOS or Windows
and then rebooting the machine. It is however a longer process to undertake.
Memory Management
Windows NT provides a flat 32-bit address space, half of which is reserved for
the OS, and half available to the process. This provides a s
of demand-paged virtual memory per process. This memory is accessible to the
software developer through the usual malloc() and free() memory allocation and
deallocation routines, as well as some advanced Windows NT-specific mechanisms.
For a programmer desiring greater functionality for memory control, Windows NT
also provides Virtual and Heap memory management APIs.
The advantage of using the virtual memory programming interface (VirtualAlloc(),
VirtualLock(), VirtualQuery(), etc.) is that the developer has much more control
over whether backing store (memory committed in the paging (swap) file to handle
physical memory overcommitment) is explicitly marked, and removed from the
available pool of free blocks. With malloc(), every call is assumed to require
the memory to be available upon return from the function call to be used. With
VirtualAlloc() and related functions, the memory is reserved, but not committed,
until the page on which an access occurs is touched. By allowing the application
to control the commitment policy through access, less system resources are used.
The trade-off is that the application must also be able to handle the condition
(presumably with structured exception handling) of an actual memory access
forcing commitment.
Heap APIs are provided to make life easier for applications with memory-using
stack discipline. Multiple heaps can be initialised, each growing/shrinking with
subsequent accesses. Synchronisation of access to allocated heaps can be done
either explicitly through Windows NT synchronisation objects, or by using an
appropriate parameter at the creation of a heap. All access to memory in that
particular heap is synchronised between threads in the process.
Memory-mapped files are also provided in Windows NT. This provides a convenient
way to access disk data as memory, with the Windows NT kernel managing paging.
This memory may be shared between processes by using CreateFileMapping()
followed by MapViewOfFile().
Windows NT provides thread local storage (TLS) to accommodate the needs of
multithreaded applications. Each thread of a subprocess has its own stack, and
may have its own memory to keep various information.
Windows NT is the first operating system to provide a consistent multithreading
API across multiple platforms. A thread is unit of execution in a process
context that shares a global memory state with other threads in that context (if
any). When a process is created in Windows NT, memory is allocated for it, a
state is set up in the system, and a thread object is created. To start a thread
in a currently executing process, the CreateThread() call is used as a function
pointer is passed in through lpStartAddr; this address may be any valid
procedure address in an application.
Windows NT supports a number of different types of multiprocessing hardware. On
these designs, it’s possible for different processors to be running different
threads an application simultaneously. Take care to use threads in an
application to synchronise access to common resources between threads.
Fortunately, Windows NT has very rich synchronisation facilities.
Most UNIX developers don’t use threads in their applications since support is
not consistent between UNIX platforms.
Handles don’t have a direct mapping from UNIX; however, they’re very important
to Win32 applications and deserve discussion. When kernel objects (such as
threads, processes, files, semaphores, mutexes, events, pipes, mailslots, and
communications devices) are created or opened using the Win32 API, a HANDLE is
returned. This handle is a 32-bit quantity that is an index into a handle table
specific to that process. Handles have associated ACLs, or Access Control Lists,
that Windows NT uses to check against the security credentials of the process.
Handles can be obtained by explicitly creating them (usually when an object is
created), as the result of an open operation (e.g. OpenEvent()) on a named
object in the system, inherited as the result of a CreateProcess() operation (a
child process inherits an open handle from its parent process if inheritance was
specified when the original handle was created and if the child process was
created with the “inherit handles” flag set), or “given away” by
DuplicateHandle(). It is important to note that unless one of these mechanisms
is used, a handle will be meaningless in the context of a process.
For example, suppose process 1 calls CreateEvent() to return a handle that
happens to have the ordinal value 0×1FFE. This event will be used to co-ordinate
an operation between different processes. Process 2 must somehow get a handle to
the event that process 1 created. If process 1 somehow “conjures” that the right
value to use is 0×1FFE, it still won’t have access to the event created by
process 1, since that handle value means nothing in the context of process 2. If
instead, process 1 calls DuplicateHandle()with the handle of process 2 (acquired
through calling OpenProcess() with the integral id of process 2), a handle that
can be used by process 2 is created. This handle value can be communicated back
to process 1 through some IPC mechanism.
Handles that are used for synchronisation (semaphores, mutexes, events) as well
as those that may be involved in asynchronous I/O (named pipes, files,
communications) may be used with WaitForObject() and WaitForMultipleObject(),
which are functionally similar to the select() call in UNIX.
Prior to 3BSD most UNIX systems were based on swapping. When more processes
existed than could be kept in physical memory, some of them were swapped out to
disk or drum storage. A swapped out process was always swapped out in its
entirety and hence any current process was always either in memory or on disk as
a complete unit.
All movement between memory and disk was handled by the upper level of a split
level scheduler, known as the (memory) swapper. Swapping from memory to disk was
initiated when the kernel ran out of free physical memory.
In order to choose a victim to evict, the swapper would first look at the
processes that were being blocked by having to wait for something such as
terminal input or a print job to respond. If more than one process was found,
that process whose priority plus residence time was the highest was chosen as a
candidate for swapping to disk. Thus a process that had consumed a large amount
of CPU time recently was a good candidate, as was one that had been in memory a
long time, even if it was mostly doing I/O. If no blocked process was available
in memory then a ready process was chosen based on the same criteria of priority
plus residence time.
Starting with 3BSD, memory paging was added to the operating system to handle
the ever larger programs that were being written. Both 4BSD and System V
implemented demand paging in a similar fashion. The theory of demand paging is
that a process need not necessarily be entirely resident in memory in order to
continue execution. All that is actually required is the user structure and the
page tables. If these are swapped into memory, the process is then deemed to be
sufficiently in memory and can be scheduled to execute. The pages of the text,
data and stack segments are brought in dynamically, one at a time, as they are
referenced, thus leaving memory free for other tasks rather than filling it with
tables of data which may be referenced only once. If the user structure and page
table are not in memory, the process cannot be executed until the swapper swaps
them into memory from disk.
Paging is implemented partly by the main kernel and partly by a process called
the page daemon. Like all daemons, the page daemon is started up periodically so
that it can look around to see if there is any work for it to do. If it
discovers that the number of free pages in memory is too low, it initiates
action to free up more pages.
When a process is started it may cause a page fault due to one of its pages is
not being resident in memory. When a page fault occurs, the operating system
takes the first page frame free on the list of page frames, removes it from the
list and reads the needed page into it. If the free page frame list is empty,
the process must be suspended until the page daemon has had time to free a page
frame from another process.
The page replacement algorithm is executed by the page daemon. At a set interval
(commonly 250 millisec but varying from system to system) it is activated to see
if the number of free page frames is at least equal to a system parameter known
as lotsfree (typically set to 1/4 of memory). If there are insufficient page
frames, the page daemon will start transferring pages from memory to disk until
the lotsfree parameter value of page frames are available. Alternatively, if the
page daemon discovers that more than lotsfree page frames are on the free list,
it has no need to perform any function and terminates until its next call by the
system. If the machine has plenty of memory and few active processes, it will be
inactive for most of the time.
The page daemon uses a modified version of the clock algorithm. It is a global
algorithm, which means that when removing a page it does not take into account
whose page is being removed. Thus the number of pages each process has assigned
to it varies in time, depending both on its own requirements and other process
requirements. The size of the data segment may vary depending upon what has been
requested, the operating system tracking allocated and unallocated memory blocks
while the memalloc function manages the content of the data segment.
Process Management, Inter-process Communication and Control
The Windows NT process model differs from that of UNIX in a number of aspects,
including process groups, terminal groups, setuid, memory layout, etc. For some
programs, such as shells, a re-architecture of certain portions of the code is
inevitable. Fortunately, most applications don’t inherently rely on the specific
semantics of UNIX processes, since even this differs between UNIX versions.
Quoting from the online help provided with the Windows NT SDK:
Win32 exposes processes and threads of execution within a process as objects.
Functions exist to create, manipulate, and delete these objects.
A process object represents a virtual address space, a security profile, a set
of threads that execute in the address space of the process, and a set of
resources or objects visible to all threads executing in the process. A thread
object is the agent that executes program code (and has its own stack and
machine state). Each thread is associated with a process object which specifies
the virtual address space mapping for the thread. Several thread objects can be
associated with a single process object which enables concurrent execution of
multiple threads in a single address space (possible simultaneous execution in a
multiprocessor system running Windows NT). On multiprocessor systems running
Windows NT, multiple threads may execute at the same time but on different
processors.
In order to support the process structure of Windows NT, APIs include:
* Support for process and thread creation and manipulation.
* Support for synchronisation between threads within a process and
synchronisation objects that can be shared by multiple processes to allow
synchronisation between threads whose processes have access to the
synchronisation objects.
* A uniform sharing mechanism that provides security features that
limit/control the sharing of objects between processes.
Windows NT provides the ability to create new processes (CreateProcess) and
threads (CreateThread). Rather than “inherit” everything always, as is done in
UNIX with the fork call, CreateProcess accepts explicit arguments that control
aspects of process creation such as file handle inheritance, security attributes,
debugging of the child process, environment, default directory, etc. It is
through the explicit creation of a thread or process with appropriate security
descriptors that credentials are granted to the created entity.
Win32 does not provide the capability to “clone” a running process (and it’s
associated in-memory contents); this is not such a hardship, since most UNIX
code forks and then immediately calls exec. Applications that depend on the
cloning semantics of fork may have to be rearchitected a bit to use threads
(especially where large amounts of data sharing between parent and child occurs),
or in some cases, to use IPC mechanisms to copy the relevant data between two
distinct processes after the CreateProcess call is executed.
If a child process is to inherit the handles of the creator process, the
bInherit flag of the CreateProcess call can be set. In this case, the child’s
handle table is filled in with handles valid in the context of the child process.
If this flag is not specified, handles must be given away by using the
DuplicateHandlecall.
Windows NT was not designed to support “dumb terminals” as a primary emphasis,
so the concept of terminal process groups and associated semantics are not
implemented. Applications making assumptions about groups of applications (for
example, killing the parent process kills all child processes), will have to
investigate the GenerateConsoleCtrlEvent API, which provides a mechanism to
signal groups of applications controlled by a parent process using the CREATE_
NEW_PROCESS_GROUP flag in the CreateProcess API.
Programs making assumptions about the layout of processes in memory (GNU EMACS,
for example, which executes, then “dumps” the image of variables in memory to
disk, which is subsequently “overlayed” on start-up to reduce initialisation
time), especially the relationship of code segments to data and stack, will
likely require modification. Generally, practices such as these are used to get
around some operating system limitation or restriction. At this level, a
rethinking of the structure of that part of the application is generally in
order, to examine supported alternatives to the “hack” that was used (perhaps
memory mapped files for particular cases like this). For those who must deal
with an application’s pages on this level, there is a mechanism by which a
process may be opened (OpenProcess), and individual memory pages, threads, and
stacks examined or modified.
There is no direct equivalent of the UNIX setuid. There are, however, a number
of Windows NT alternatives to use depending on the task to be accomplished. If
the task at hand is a daemon that runs with a fixed user context, it would be
best to use a Windows NT service (again, the online help is invaluable for this
information). A Windows NT service is equivalent to a “daemon” running with
fixed user credentials, with the added benefit of being administrable locally or
remotely through standard Windows NT administration facilities. For instances
when a process must “impersonate” a particular user, it’s suggested that a
server program be written that communicates thr
359