Chapter 27 Windows 2000

Exercises

27-1 Describe the functions of the Object Manager in Windows 2000. Which UNIX abstraction is the closest analogue of an object handle?

The object manager fulfils a number of functions which are common between the various facilities that are provided by the executive component of the operating system. This includes access control (deciding which principals can access which objects) and existence control (deciding when a particular object can be de-allocated because it is no longer in use). Objects include processes, threads, files and timers. Applications use opaque object handles to identify particular objects. The closest analogue in UNIX is that of a file descriptor, but notice how the objects in Windows are more general than the entities that a file descriptor can refer to. For instance a UNIX file descriptor cannot identify a process.

27-2 What is an IRP? What advantages and disadvantages are introduced by using them in the I/O subsystem over using ad-hoc per-device interfaces?

An IRP is a data structure representing a particular I/O request, for instance a request to read a particular block from a disk. The I/O manager passes IRPs to each of the drivers responsible for implementing the requested function. This makes it easy to implement a layered I/O system in which additional functionality – such as logging or mirroring – can be added. Representing I/O operations as IRPs may also help provide asynchronous I/O operations by allowing IRPs to bypass one another as they are handled by the I/O subsystem.

27-3 Compare and contrast the distinction between processes, threads and fibers introduced in Section 27.5 with the concepts of Solaris processes, threads and LWPs from Section 25.6.

In each case a process is the entity to which resources are allocated. A Windows thread corresponds to a Solaris LWP in that these are the entities which the kernel schedules, which can block and for which it maintains a saved register state when they are not running. A Windows fiber is similar to a Solaris thread in that these are implemented within a programming library rather than by the OS kernel; in each case the program must take care when one of these performs a blocking operation.

27-4 Section 27.2 described how a programming environment such as POSIX could be provided by a combination of a shared library used by applications and a subsystem process with which all POSIX applications communicate using IPC. (a) Why are both components necessary?

A separate subsystem process is needed to securely maintain POSIX-environment-wide state, such as the parent-child relationship between process IDs. The components in a shared library perform translation functions that are local to the POSIX application; the clearest example is mapping from file descriptors to object handles. Performing this mapping within the application aids performance (by avoiding IPC communication with the environment subsystem) and means that it may then perform the resulting I/O itself rather than having it performed on its behalf (again, perhaps aiding performance and ensuring that the access is done in the correct security context).

(b) Discuss how functionality could be split between them in providing (i) the basic UNIX process management functions from Chapter 24, (ii) the sockets interface from Chapter 25 and (iii) SVr4 shared memory segments from Chapter 25.

The basic process management functions (creation of processes using fork and synchronization using wait) could be implemented by IPC from an application to the environment subsystem – the environment subsystem would be responsible for maintaining the parent-child mappings between POSIX applications and for holding the exit code of terminated processes. The sockets interface would more naturally be implemented as a shared library because this is essentially a different set of wrappers around the existing communication facilities exported by the executive. Sockets in different domains or socket types may map to different kinds of object. Shared memory segments could generally be implemented within an application as wrappers around memory sections. However, some mechanism will be needed to map between SVr4-style shared memory keys and the object handles for these sections.