Page 382 - DCAP103_Principle of operating system

Unit 13: Input/Output and Security of Windows

are defined, including text, bitmaps, objects, and metafiles. The latter are sets of Win32 calls that Notes
when executed draw something, allowing arbitrary drawings to be cut and pasted. This group
of calls puts things on the clipboard, takes things off the clipboard, and generally manages it.
Finally, we come to input. There are no Win32 calls for GUI applications for reading input
from the keyboard because GUI applications are event driven. The main program consists of a
big loop getting input messages. When the user types something interesting, a message is sent
to the program telling it what just came in. On the other hand, there are calls relating to the
mouse such as reading its (x, y) position and the state of its buttons. Some of the input calls are
actually output calls, though, such as selecting a mouse cursor icon and moving it around the
screen (basically, this is output to the screen). For nonGUI applications, it is possible to read
from the keyboard.
13.1.3 Implementation of I/O

We could go on more or less indefinitely about the Win32 graphics calls, but now it is time to look
at how the I/O manager implements graphics and other I/O functions. The main function of the
I/O manager is to create a framework in which different I/O devices can operate. The basic
structure of the framework is a set of device-independent procedures for certain aspects of I/O
plus a set of loaded device drivers for communicating with the devices.
13.1.4 Device Drivers

To make sure that device drivers work well with the rest of Windows 2000, Microsoft has defined
a Windows Driver Model that device drivers are expected to conform with. Furthermore, it
also has provided a tool kit that is designed to help driver writers produce conformant drivers.
In this section, we will briefly examine this model. Conformant drivers must meet all of the
following requirements as well as some others:

1. Handle incoming I/O requests, which arrive in a standard format.
2. Be as object based as the rest of Windows 2000.

3. Allow plug-and-play devices to be dynamically added or removed.

4. Permit power management, where applicable.
5. Be configurable in terms of resource usage.

6. Be reentrant for use on multiprocessors.
7. Be portable across Windows 98 and Windows 2000.

I/O Requests are passed to drivers in the form of a standardized packet called an IRP (I/O
Request Packet). Conformant drivers must be able to handle them. Drivers must be object based
in the sense of supporting a specific list of methods that the rest of the system can call. They must
also correctly deal with other Windows 2000 objects when given an object handle to deal with.

Conformant drivers must fully support plug and play, which means that if a device managed
by the driver is suddenly added or removed from the system, the driver must be prepared to
accept this information and act on it, even in the case that the device currently being accessed is
suddenly removed. Power management must also be supported for the devices for which this is
relevant. For example, if the system decides it is now time to go into a low-power hibernation
mode, all devices that are capable of doing this must do so to save energy. They must also wake
up when told to do so.

LOVELY PROFESSIONAL UNIVERSITY 375