[oR]
2.1
WINDOWS GRAPHICS SYSTEM COMPONENTS
The Windows Application Programming Interface�in other words, the Win32 API�is a huge set of interrelated functions providing different kinds of services to application programs. From the programmer's viewpoint, the Win32 API can be divided into several groups of services:
Window Base Services, commonly known as kernel services, which include Microsoft clustering, debugging, error handling, dynamic load library (DLL), process, thread, file, I/O, international features, interprocess communication, performance monitoring, removable storage, security, etc.
User Interface Services, commonly known as user services, which include windowing, message queue, dialog box, control, common control, common dialog box, resource, user input, shell, etc.
Graphics and Multimedia Services, including broadcast architecture, color management, DirectX, GDI, multimedia, video for windows, still image, OpenGL, Windows Media, etc.
COM, OLE, and Active X Services, including Component Object Model (COM), automation, Microsoft Transaction Server, Object Linking and Embedding (OLE), etc.
Database and Messaging Services, including Data Access Objects (DOA), the Structured Query Language (SQL) server, Messaging API (MAPI), etc.
Networking and Distributed Services, including active directory, message queue, networking, remote procedural call, routing and remote access, Systems Network Architecture (SNA) server, synchronization manager, Telephony API (TAPI), etc.
Internet, Intranet, and Extranet Services, including indexing service, Internet Explorer, Microsoft agent, NetShow, scripting, site server, etc.
Setup and System Management Services, including configuration, setup, systems management, etc.
Each group of services is supported by a set of operating-system components. They include Win32 environment subsystem DLLs, user mode drivers, OS system services, and kernel mode drivers. Each group is well worth several good books to uncover the deep knowledge needed to use those services effectively. For example, Jeffrey Richter's Programming Applications for Microsoft Windows, 4th ed. (originally called Advanced Windows), is a masterpiece on windows base services; while Charles Petzold's Programming Windows, 5th ed., focuses on user interface services and GDI services.
The Graphics and Multimedia Services group of the Win32 API is so huge that it may well take several books to cover adequately. The focus of this book is a very important subset of the Graphics and Multimedia Services, namely GDI and DirectDraw. Let's now take a closer look at the components that support Graphics and Multimedia Services.
The Win32 graphics APIs are implemented on several platforms: Windows 95/98, WinCE, Windows NT, and the latest Windows 2000. It used to be that NT-based systems provided the best support for GDI, being a true 32-bit implementation, while Windows 95-based systems provided the best support for game programming. But the new Windows 2000 operating system provides the best of both worlds. Windows 2000 makes significant changes to provide hardware acceleration for DirectX/OpenGL, the new still-image API, broadcasting architecture, user mode printer driver, etc. In this book we will focus on the Windows 2000 graphics and multimedia system architecture, while pointing out the differences with Windows 95/98 and Windows NT 3.5/4.0 from time to time.
Looking top-down at Figure 2-1, as you've seen with the overall operating-system design, the Windows NT/2000 graphics and multimedia system is a layered system. The topmost box contains application programs, which interface with a set of 32-bit user mode system DLLs through the Win32 API. The system DLL layer contains familiar DLLs like GDI32.DLL for the graphics device interface, USER32.DLL for the user interface and window management, KERNEL32.DLL for window base services, etc. Most of the modules in this layer are provided by the operating system, but a few components in this layer rely on help from some user mode drivers provided by hardware vendors. Below this is the system service call gate, which invokes system calls that are served by system service routines in the kernel mode portion of the operating system. The Windows NT/2000 Executive, which lives in kernel address space, provides the graphics engine, I/O manager, video port driver, etc., to support the graphics and multi media system. It needs support from vendor-supplied device drivers, which talk to an array of hardware devices like the bus, video display, and printer with the help of the OS hardware abstraction layer.
Figure 2-1. Windows 2000 graphics/multimedia system architecture.
Now let's scan through the user mode portion horizontally. Graphics Device Interface (GDI) and Image Color Management (ICM) provide a device-independent graphics programming interface to application programs. If you're doing printing output, GDI eventually needs to talk to a printer driver, which could be running in user mode in Windows 2000. User mode printer drivers rely heavily on functions provided by the graphics engine, for which they call GDI to pass calls back to the graphics engine. Printing jobs are controlled by the spooler system process, which relies on vendor-customizable components like the print processor, printer monitor, and printer provider.
DirectX adds a relatively new set of Win32 system DLLs, which implement the DirectX COM interfaces. For actual interfacing with DirectX implementation in kernel address space, DirectX goes through GDI. DirectX is made up DirectDraw, Direct Sound, DirectMusic, DirectInput, DirectPlay, DirectSetup, AutoPlay, and Direct3D. This book covers only the DirectDraw part of DirectX.
We will cover GDI and the DirectDraw portion of DirectX in much more detail. For the moment, let's just quickly go through the components we will not be covering in this book.
Multimedia
The multimedia part of the Win32 API is a continuation from multimedia support started in Windows 3.1. It contains the MCI (media control interface), audio output, multimedia file I/O, joystick, and the multimedia timer. The MCI is defined to control all linear playback media, with functions like load, pause, play, record, stop, resume, etc. There are three types of audio output supported: CD audio, MIDI (musical instrument digital interface), and waveform audio. The Win32 multimedia API is defined in mmsystem.h, with winmm.lib and winmm.dll being its import library, and Win32 system DLL. Winmm.dll relies on installable user mode device drivers for each actual multimedia device. The single major exported function for a multimedia driver, which is itself a 32-bit DLL, is DriverProc. DriverProc handles messages from the multi media system, such as DRV_OPEN, DRV_ENABLE, DRV_CONFIGURE, DRV_CLOSE, etc.
Note
To check the multimedia drivers available on your system, open mmdriver.inf under the %SystemRoot%\system32 directory. You can find around a dozen multimedia drivers. For example, mmdrv.dll is for low-level wave, MIDI (musical instrument digital interface), and AUX support (auxillary output device); msacm32.drv is Microsoft Audio Compression Manager; and ir32_32.dll is the Indeo codec, a video compressor/decompressor developed by Intel, which uses a wavelet compression algorithm with MMX support.
If you wonder how Windows NT/2000 user mode drivers can control hardware like your speaker, they can't do it alone. User mode multimedia drivers rely on a class of kernel mode drivers called kernel streaming drivers, which are capable of controlling hardware directly.
The Win32 multimedia component is gradually being replaced by corresponding components in DirectX, with better features and higher performance. For example, DirectSound handles waveform-audio sound capture and playback; DirectMusic can capture and play back digital sound samples, including MIDI; DirectInput supports a whole range of input devices including mouse, keyboard, joystick, and other game controllers, as well as force-feedback devices.
One multimedia function is widely used by non-multimedia Windows applications to get high-resolution timer readings, namely, the timeGetTime() function. It can offer at best 1 ms accuracy, usually better than Get TickCount() (1 ms on Windows 95, 15 ms on Windows NT/2000). For Win32 programs, QueryPerformanceCounter is orders of magnitude more accurate than both timeGetTime and GetTickCount if the CPU supports a high-resolution performance counter. On machines with the Intel Pentium CPU, the high-resolution performance counter is the CPU clock-cycle count we mentioned in Chapter 1. So on a 200-MHz CPU, its accuracy is 5 nanoseconds. But calling Query PerformanceCounter itself is not so high performance; a system call is made to the OS kernel to return the performance counter.
Video for Windows
Similar to Win32 multimedia, Win32 Video for Windows has a long history dating back to Windows 3.1. Video for Windows (VFW) provides Win32 API support for video data processing. To be more specific, it supports AVI (audio-video interleaved) file read, write, positioning, and editing, the video compression manager, video capture, and the DrawDib API. Many of VFW's features have been superseded by Direct Show within DirectX.
The DrawDib API contains functions like DrawDibDraw, DrawDibGetBuffer, DrawDibUpdate, etc. It's similar to the Win32 StretchDIBits call, but provides extra features like calling the right decoder, data streaming, and supposedly higher performance. The first two benefits are from installable multimedia drivers that support different data streams; the third benefit is certainly no match for DirectDraw. Win32 VFW is supported by header file vfw.h, library file vfw32.lib, and runtime DLL msvfw32.dll. The VFW implementation relies on Win32 multimedia implementation.
Note
The DrawDib functions are still advertised as providing high-performance image-drawing capabilities which do not rely on GDI and write directly to video memory. While it sounds good, it may no longer be true, especially with Windows NT/2000. On Windows NT/2000, where direct video access is available only through kernel mode driver or DirectX, DrawDibDraw does use the GDI function to draw normal Window DIB, which makes it slower than the GDI DIB drawing function.
Still Image
The Still Image (STI) API is a new Microsoft interface for acquiring digital still images from devices like scanners and digital cameras and is available only on Windows 98 and Windows 2000. Clearly STI is a replacement for the older TWAIN standard. (You may wonder why it's not called DirectImage; perhaps it will be soon.) Because it's new, Microsoft has the luxury of using COM interfaces for STI instead of traditional Win32 API function calls. Microsoft STI is made up of a still-image event monitor, vendor-supplied user mode still-image mini-drivers, and a scanner and camera control panel. The still-image event monitor monitors system-wide still image devices and their events. It also keeps track of registered still-image applications, which can be started when an event is detected. A still-image mini-driver detects events from a particular device, notifying the event monitor of activities. It also passes image data from the kernel mode driver to user mode. The scanner and camera control panel allows the user to associate still-image devices with still-image-aware applications. The scanner/camera control panel applet (sticpl.dll), still-image monitor (stimon.dll, stisvc.exe) and imaging applications all use STI COM object (CLSID_Sti), which implements the IStillImage interface, whose instance is created by StiCreateInstance. The STI COM object is implemented by sti.dll, which uses IStiDevice and IStiDeviceControl COM interfaces to control still-image mini-drivers. Windows 98/2000 STI API is supported by header file sti.h, library file sti.lib, the DLLs and EXE mentioned above, and user mode and kernel mode still-image device drivers.
OpenGL
The last user mode component in Figure 2-1 is OpenGL. OpenGL is a programming standard for 2D/3D graphics developed by Silicon Graphics, Inc. Its main purpose is to render 2D/3D objects into a frame buffer. OpenGL allows a programmer to describe objects using a group of vertices, each with its coordinate, color, normal, texture coordinate, and edge flag. This allows a description of points, line segments, and 3D surfaces, using OpenGL function calls. The OpenGL graphic control allows specification of transformation, lighting equation coefficients, antialiasing methods, and pixel update operators. The OpenGL render goes through several stages to finally render the data into a frame buffer. The first stage, evaluator, approximates curves and surfaces by evaluating polynomial commands. The second stage, vertex operation and primitive assembly, transforms, lights, and clips vertices. The third stage, rasterization, produces a series of frame-buffer addresses and associated values. The last stage, per-fragment operation, does depth buffering, alpha blending, masking, and other pixel operations in the final frame buffer.
The Microsoft OpenGL implementation, as seen on Windows NT/2000, adds some extra features to the OpenGL standard. It implements the full set of OpenGL commands, OpenGL Utility (GLU) library, OpenGL Programming Guide Auxiliary Library, Window extension (WGL), per-window pixel format, and double buffering. OpenGL uses three header files in the gl subdirectory of your compiler include directory, including gl.h, glaux.h, and glu.h. The window extension (WGL) part is defined in the GDI header file wingdi.h. OpenGL uses library files opengl.lib and gdi32.lib and runtime DLLs opengl32.dll and gdi32.dll.
To improve OpenGL performance, its implementation allows for vendor-supplied drivers to perform vendor-specific optimization and direct hardware access. Microsoft provides mini-client architecture (MCD) to facilitate OpenGL drivers. Open GL.dll loads mcd32.dll, the OS-supplied client-side DLL, and an optional vendor-supplied user mode OpenGL driver. You can find your OpenGL driver by searching for OpenGLDrivers in the registry. The MCD client and OpenGL user mode driver uses the GDI function ExtEscape to send commands to the graphics engine and driver in kernel mode. A display driver providing OpenGL optimization is needed to support its MCD portion, with the help of a kernel MCD server in mcdsrv32.dll.
It's quite common nowadays for graphics card vendors to support DirectDraw, Direct3D, and OpenGL hardware acceleration in a single package. It's always interesting to see different designs for similar purposes, in this case, GDI and OpenGL. Initially, GDI started as a simple graphics programming interface for the hardware the PC industry had during that time, namely, 16- or 256-color EGA or VGA display cards, and monochrome printers. Gradually, GDI added support for device-independent bitmaps, color printers, vector fonts, TrueType fonts, OpenType fonts, 32-bit logical coordinate space, gradient fill, alpha channel, multiple monitor support, multiple terminal support, and so on. GDI is still evolving to GDI+. GDI can really run a small device like a palmtop PC as well as a powerful machine like a workstation. Performance, backward compatibility, and device independence may be the main design goals behind GDI, or the Windows API in general. On the contrary, OpenGL is designed to be a high-end 2D/3D graphics package for creating photorealistic scenes. OpenGL's heavy usage of floating-point calculation needs a high-end machine with lots of memory and horsepower. Various effects like lighting, blending, antialiasing, and fogging would not be effective on a 256-color VGA monitor. Although OpenGL is designed to be device-independent, it's mainly designed to render onto a frame buffer. So OpenGL still has difficulty printing on high-resolution printers. Actually, on Windows NT/2000, GDI is offering an OpenGL printing solution by recording OpenGL commands into a special EMF format and then playing them back to a high-resolution printer device.
Because of the complexity of building a 2D/3D scene, OpenGL is a higher-level graphics language than GDI. An OpenGL program normally builds a scene in three-dimensional space using vertices, line segments, and polygon surfaces, defines attributes, lighting sources, and viewing angles, and then has the OpenGL engine do all the detailed work. In comparison, GDI is a much more procedural-level language, where the application needs to specify the exact command parameters and sequence to construct a picture. If you want to create a 3D scene, GDI does not help you to calculate 3D depth and remove hidden surfaces. Even Direct3D Immediate Mode is a lower level API when compared with OpenGL.
Windows Media
Windows Media is a new addition to the Win32 Graphics/Multimedia system. It contains Windows Media Services, Windows Media Encoder, Windows Media Player Control, and Windows Media Format SDK.
Windows Media Services provides ActiveX controls and COM APIs to allow Web authors to add streaming media to their web sites and to control, monitor, and managing media broadcasting.
Windows Media Encoder is primarily responsible for encoding different types of media content into the Windows Media Format stream or file, which can then be delivered through Windows Media Services. Advanced Streaming Format (ASF) is a file container which can contain data in different media formats.
Windows Media Player Control is an ActiveX control for adding multimedia playback to applications and web pages.
Windows Media Format SDK is a development kit for reading, writing, and editing Windows Media audio, video, and script files.
OS Kernel Mode Components
The user mode graphics and multimedia components have two ways to communicate with the operating system kernel. For GDI, DirectDraw, Direct3D, and OpenGL, user mode calls go through gdi32.dll, which provides the interface to hundreds of system service calls. For interaction with video port drivers and multimedia drivers, user mode calls use the normal file I/O API provided by Windows base services.
File I/O system services are handled by the I/O manager in the kernel mode Executive, which calls corresponding drivers. GDI, DirectDraw, Direct3D, and OpenGL calls go through the graphics engine, which passes them to individual device drivers.
The actual operating-system modules involved include NTOSKRNL.EXE (system service dispatching, I/O manager), WIN32K.SYS (graphics engine), MCDSVR32.DLL (MCD server), and HAL.DLL (hardware abstraction layer).
The Windows NT/2000 kernel Executive, NTOSKRNL.EXE, is the most important piece in the OS kernel. In the graphics system, it's mainly responsible for dispatching graphics-system service calls to the graphics engine, because the graphics engine happens to use the same system service-call mechanism used by other more hard-core system services. The hardware abstraction layer, HAL, provides some service routines to the graphics device driver for things like reading and writing hardware registers. It helps other components of the kernel to be more platform independent. For more discussion on the Executive and HAL, refer to Chapter 1.
Kernel Mode Drivers
The Windows NT/2000 graphics and multimedia system relies on quite a number of vendor-supplied drivers to interface with the final hardware.
The most important driver is the display driver, which should handle GDI, DirectDraw, Direct3D, and MCD for OpenGL support. The display driver is always paired with a video miniport driver, which handles interaction with things like hardware ports. The video miniport driver also needs to support VPE (video port extension to DirectX) and DxApi miniport.
A font driver is a lesser-known kind of graphics driver, which supplies font glyphs to the graphics engine. For example, ATM (Adobe Type Manager) uses atmfd.dll as a font driver. Font files are loaded into kernel address space by the graphics engine and font drivers.
The printer driver is similar to the display driver with some more functions to implement. Unlike other drivers, printer drivers normally do not talk directly with printer hardware. Instead, they write the printer-ready data stream back to the spooler in user mode. The spooler passes the data to the print processor and then to the port monitor, which then uses file I/O to call the kernel mode I/O driver. Windows 2000 allows the printer driver to be either user mode DLL or kernel mode DLL.
Other kernel mode drivers used by the graphics and multimedia system include multimedia drivers like the sound-card driver, and still-image drivers like the scanner driver and camera driver. Windows 2000 DDK provides detailed documentation on kernel streaming drivers (audio, video, video capture) and still-image drivers.
The quality of the kernel mode device driver is crucial to the stability of the whole operating system. A kernel mode driver has read, write access to the whole kernel mode address space and all privileged CPU instructions. So a buggy kernel mode driver could easily damage important data structures maintained by the operating system, causing the whole system to crash. Therefore, it is critical that any application that includes kernel mode drivers, such as antivirus products, be thoroughly tested to minimize this risk. With Windows 2000, Microsoft ships a Driver Verifier Manager tool (verifier.exe in the system directory) with the OS to help developers verify their drivers.
This section covered the architecture of the Windows NT/2000 graphics and multi media system, a sophisticated yet structured hierarchy of DLLs, user mode drivers, kernel mode DLLs, and kernel mode drivers. The control flow is much more complicated, as in printing, where control cycles between user mode code and kernel mode code several times. We will leave most of the details to the MSDN library, DDK, and other references, while focusing on a few major components important to common Windows applications. In the remaining sections of this chapter, we will un fold what's in GDI, DirectDraw, the display driver, and the printing system including the printer driver.
|
No comments:
Post a Comment