Page 1 of 24
`Page 1 of 24
`
`AMS
`AMS
`Exhibit 2012
`RA v AMS
`IPR2017-00048
`
`IPR20 1 7—00048
`
`Exhibit 2012
`
`RA V AMS
`
`

`

`
`
`ADRIAN KING
`
`Page 2 of 24
`Page 2 of 24
`
`AMS
`AMS
`Exhibit 2012
`RA v AMS
`IPR2017-00048
`
`IPR2017—00048
`
`Exhibit 2012
`
`RA V AMS
`
`

`

`
`
`}I
`l
`
`
`
`
`
`
`PUBLISHED BY
`Microsoft Press
`A Division of Microsoft Corporation
`One Microsoft Way
`Redmond, Washington 93052-6399
`Copyright © 1994 by Adrian King
`
`All rights reserved. No part of the contents of this book may be reproduced or
`transmitted in any form or by any means without the written permission of the publisher.
`
`Library of Congress Cataloging-in-Publication Data
`King. Adrian, 1953-
`Inside Windows 95 / Adrian King.
`.
`cm.
`Includes index.
`ISBN I-55615-626-X
`1. Windows [Computer programs)
`file)
`I. Title.
`Q_A7fi.7Ii.W56K56
`005.4 ' 469--dc20
`
`1994
`
`2. Microsoft Windows [Computer
`
`93- 48485CIP
`
`Printed a.nd bound in the United States of America.
`
`123456789 QMQM 987654
`
`Distributed to the book trade in Canada by Macmillan of Canada, a division of Canada Publishing
`Corporation.
`
`A CIP catalogue record for this book is available from the British Library.
`
`Microsoft Press books are available through booksellers and distributors worldwide. For further information
`about international editions, contact your local Microsoft Corporation office. Or contact Microsoft Press
`International directly at far. (206) 936-7329.
`
`PageMaker is a registered trademark of Aldus Corporation. Apple, AppIeTalk, Laserwriter. Mac,
`Macintosh, and 'I'rueType are registered trademarks ofApple Computer, Inc.
`l.ANtastic is a registered
`trademark of Artisoft, Inc. Banyan and Vines are registered trademarks of Banyan Systems, Inc.
`Compaq is a registered trademark of Compaq Computer Corporation. CompuServe is a registered
`trademark of CompuServe, Inc. Alpha AXP, DEC, and Pathworits are trademarks of Digital Equipment
`Corporation. LANstep is a trademark of Hayes Microcomputer Products, Inc. HP and Laserjet are
`registered trademarks of Hewlett-Packard Company. Intel is a registered trademark and EtherExpress,
`Pentium, and SK are trademarks-of Intel Corporation. COMDEX is a registered trademark of Interface
`Group-Nevada, Inc. AS/:1-D0, IBM, Micro Ch-artnel. 05/2, and PS/2 are registered trademarks and PC/
`XT is a trademark of International Business Machines Corporation. I~2»3, Lotus, and Notes are
`registered trademarks of Lotus Development Corporation. Microsoft, MS, MS-DOS, and XENIX are
`registered trademarks and ODBC, Win32s. Windows. Windows NT, and the Windows operating system
`logo are trademarks of Microsoft Corporation. MIPS is a registered trademark and R4000 is a trade-
`mark of MIPS Computer Systems, Inc. Netware and Novell are registere'd trademarks of Novell, Inc.
`Soft-[ce/W is a registered trademark of Nu-Mega Technologies, Inc. DESQview is a registered trade-
`mark and Qemm is a trademark of Quarterdeck Office Systems. OpenGL is a trademark of Silicon
`Graphics. Inc. PC-NFS. Sun, and Sun Microsystems are registered trademarks of Sun Microsystems, Inc.
`TOPS is a registered trademark of TOPS, a, Sun Microsystems company. UNIX is a registered trademark
`of UNIX Systems Laboratories.
`
`Acquisitions Editor: Mike Halvorson
`Project Editor: Erin O'Connor
`Technical Editors: Seth McEvoy and Dail Magee,]r.
`
`
`
`Page 3 of 24
`Page 3 of 24
`
`AMS
`AMS
`Exhibit 2012
`RA v AMS
`IPR2017-00048
`
`Exhibit 2012
`
`RA V AMS
`
`IPR2017—00048
`
`

