Hardware Reference
In-Depth Information
Microsoft changed the name of Win32 to cover both the 32-bit and 64-bit versions,
but for our purposes, looking at the 32-bit version is sufficient.
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 that
clearly should not be (and are not) system calls, such as an API call to copy an en-
tire file.
Many Win32 API calls create kernel objects of one kind or another, including
files, processes, threads, pipes, etc. Every call creating a kernel object returns a re-
sult called a
handle
to the called. This handle can be subsequently used to per-
form 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 can have a security
descriptor associated with it, telling in detail who may and may not perform what
kinds of operations on the object.
Windows 7 is sometimes said to be object oriented because the only way to
manipulate kernel objects is by invoking methods (API functions) on their handles,
which are returned when the objects are created. On the other hand, it lacks some
of the most basic properties of object-oriented systems such as inheritance and
polymorphism.
In this section we will look at virtual memory in both
UNIX
and Windows 7.
For the most part, they are fairly similar from the programmer's point of view.
UNIX Virtual Memory
The
UNIX
memory model is simple. Each process has three segments: code,
data, and stack, as illustrated in Fig. 6-33. In a machine with a single, linear ad-
dress space, the code is generally placed near the bottom of memory, followed by
the data. The stack is placed at the top of memory. The code size is fixed, but the
data and stack may each grow, in opposite directions. This model is easy to imple-
ment on almost any machine and is the model used by Linux variants that run on
OMAP4430 ARM CPUs.
Furthermore, if the machine has paging, the entire address space can be paged,
without user programs even being aware of it. The only thing they notice is that it
