Page 327 - DCAP103_Principle of operating system
P. 327
Principles of Operating Systems
Notes The Win32 API philosophy is completely different from the UNIX philosophy. In the latter, the
system calls are all publicly known and form a minimal interface: removing even one of them
would reduce the functionality of the operating system. The Win32 philosophy is to provide
a very comprehensive interface, often with three or four ways of doing the same thing, and
including many functions (i.e., procedures) that clearly should not be (and are not) system calls,
such as an API call to copy an entire file.
Many Win32 API calls create kernel objects of one kind or another, including files, processes,
threads, pipes, and so on. Every call creating an object returns a result called a handle to the
caller. This handle can subsequently be used to perform operations on the object. Handles are
specific to the process that created the object referred to by the handle. They cannot be passed
directly to another process and used there (just as UNIX file descriptors cannot be passed to
other processes and used there). However, under certain circumstances, it is possible to duplicate
a handle and pass it to other processes in a protected way, allowing them controlled access to
objects belonging to other processes. Every object also has a security descriptor associated with
it, telling in detail who may and may not perform what kinds of operations on the object.
Not all system-created data structures are objects and not all objects are kernel objects. The
only ones that are true kernel objects are those that need to be named, protected, or shared in
some way. Every kernel object has a system-defined type, has well-defined operations on it,
and occupies storage in kernel memory. Although users can perform the operations (by making
Win32 calls), they cannot get at the data directly.
The operating system itself can also create and use objects and does so heavily. Most of these
objects are created to allow one component of the system to store some information for a
substantial period of time or to pass some data structure to another component. For example,
when a device driver is loaded, an object is created for it holding its properties and pointers to
the functions it contains. Within the operating system, the driver is then referred to by using
its object.
Windows 2000 is sometimes said to be object-oriented because the only way to manipulate
objects is by invoking operations on their handles by making Win32 API calls. On the other
hand, it lacks some of the most basic properties of object-oriented systems such as inheritance
and polymorphism.
The Win32 API calls cover every conceivable area an operating system could deal with, and
quite a few of it arguably should not deal with. Naturally, there are calls for creating and
managing processes and threads. There are also many calls that relate to interprocess (actually,
interthread) communication, such as creating, destroying, and using mutexes, semaphores,
events, and other IPC objects.
Although much of the memory management system is invisible to programmers (fundamentally,
it is just demand paging), one important feature is visible: namely the ability of a process to
map a file onto a region of its virtual memory. This allows the process the ability to read and
write parts of the file as though they were memory words.
An important area for many programs is file I/O. In the Win32 view, a file is just a linear sequence
of bytes. Win32 provides over 60 calls for creating and destroying files and directories, opening
and closing files, reading and writing them, requesting and setting file attributes, and much more.
Another area for which Win32 provides calls is security. Every process has an ID telling who it is
and every object can have an access control list telling in great detail precisely which users may
access it and which operations they may perform on it. This approach provides for a fine-grained
security in which specific individuals can be allowed or denied specific access to every object.
320 LOVELY PROFESSIONAL UNIVERSITY