`

`INSIDE WINDOWS 95
`
`the event of a memory access fault when the code scans past the end of
`the allocated memory buffer (with the pattern not found). Neither ex-
`ample tests for this condition, and in the first case you'd get a program
`failure with little useful qualifying information.
`Exception handlers are frame based, meaning that their scopes
`nest just as declaration scopes do. so it‘s possible to handle errors on
`either a global or a local basis. There are also facilities for specifying
`the context in which the exception is handled."‘ The structured excep-
`tion handling feature also allows a program to initiate an exception
`(the RaiseExcept:'an() API) and specifies the protocol for interacting
`with a debugging tool ifone is in use. Within an except block, you can
`determine the cause of an exception so that you can carry out appro-
`priate error recovery. You shouldn’t replace every error test in your
`code with an exception sequence, but it is a great way to manage a mul-
`titude of possible error conditions diligently and efiiciently. After all,
`how many times do you test for every possible error in your code?
`
`The Graphics Device Interface
`
`GDI is the heart of the Windows graphics capabilities. All of the draw-
`ing functions for lines and shapes are in GDI as well as the color man-
`agement and font handling functions. Many aspects of Windows
`performance are tied closely to GDI performance, and a lot of the GDI
`code is handcrafted 386 assembly language. At the application level,
`Windows provides logical objects known as device contexts (DCs) that de-
`scribe the current state of a particular GDI drawing target. A DC can
`describe any output device or representation of a device. An applica-
`tion will obtain a DC. for printer output or for completely memory-
`based operations, for example. Applications manage DCs by means of
`Win32 APIs only. The actual DC data structure is always hidden from
`the application. At any instant a DC contains information about objects
`such as the current pen (for drawing lines), the current brush (for fill-
`ing regions), the color selection, and the location and dimensions of
`the logical drawing target.
`The key to the use of Windows and Windows applications on a
`widely disparate range of target hardware is the device independence
`
`
`24. Reminiscent of. but much better than, the C language .mJ1‘?np()/£an.g_,insp(,i
`facility.
`
`
`
`W
`
`Page 4 of 24
`Page 4 of 24
`
`IPR2017—00048
`
`AMS
`AMS
`Exhibit 2012
`RA v AMS
`IPR2017-00048
`
`Exhibit 2012
`
`RA V AMS
`
`

`

`S I X: Applications and Devices.
`
`embodied in the Windows AP]. An application uses DCS and other logi-
`cal objects when calling GDI functions. It never writes data directly to
`an output device. GDI itself manages the process of transforming the
`data into a format suitable for use by a particular device driver, and the
`driver handles the task of placing a representation of the request on
`the output device. For example, an application may call the system ask-
`ing for its main window to be repainted. During the repainting opera-
`tion, among many other requests,
`(3131 may tell the driver “on the
`screen draw a one-pixel-wide black line from position {0, 48) to posi-
`tion (639, 48) .” If the device—a dot matrix printer, say—can’t perform
`operations such as line drawing, GDI will break the request down into
`simpler operations. The device driver will receive a series of calls telling
`it to draw individual dots. for example. This architecture frees applica-
`tions from device-dependent problems and allows Windows to make
`use of even the simplest hardware as an output device.
`With this device-independent capability come several problems.
`In addition to simply choosing and managing an appropriate device-
`independent representation of all the graphics objects, you need to
`have a plethora of device drivers available to interface CD1 to the target
`hardware. Issues such as handling complex fonts through a range of
`point sizes and then being able to draw the font legibly on both a 1024
`by 768 pixel display screen and a simple dot matrix printer involve
`many complex algorithms and a lot of very clever code.
`Over successive releases of Windows, the capabilities of GDI have
`improved considerably, and the underlying structure of the system has
`adapted to the experience gained from earlier versions and to the pre-
`vailing market forces. The vast majority of Windows users nowadays
`tend to have fairly capable hardware; VGA displays and laser or high-
`resolution dot matrix printers. The hardware will probably get even
`more powerful, with higher resolution and color-capable devices
`abounding. It's therefore important to get the best possible perfor-
`mance out of a few core components rather than expend effort on
`hundreds of device drivers, each with a limited installed base. It has
`
`also been important to look ahead at the likely effects of hardware
`trends. Two of the major changes in the Windows 95 GDI subsystem
`reflect hardware trends: the device-independent bitmap (DIE) engine and
`the image coitrr matrhiv1g(ICM) subsystem.
`Windows 3.1 successfully introduced the concept of the mriversal
`printer dn've'r—a device driver that does much of the work for all the
`other system printer drivers. The so called primer minuirivers support
`
`253
`
`Page 5 of 24
`Page 5 of 24
`
`AMS
`AMS
`Exhibit 2012
`RA v AMS
`IPR2017-00048
`
`IPR2017—00048
`
`Exhibit 2012
`
`RA V AMS
`
`

`

`INSIDE WINDOWS 95.
`
`only the hardware-specific operations of a printer and rely on the uni-
`versal driver for most printing-related functions. This allocation of re-
`sponsibility allowed Microsoft to invest heavily in a high-performance,
`high-quality universal printer driver and in some good example mini-
`drivers for devices such as the Hewlett-Packard Laserjet. From the
`printer manufacturer's perspective, Windows printer driver develop-
`ment became a much simpler and much less error prone project.
`Windows 95 takes up this design concept by incorporating the
`DIB engine and a display mim’-chiver capability. If the display hardware
`matches what the DIB engine can do, what was once a very complex,
`performance-sensitive development effort is considerably simplified.25
`Vfrite a display mini-driver, and rely on the D13 engine as
`(in
`Microsoft’s phrase) “the world’s fastest flat frame buffer” display driver.
`The DIB engine design also recognizes the level of effort that hardware
`manufacturers now put into hardware assists for Windows-based sys-
`tems. If you have hardware acceleration or other capabilities, the dis-
`play mini-driver can use these instead of calling the DIB engine.
`Image color matching is a new capability that addresses device-
`indepenclence issues for applications that deal with color, such as
`photo retouching applications. Although color has always been part of
`Windows, earlier releases didn’t have to worry too much about the is-
`sue since color-capable peripherals were relatively rare. But now that
`the price of good color scanners and color printers has fallen to the
`$1,000 range, Windows has to take careful note of color management.
`Here are the other improvements to GDI in Windows 95:
`
`I Performance. A lot of code has been tuned, and some impor-
`tant components have been converted to 32-bit code.
`
`I Relaxation of resource limitations. In parallel with what‘s
`been done [0 the User subsystem, many of GDI‘s resource
`limits have been raised significantly.
`
`I Win32 support. Windows 95 fully supports many graphics APIs
`unavailable in Windows 3.1.
`
`I Tr1leType enhancements.
`
`
`
`25. One simple code count shows the VGA display driver in Windows 3.1 to be over
`41,0001ines of assembler (for a lfi—co]or—onIy display). In Windows 95, it's only about
`5000 lines for the full 256-color driver.
`
`GDIA
`
`
`
`._.-ju-:-Z-—q—o-j-1
`
`Page 6 of 24
`Page 6 of 24
`
`AMS
`
`AMS
`Exhibit 2012
`RA v AMS
`IPR2017-00048
`
`Exhibit 2012
`
`RA V AMS
`
`IPR2017—00048
`
`

`

`5 ix: Applications and Devices
`
`I Metafile support enhancements Compatible with Windows
`NT’s metafile support.
`
`I Printing subsystem enhancements, including bi-directional
`printer support and a new 32-bit print spooler.
`
`GDI Architecture
`
`Figure 6-7 illustrates the major components of the GDI subsystem. It
`also shows the breakdown between 16-bit and 32-bit code modules—
`
`with one caveat: the DIB engine is actually 32-bit code running with a
`16-bit (segmented) View of system memory—so the code makes use of
`the fast 386 instructions for memory move operations, for example.
`There’s considerable trickery involved in efficient address manipula-
`tion, but it means that existing 16-bit applications can realize the per-
`formance improvements of the new DIB engine and that the engine
`itself can call into the 16-bit CD1 code with no additional overhead. If
`
`the DIB engine were placed on the 32-bit side of the fence, either the
`
`16-bit API
`
`32-bit API
`
`Thunk
`
`interface
`
`Figure 6-7.
`The components afGD1t':rt Windows 55.
`
`255
`
`Page 7 of 24
`Page 7 of 24
`
`IPR2017—00048
`
`AMS
`AMS
`Exhibit 2012
`RA v AMS
`IPR2017-00048
`
`Exhibit 2012
`
`RA V AMS
`
`

`

` INSIDE WINDOWS 95
`
`32-bit GDI module would have to replicate much of the GDI function-
`ality, or the DIB engine would incur lots of thunk overhead calling back
`to the 16-bit side.
`
`Before looking in detail at the new 1313 engine and the [CM sub-
`system, let's review the smaller improvements in the Windows 95 CD1.
`
`Performance Improvements
`The performance of the GDI subsystem is critical to the performance
`of Windows. Many benchmarks of Windows 3.1 tend to focus attention
`on video performance. Although video performance is only one ele-
`ment of the overall performance of the system, it’s certainly a huge Fac-
`tor in perceived performance.
`The Windows GDI code has been worked on for a sufficiently
`long time that there really aren't any huge undiscovered performance
`gains to be made. But Vlfindows 95 includes quite a few incremental
`improvements:
`
`I The new DIB engine is handcrafted assembler. The effort
`invested in this will improve the performance of many video
`display drivers as well as the print subsystem.
`
`I The TrueType rasterizer is the component responsible for
`turning a description of a font into the actual image you see
`on the screen or on the printed page. The Windows 95
`rasterizer is new 32-bit code.
`
`I The print subsystem spools print rnetafiles, reducing the
`amount of data movement and hence speeding up the print
`process. The print spooler itself is new 32-bit code that can
`run as a true background process.
`
`I A lot of new 32-bit code in key components makes use of the
`improved instructions available on the 386 processor. Also the
`duplication of some GDI components in 16-bit and 3?-bit
`code avoids thunk overhead.
`
`Limit Expansion
`Along with the move partway to a 32-bit subsystem comes access to the
`32-bit memory pools used by Windows 95. Under Windows 3.1, the GDI
`subsystem allocated all resources from a single 64K heap-—which
`limited the total number of available resources significantly on systems
`that were capable of running several applications at once.
`
`
`
`Page 8 of 24
`Page 8 of 24
`
`IPR2017—00048
`
`AMS
`AMS
`Exhibit 2012
`RA v AMS
`IPR2017-00048
`
`Exhibit 2012
`
`RA V AMS
`
`

`

`S I X: Applications and Devices
`
`In Windows 95, GDI still keeps many logical objects in a heap lim-
`ited to 64K. The data structures that describe brushes, pens, and
`bitmap headers, for example, stay in this smaller heap. Display context
`structures also remain in this pool. However. GDI now allocates the ob-
`jects that can really eat up space from a separate, 32-bit memory pool.
`GDI regions, font management structures, and physical objects all
`move to this pool, which considerably reduces the pressure on the 64K
`heap. For example, the collection of rectangles used to describe an el-
`liptical region can consume up to 45K. Decisions over which objects to
`move out of the 64K heap were also influenced by performance consid-
`erations. Since both 16-bit and 32-bit code has to manipulate the struc-
`tures, the designers had to be careful not to incur too many selector
`loads when switching between the different heap areas.
`
`New Graphics Features
`Windows 95 incorporates almost all of the more advanced graphics
`APIS defined by Win32. Their inclusion increases the suitability of Win-
`dows for use as an application platform by graphics-intensive applica-
`tions. The new APIs encompass
`
`I Support for paths, allowing an application to describe a
`complex arrangement of geometric shapes that GDI will
`outline and fill with a single function call
`
`I Bézier curve drawing, in which an application describes a curve
`using a series of discrete points and GDI figures out how to
`draw the curve
`
`Applications such as high-end drawing packages and CAD prod-
`ucts have to concern themselves with the very accurate representation
`of geometric objects. One of the differences between Windows 95 and
`Windows NT is in the drawing algorithms that define the pixels used
`when an application draws lines or fills shapes. Internally, an applica-
`tion can draw anywhere within the 16-bit coordinate space (—32,767 to
`+32,’/67 in both the xand y directions). GDI may have to scale this im~
`age dramatically to allow its display on a 640 by 480 pixel screen and,
`regardless of scaling issues, drawing a diagonal line on a video screen is
`always problematic. Essentially, CD! and the display driver have to fig-
`ure out between them which pixels become black and which stay white.
`For most of us (and most applications), the differences between lines
`
`257
`
`Page 9 of 24
`Page 9 of 24
`
`RA V AMS
`
`IPR2017—OOO48
`
`AMS
`
`E
`
`xhibit 2012
`
`AMS
`Exhibit 2012
`RA v AMS
`IPR2017-00048
`
`

`

`Imag‘
`
`INSIDE WINDOWS 95
`
`drawn according to the two algorithms won't be discernible. There are
`similar subtle differences between the ways the two GDI subsystems fill
`shapes on the screen. The algorithms differ as they determine which
`pixels to include or exclude around the edge of the shape.
`
`TrueType
`
`The new TrueType rasterizer is implemented in C. It's an adaptation
`of the C++ module developed for Windows NT?“ The new code also
`implements an improved mathematical representation of a font, using
`32-bit fixed point arithmetic with a 26-bit fractional part. Windows
`3.1 uses a 16-bit representation with a 10-bit fraction. This led to some
`rounding error problems (leading to reduced fidelity on high resolu-
`tion devices) and difficulties in handling complex characters such as
`those in the Chinese language (the Han characters}.
`The rasterizer now uses memory mapped files to access font de-
`scription files (all those .TTF files in your Windows system directory),
`and the associated .FOT files are gone. During the system boot process
`a private record of an installed font is written to disk and used during
`the next boot. This improves the speed of system startup considerably if
`you have a lot of fonts installed.
`
`Metafile Support
`Metafiles contain sequences of graphics operations written in a device-
`independent format. An application can obtain a device context to a
`metafile and draw a picture using the DC. GDI generates the metafile
`records that correspond to the GDI function calls made by the applica-
`tion. Metafiles can be reprocessed with the drawing output directed to-
`ward any capable device. The recorded picture will appear with the
`original sizing, proportions, and colors intact.
`Windows 95 adds support for the enhanced metafiles defined for
`Win32, including limited support for world transforms (scaling opera-
`tions only). There are some Win32-generated metafile records that
`Windows 95 won‘t understand, so it skips them when reading the
`metafile. This means that a metafile generated on a Windows NT sys-
`tem using the full range of graphics capabilities can’t be completely re-
`produced on a Windows 95 system.
`
`
`
`26. The Windows NT operating system code uses C++ extensiveiy. There's none in
`the Windows 95 operating system.
`
`
`
`Page 10 of 24
`Page 10 of 24
`
`IPR2017—00048
`
`AMS
`AMS
`Exhibit 2012
`RA v AMS
`IPR2017-00048
`
`Exhibit 2012
`
`RA V AMS
`
`

`

`S I X: Applications and Devices
`
`Image Color Matching
`
`The problem of producing a completely device-independent color ca-
`pability for Windows remains an intractable one. There doesn’t yet ex-
`ist a recognized solution to the probIem—for any general purpose
`computer system. Accurate color reproduction is the subject of many
`research projects, and a 11 umber of international standards try to solve
`subsets of the problem. Interestingly, all color standards in use today
`are derived from a 1931 definition known as the CIEXYZ standard.
`
`Apart from the fact that color reproduction involves issues of human
`perception. the basic problem is that even if you can define a com-
`pletely adequate internal color representation system, no two devices
`will reproduce a given color identically. Thus, a "red” on the printed
`page will look different on the screen, and many colors that you can
`choose for your latest Van Gogh knockoff on screen can‘t be accurately
`matched by the colors your printer can produce. Given the inability of
`a device to produce a particular color, what do you do? Adjust that
`color to the nearest one available on the output device? Or adjust every
`color in the image in an attempt to maintain the original contrast? It
`doesn't seem likely that anyone will ever solve the problem to the com-
`plete satisfaction of every expert.
`Color management systems that do exist today are built around
`specific hardware, so the controlling software knows what colors are
`available and what transformations it must use to render accurate color
`
`output. This of course runs counter to the Windows philosophy of al-
`ways maintaining device independence. Yet the need for a good color
`management system is apparent. For a few thousand dollars, you can
`set yourself up with a very high quality color production system, and
`the prices will no doubt fall further. Thus, the Windows designers were
`faced with the challenge of integrating a color management system
`that meets the nonexpert needs (and budgets) of most of us while still
`supporting the stringent requirements posed by professionals in maga-
`zine publishing and photographic reproduction.
`Image color matching (ICM) is Microsoft's name for the solution
`incorporated into Windows 95:
`
`I ICM defines a logicat calm" space for Windows that is defined in
`terms of the RGB (red, green, blue) triplets already used in
`Vt-Tindows 3.1. The use of the existing RGB mechanism is really
`
`259
`
`Page 11 of 24
`Page
`Of
`
`IPR2017—00048
`
`AMS
`Exhibit 2012
`RA v AMS
`IPR2017-00048
`
`Exhibit 2012
`
`RA V AMS
`
`

`

`!NS|DE WINDOWS 95
`j..
`
`‘II
`
`a convenient implementation detail. The logical color space is
`actually calibrated with reference to the CIEXYZ standard.
`
`I ICM uses a colorpmfile that defines the color capabilities of a
`particular device. Manufacturers of color output peripherals
`can ship a color profile with their devices, much as they might
`ship a Windows device driver today. l_fa device has no associ-
`ated color profile, the system chooses a sensible default
`profile.
`
`I The color profile allows the ICM to build a color tramfmm that
`defines how to map colors from the logical color space to the
`colors reproducible on the output device. For an input device
`such as a scanner, ICM uses the profile to transform the
`device colors to the logical color space.
`
`I ICM thus allows device drivers and the system itself to per-
`form color matching and color transformation operations in
`support of scanning or reproducing images involving a speci-
`fic device. ICM aims to be consistent—-giving you predictable
`results each time you scan, display, or print an image.
`
`I ICM is implemented as a replaceable DLL, and it’s possible
`to load more than one ICM at a time.” This means that for
`
`environments with different color management needs the
`system's default processing can be replaced or circumvented.
`
`I Windows 95 adds support for the CMYK color standard that’s
`widely used in applications that produce color separations for
`printing and publishing. If an application chooses CMYK as
`its color space. Windows stays out of the way and the applica-
`tion can pass color coordinates to the device driver without
`further transformation by the ICM.
`
`Microsoft also realized early on that there were people who knew
`a lot more about color management than they did. The specification
`and development of the Windows 95 ICM was done in conjunction with
`Eastman Kodak, a company that does indeed know quite a lot about
`color. The default ICM DLL planned for inclusion with Windows 95
`was written largely by Kodak.
`
`
`
`27. Loading a new [GM is under application control. Two new APls—
`Load1mags't'£alorMatrhmi) and FrerrIm.agP(.‘ol'an’li'alo‘m'(}—manage the procedure.
`
`260
`
`Page 12 of 24
`Page 12 of 24
`
`AMS
`
`AMS
`Exhibit 2012
`RA v AMS
`IPR2017-00048
`
`Exhibit 2012
`
`RA V AMS
`
`IPR2017—00048
`
`

`

`S I X: Applications and Devices
`
`Color Profiles
`
`Microsoft will publish the format of a color profile in the Windows 9:’)
`SDK and DDK products. The definition will describe both the File and
`in-memory formats for color profiles. No doubt some standard profiles
`will be included with Windows 95 when it ships—_just as you get most of
`your printer drivers “in the box" today. The contents of a color profile
`have been determined by efforts involving several different companies,
`and it’s freely acknowledged that there are application areas that will
`need further extensions of the information embodied in a color pro-
`file. But for most applications, these color profiles are sufficient.”
`As you'd expect, color profiles will be available for scanner de-
`vices, display screens, and color printers. The profile definition also
`enables the specification of profiles that describe abstract devices (al-
`lowing color ePfects) and color space conversion (from the internal
`logical color space to a different standard) and the specification of de-
`vice link profiles. A device link profile caters to a system with a fixed
`C0n_fig‘ura.tion, allowing the color transformations to be fine tuned so
`that, for example,
`the particular “red” generated by your Hewlett-
`Packard Scanjet becomes exactly this "red” on your HP Deskjet printer.
`Don‘: imagine that you’ll be generating color profiles the same
`way you change your desktop colors with the Windows Control Panel,
`though. Color profiles a1'e real science and may involve device calibra-
`tion, temperature correction, and the handling of different paper and
`ink types, among other complexities.
`
`Communicating color Information
`Figure 6-8 on the next page illustrates the flow of color information
`among the various components in the system. The color information
`communicated among the components is always expressed in either
`RG8 or CMYK values, or in some transformation of these values ac-
`cording to the way the appiication has defined its color space.
`At the application level, GDI provides several new APIS that allow
`a specific color space to be defined and manipulated.“ An application
`uses a device-independent bitmap (DIB) to store an image, and the
`
`
`28. ifyou don't already believe that color management is a tough probiem. note
`the way in which the ICM designers acknowledged the dtfiicttlty. They listed one of
`their goals as specifying a system Ll1at’s “simple enough to implement in our lifetimes.”
`29. lfyou‘re interested in the details, look for all the ]CM—relaLed.APls—those that
`have the string Color somewhere (I) in their names.
`
`261
`
`Page 13 of 24
`Page 13 of 24
`
`AMS
`
`AMS
`Exhibit 2012
`RA v AMS
`IPR2017-00048
`
`Exhibit 2012
`
`RA V AMS
`
`IPR2017—00048
`
`

`

`AMS
`AMS
`Exhibit 2012
`RA v AMS
`IPR2017-00048
`
`IPR2017—00048
`
`Exhibit 2012
`
`RA V AMS
`
`INSIDE wmo-ows .95 __
`
`
`
`35
`
`-
`-
`
`Calm‘ "information handling uairhin the systm.
`
`color matching APIS operate directly on the bitmap. The DIB structure
`itself has been extended to incorporate color information,-and, as with
`other dcvice—1'elated operations, color -manipulation is specific to each
`Windows device context.
`
`The Display‘ Subsystem
`
`Although Windows allows only a single system display device to be ac-
`tive, several different software components are involved in comrolling
`the display. Figure 6-9 illustrates most of these components, together
`with the boundaries between then-i—~the API layer-and ting zero com-
`ponents vs. ring three components. The ‘example in Figure 5-9 assumes
`a configu'ration that uses the new device-independent bitmap engine.
`The DIB engine assumes a major role in the control of the video dis-
`play under Windows 95. In a configuration that doesn’t use the D13
`engine, the engine and the associated display mini-driver won’t be
`present, and the system components such as GDI interact with a single
`
`j
`
`262
`
`Page 14 of 24
`Page 14 of 24
`
`

`

`S I X: Applications and Devices
`
`
`MS-DOS
`application
`
`Windows
`application
`
`
`
`
`
`(W,-gUa‘l’ggpgmDdmB;) <#:a> Di5P13Y'3d3Pt9r
`
`Screen
`
`Figure 6-9.
`IJ:€s;fM.'a_3; subsystem ro-m.pom=ni.‘.c in an example configuration.
`
`display driver module. That’s essentially how Windows 3.1 works today,
`but in a very large percen Lage of Windows systems, the video hardware
`will be appropriate for use of the new DIB engine and the display mini~
`
`263
`
`
`
`Page 15 of 24
`Page 15 of 24
`
`IPR2017—00048
`
`AMS
`AMS
`Exhibit 2012
`RA v AMS
`IPR2017-00048
`
`Exhibit 2012
`
`RA V AMS
`
`

`

`
`
`1NS|DE WINDOWS 95
`
`
`
`
`—-andon-11-It-:3-onaarbh-so-u-no-|I$Q.fIrfln.Ij..,_.i.go:I
`
`driver architecture introduced with Windows 95. For most purposes,
`you can think of the DIB engine and the mini-driver as a single display
`driver. Windows always assumes that the video display is directly addres-
`sable as a memory region. Display adapters that don't allow this aren’t
`usable by Windows for graphics operations.
`Video system performance is critical to Windows, so, in terms of
`the length of instruction sequences, bringing the video memory and
`the video display adapter as close as possible to GDI is an overriding
`consideration. The device-independent nature of CD1 means that it
`has to go through a device driver to get to the hardware and, in fact,
`two device drivers are involved. One is the Vxl) responsible for vir-
`tualizing the video hardware and controlling the switching of the
`screen between different virtual machines. (This is the VDD in Figure
`6-9.) The other driver is a ring three DLL that always runs in the con-
`text of the system virtual machine. (This is the combination of the dis-
`play mini-driver and the DIB engine in Figure 6-9.) So when the
`Windows desktop is on the screen [meaning that any MS-DOS applica-
`tions are either not running or running in the background), the path
`from a Windows application to the screen is fairly efficient: a call to one
`of the Windows system DLLs, which in turn calls the display driver. No
`ring transition is involved, and the display driver has direct access to
`the video memory.
`If Windows needs to initiate a hardware control operation—for
`example, to switch the screen resolution—it does rely on the dispiay
`driver VxD. Normally, the ring three display driver will use the INT 10
`video services interrupt to do this. The INT causes a fault, which ini-
`tiates a ring transition. The kernel unravels the cause of the fault and
`hands control to the display driver VXD. Typically the display VxD will
`be the only component that mucks with the display adapter hardware.
`The grabber module in Windows 95 is the same as in Windows 3.1.
`To support MS-DOS applications, the system’s WINOLDAP module re-
`lies on a screen grabber for the purpose of saving and restoring the
`state of the video hardware and the video memory. The grabber has to
`match the display hardware type, so the grabber, the display VxD, and
`the display mini-driver are developed in concert. The VXD services
`used by the grabber include functions for Copying data back and forth
`between video memory and a memory buffer, and various synchroniza-
`tion primitives that assist in critical section management and switching
`between virtual machines.
`
`264
`
`Page 16 of 24
`Page 16 of 24
`
`AMS
`
`AMS
`Exhibit 2012
`RA v AMS
`IPR2017-00048
`
`Exhibit 2012
`
`RA V AMS
`
`IPR2017—00048
`
`

`

`5 I X: Applications and DEWCSS
` .
`
`The DIB Engine
`In Windows, a bitmap is a memory-based representation ofa completed
`sequence of (SDI operations. The resulting object is suitable for immedi-
`ate display on a compatible output device, and, in the case of 21 device-
`independent bitmap, minimal additional processing will prepare the
`object for output to a different device. Bitmaps appear in files (the desk-
`top wallpaper, for example). as application resources (the pictures on
`toolbar buttons, for example}, and in main memory. where applica-
`tions and device drivers can build and manipulate them directly. The
`entire Windows desktop display is itselfa large bitmap. and the code that
`deals with updating the screen is critical to the systenfs performance.
`The Windows 95 D13 engine recognizes the current state of dis-
`play hardware by implementing a bitmap management capability that
`deals very efficiently with color flat frame buffer devices. In hardware
`terms, this would mean that the output device provides a large linear
`memory space with each screen pixel directly addressable as a memory
`location. Associated with each pixel is a color. represented by a number
`of bits. The DIB engine handles 1, 4, 8. 16, or 24 bits per pixel