Windows NT Vs Unix As An Operating 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 separate 2 gigabytes

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