CA2202614A1 - Object-oriented system for servicing windows - Google Patents

Abstract

A window server communicates with clients and creates, destroys and modifies window objects. Objects are created in response to parameters provided by clients. Clients can obtain a variety of information regarding windows managed by the window server. Hardware windows are supported by subclassing objects which provide polymorphic screen objects. Therefore, it does not matter whether the window is created by a hardware or software entity. Clients may be notified by the window server in response to certain events occurring with respect to particular windows, such as a configuration change. The window server also dynamically manages a default window layering scheme which takes into account the parameters specified, or not specified, by clients as well as the characteristics of the windows currently being managed by the window server. The window server also supports window clustering, which allows a window to span monitors. The window server also allows extensive changes to the characteristics of the desktop in response to configuration programs.

Description

WO 96/13026 PCT/lJS9~i/10632 -I -OBJECT-ORIENTED SYSTEM FOR SERVICINC. WINDOW S
Copyrightl~l;r;..-1;....
Portions of this patent application contain materials that are subject to S copyright ~JlV~IiVl~. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document, or the patent disclosure, as it appears m L-he Patent and Trademark Of fice.
Field of the Invention This invention generally relates to iUlll~lVVt~lllt~llb m computer systems and, more particularly, to operating system software for managing window display areas in a graphic user interface.
Background of the Invention One of the most important aspects of a moder~n ~Vlll~U~iUlg system is the mterface beLween the human user and the machine. The earliest and most popular type of interface was text based; a user ~ . ,..., ...., . ;. ~ l.-.~ with the machine by typing text characters on a keyboard and the machine ~vllul~u~ d with the user by displayirlg text characters on a display screen. More recently, graphic user interfaces 20 have become popular where the machine ~l~mmllni~Ates with a user by di~ldyiu g graphics, including text and pictures, on a display screen and the user .. ... , .. , i~
with the machme both by typing in textual l ~mmAnr1~ and by lllalu~uula~illg thedisplayed pictures with a pointmg device, such as a mouse.
Many modern computer systems operate with a graphic user interface called a window environment. In a typical window t'llVilVlUUlt'llL, the graphical display portrayed on the display screen is arranged to resemble the =surface of an electronic "desktop" and each application program running on the computer is l~ d as one or more electronic "paper sheets" displayed in rectangular regions of the screen called "windows".
Each window region generally displays i . . r~ ,. . . ,~ l i. ~. . which is generated by the associated application program and there may be several window regions cimll1fsln~ouslypresentonthedesktop~eachle~ illg illr.,....~i.,.. generatedbya different application program. An application program presents information to the user through each wrndow by drawing or "painting" images, graphics or text within 35 the window region The user, in turn, f~mmllni~ t~s with the application by "pointing at" objects in the wmdow region with a cursor which is controlled by apointing device and m~nir~ tin~ or moving the objects and also by typing information into the keyboard. The window regions may also be moved around on CA 022026l4 1997-04-14 WO 9611302C PCT/I?S95110C32 the display screen and changed in size and appearance so that the user can arrange the desktop in a ~UIIV~IIit!llL manner.
Each of the wmdow regions also typically includes a number of standard graphical objects such as sizing boxes, buttons and scroll bars. These features S represent user interface devices that the usér can pomt at with the cursor to select and malupulate. When the devices are selected or manipulated, the umderlying dlu~ d~iul, program is informed, via the window system, that the control has been .l,dl.iluulal~d by the user.
In general, the window environment described above is part of the computer 10 operatmg system. The operating system also typically includes a co lection of utility programs that enable the computer system to perform basic UU~ldLiul~s, such as storing and retrieving information on a disc memory and pl:lrv~ ,g file ulu~:ldlionb imcluding the creation, naming and renaming of files and, in some cases, p~lrulll"l~g diagnostic ~U~ldLiUllb in order to discover or recover from mAlflmftinnc The last part of the computing system is the "application program" which imteracts with the operating system to provide much higher level fimftinnAlity, perform a specific task and provide a direct interface with the user. The application program typically makes use of operating system functions by sendmg out series of task ...... ,~ . to the operating system which then performs a requested task, for 20 example, the d~ d~iUll program may request that the operating system store particular rnformation on the computer disc memory or display ;.. r.., ...~ on the video display.
Figure 1 is a schematic illl?ctr~tinn of a typical prior art computer system utilizing both an application program and an operating system. The computer system is ct hPm~ti~;311y i~lul~llL~d by dotted box 100, the application is l~ d by box 102 and the operating system by box 106. The lul~viuu~ly-described ll l between the d~Jluli~liul l program lo2 and the operatmg system lo6 is illustrated ~cfhPm~tif~lly by arrow 104. This dual program system is used on mamy types of computer systems ranging from main frames to personal computers.
The method for handling screen displays varies rTom computer to computer and, in this regard, Figure 1 l~ b~llls a prior art personal computer systerf . In order to provide screen displays, application program 102 generally stores ;.. r.. ~l;.. tobedisplayed(thestoringoperationisshowncrh~m~tif~llybyarrow108) into a screen buffer 110. Under control of various hardware and software m the 35 system the contents of the screen buffer 110 are read out of the buffer and provided, asindicateds-l-P--,;~li.,-llybyarrowll4,toadisplayadapterll2. Thedisplay adapter 112 contains hardware and software (cnmf~timPC in the form of firmware) which converts the illfulll~aLiull in screen buffer 110 to a form which can be used to drive the display monitor 118 which is connected to display adapter 112 by cable lI6.

CA 022026l4 l997-04-l4 WO 96r~3026 PC~T/DS95nO632 The prior art . .:,. . ~i~" . . ,. l ;~ln shQwn in Figure 1 generally works well in a system where a single application program 102 is runnmg at any given time. This simple system works properly because the smgle application program 102 can writeil~ru~ aLiull mto any area of the entire screen buffer area 110 without causing a 5 display problem. However, if the ~Ul~ UldliUll shown in Figure 1 -1s used in acomputer system where more than one application program 102 can be ~el~liul,dl at the same time (for example, a "multi-tasking" computer system) display problems can arise. More particularly, if each d~li.dlioll program has access to the entire screen buffer 110, rn the absence of some direct ( -,,~.,.. i. ,-l ;.-.. between applications, 10 one a~li.dLiul, may overwrite a portion of the screen buffer which is being used by amother application, thereby causing the display generated by one d~li.dliull to be UVt'l ~ ll by the display generated by the other application.
A~uldill~;ly, ....o. l ~ ...s were developed to coordinate the operation of the d~li.dLiUll programs to ensure that each application program was conrined to only a portion of the screen buffer thereby s~rArA~in~ the other displays. This ~uuldil~aLiu became ~:ulll~li.dled in systems where windows were allowed to "overlap" on the screen display. When the screen display is arranged so that windows appear to "overlap", a window which appears on the screen in "front" of another wrndow coves and obscures part of the umderlying window. Thus, except for the foremost window, only part of the underlying windows may be drawn on the screen and be "visible" at any given time. Further, because the windows cam be moved or resized by the user, the portion of each window which is visible changes as other windows are moved or resized. Thus, the portion of the screen buffer which is assigned to each application window also changes as windows from other applications are moved or resized.
In order to efficiently manage the changes to the screen buffer necessary to :u-~ nmmr~ t~ rapid screen changes caused by moving or res'lzmg wmdows, the prior art computer ~ shown in Figure l was modified as shown in Figure 2. In this new .- - -, . .g.~ . . l computer system 200 is controlled by one or more d~ dLiu programs, of which programs 202 and 216 are shown, which programs may be running cimllltAn~usly in the computer system. Each of the programs interfaces with the operating system 204 as illllctrAtod s~ h~m~tif~lly by arrows 206 and 220.
However, in order to display infi~rm~tlon on the display screen, d~ dliull programs 202 and 216 send display inf )rm~t~ n to a central window manager program 218 located in the oFerating system 204. The window manager program 218, in turn, interfaces directly with the screen buffer 210 as i111 ICtri3tPfi 5rhl~m~ti~ ;~lly by arrow 208. ~he contents of screen buffer 210 are provided, as indicated by arrow 212, to a display adapter 214 which is connected by a cable 222 to a display monitor 224. = ~

CA 022026l4 l997-04-l4 WO 96/13026 PCTl[rS95/10632 In such a system, the window manager 218 is gnerally responsible for " .,.;, . 1 .; " i "g ail of the window disp~ays that the user views during operation of the application programs. Since the wrndow manager 218 is in ~nmmlmi~tinn with all alul,li dLivl. programs, it can coordrnate between a~ dliOl~ to insure that wmdow 5 displays do not overlap. Consequently, it is generally the task of the window manager to keep track of the location and size of the window and the wrndow areas which must be drawn and redrawn as windows are moved.
The window manager 218 receives display requests from each of the a~ dlivlls 202 and 216. However, since only the window manager 21g mterfaces 10 with the screen buffer 210, it can allocate respective areas of the screen buffer 210 for each application and insure that no application ~l~vl~evu ly UVt'l ~. l;L~s the display generated by another application. There are a number of different window ~l~YilUlUl~ ~ commercially available which utilize the ~ gl'.. .~ ~l illllcfrilt~ll in Figure 2. These include the X/Window Operating e~llVilUlUllC'll~, the WI~DOWS~
15 graphical user interface developed by the Microsoft CvlpuldLivl- and ihe OS/2Pl~l.Ldli~,l.Manager, developedbytheT..I~..-;~I;.,..~lBusinessMachines C~nl)vlaLiull.
Each of these window ~llYil~null~llls has its own internal software àl~l iLt~Lulc~ but the d~ .LUl~ can all be classified by usmg a multi-layer model si_ilar to the multi-layer models used to described computer network software. Atypical multi-layer model includes the following layers:
User Interface Window Manager Resource Control and (~r-mmllnifAtion Cornponent Driver Software Computer Hardware where the term "window t~IIYllUIUII~ " refers to all of the above layers taken together. ~ - -The lowest or computer hardware level includes the basic computer and associated input and output devices mcluding display monitors, keyboards, pointing devices,suchasmiceortrackballs,amdotherstandard..lll,l.vll.-..lc,includrng printers and disc drives. The next or ''~UIIIpOII~III driver software" level consists of device-dependent software that generates the rr)mm~nrlc and signals necessary tooperate the various hardware components. The resource control and fr~mmlmi~tinn 35 layer interfaces with the component drivers and includes software routines which allocate resources, ~r~mmllni~t~ between applications and multiplex ~r~mmllnit ~fir)ns generated by the higher layers to the underlymg layers. The window rnanager handles the user mterface to basic window Ul ~.a~iu-ls, such as moving and resizing wmdows, activating or illd~LiYalillg windows and redrawing CA 022026l4 l997-04-l4 6 PCI-/US95/lOG32 and l~JaiL~ g windows. The final user interface layer provides high level facilities that ;...~ the various controls (buttons, sliders, boxes and other contro]s) that application programs use to develop a complete user interface.
Although the ,. . . ,-~ l shown in F;gure 2 solves the display screen s ~ rl ~ problem, it suffers from the drawback that the window manager 218 must process the screen display requests generated by all of the application programs. Since the requests can only be processed serially, the requests are queued for ~ ~lLdLivll to the window manager before each request is processed to generate a display on terminal 224. In a display where many windows are preSent F; nllltAnPnusly on the screen, the wmdow manager 218 can easily become a ' b~ . k" for display ilirulll-alivl~ and prevent rapid changes by of the display by the a~ li dlivll programs 202 and 216. A delay in the r~lldwillg of the screen when windows are moved or l~,o~iLiul.ed by the user often manifests itself by the a~ ald~ that the wmdows are being constructed m a piecemeal fashion which lS becomes anrloying amd detracts from the operation of the system.
A~ulvil~gly, it is an object of the present invention to provide a window manager which can interface with application programs m such a manner that the screen display generated by each a~luli~a~ivll program can be quickly and effectively redrawn.
It is another object of the present mvention to provide a window manager which uvlvil~aL~s the display ~PnPrAtinn for all of the application programs orclients in order to prevent the alu~Jli aliOl~ or clients from intPrfPrin~ with each o&er or UV~l VVlilillg each other on the screen display.
It is yet another object of the present invention to provide a window manager which can interact with the application programs or clients by means of a simplecommand structure without the application programs being concerned with actual imrlPmPntAtinn details.
It is yet another object of the present invention to provide a window manager which allows application program developers who need detailed control over the screen display process to achieve &is control by means of a full set of display control nmmAnfls which are available, but need not be used by each application program.
Summary of &e Invention The foregoing problems are overcome and the foregoimg objects are achieved in an illustrative embodiment of the invention m which an object-oriented windowserver provides covlvil~aLiùl- between clients and the display system. Each client may create windows by sending pArAmPtPrs to the window server. The window server creates window objects in accordance with the ~ The object-oriented design, and in particular the unique fhAr:~rtPric~i~c of the objects created by the window server, provide a consistent interface for clients desiring to create, modify and destroy various aspects of the display space, such as the desktop andelements thereof.
Upon receiving the p~l .. ~1.-.~, the window server df~tPrmin~c whether S particular ~ are present. If particular pArAm~tPrc are present, a window is displayed in a pQsition relative to the screen space and other wmdows according to the p,-.. ~ . If the particular pArAm.otPrc are not present the wmdow is displayed using a default layering scheme, and the window takes on p~ associated with the already displayed windows.
The window server also provides hardware windows which may be created by b' .~ g to create a polyll-u~ ic screen device object. It is then irrelevant to the window server whether the client is a hardware or software entity.
The window se~ver further supports spannmg of monitors by creating a cluster object which contains the mternal windows necessary to span the monitors.
Brief ~ liull of the Drawings The above and further advantages of the invention may be better understood by refer~ing to the following-description in ~r~njlmrtinn with the a~u~ allyi~g drawings, in which:
Figure 1 is a schematic block diagram of a prior art computer system showing the rl~lAtionchir of the dp~ alibll program, the operating system, the screen buffer and, the display monitor.
Figure 2 is a schematic block diagram of a mn lifi~ Atil~n of the prior art system shown in Figure 1 which allows several application programs running cim1-ltAn~llcly to generate screen displays.
Figure 3 is a block schematic diagram of a computer system for example, a personal computer system on which the inventive object oriented window manager operates.
Figure 4 is a schematic block diagram of a modified computer system showing 30 theil,l,-.,li.,betweenapluralityofapplicationprogramsandthewindow manager in screen buffer in order to display graphic inf )rm~tif~n on the display monitor.
Figure5isablockschematicdiagramofthe illr.~l...~l;~".pathswhichindicate the manner in which an d,U~UIi~d~iUll program ( I~mmllnirAtl~c with the inventive object 35 oriented manager.
Figure 6 is a block diagram showing the system level Window Server, and the relation between the Window Server and the Clients.

CA 022026l4 l997-04-l4 wo 96/13026 r~ u~

Figure 7 is a block diagram demu.lsl-dli..g the elements and ~lpPrAti~nc involved with parameter passing from a Client to the Window Server im order to create a window.
Figure 8 is a flowchart describing how a window i3 pu~;Liu- æd by the Window S Server m response to spP~-ifit Atinn of window kind and position by the Client.
Figure 9 is a block diagram d~m~ how a Client interacts with window objects to create notification instances. = ~ ~
Figure I0 is a block diagram which shows the int~rArti~nc between windows, the Window Server, arld event server in a preferred ~ Odil~lellL of the present 10 mvention.
Figure II is a block diagram dPm.~ that for each display device that makes up the desktop, there is an IO access manager.
Figure 12 shows the elements and flow of U~ dLiUlls between ~Ullri~;UldLilJII
teams, the display device rldlllew-)lh, the Window Server, and display device acoess 15 manager. = _ Figure 13 shows the classes used for accessmg the desktop geometry.
Figure 14 is a Booch diagram depicting how each component graf device is el~les~llLed by a subclass of TGrafDevice and MScreenDevice.
Figure 15 is a block diagram showing the windows of a Client team, and the 20 windows of the Window Server.
Figure I6 is a Booch diagram ~1.-.. ,..,~..1. ,.1 ;..~ TlnternalWmdow being sub~ld~ed in order to iull~JlelllellL hardware wmdows.
Figure 17 is a Booch diagram showing the subclassmg of TSystem Wmdow and TlnternalWindow.
Figure 18 is a block diagram which shows that for each display device that makes up the de3htop, there is a TDisplayDevice that lives in the window.
Figure I9 is a block diagram illustrating how internal windows are created.
Figure 20 illustrates by block diagram a window which spans three different monitors.
Figure 21 illustrates the sy3tem used to enable the window to span the three monitors.
Figure 22 i3 a Booch diagram illustrating the objects necessary to support the spanning of monitors.
Detailed Description of a Preferred Embodiment of the Invention The im~ention is lulereldbly practiced in the context of an operating system resident on a personal computer such as the IBM~ PS/2, or Apple~ Macmtosh, computer. A le~leS~llLdLiv~ hardware ~llvilulullellL is depicted in Figurê 3, which illustrates a typical hardware ~UIIrigUldLiOll of a computer 300 in accorclance with the CA 022026l4 1997-04-14 WO 96/13026 PCI'IUS95110632 subject invention. The computer 300 is controlled by a central processing unit 302 (which may be a conventional microprocessor) and a number of oeher units, al1 interconnected via a system bus 308, are provided to ~rrr~mrlish specific tasks.Although a particular computer may only have some of the units illustrated in Figure 5 3, or may have arl~itinn~l rr,mrr,nr-nts not shown, most ~UIII~JUIt~ID will include at least the units shown.
Specifically, computer 300 shown in Figure 3 includes a random access memory (RAM) 306 for Ll~ dly storage of; r~ , a read only memory (ROM) 304 for p~ all~lll storage of the computer's ~VI~i~,UldliVll and basic 10 operating e --mm~n~c and an input/output (I/O) adapter 310 for . ~ ., ...~ 1 ;"g peripheral devices such as a disk unit 313 amd printer 314 to the bus 308, via cables 315 and 312, .~D~e.~iv~ly. A user interface~adapter 316 is also provided for ~.,.,..~. l;.-ginputdevices,suchasakeyboard320,andotherknownrnterfacedevices includimg mice, speakers and microphones to the bus 308. Visual output is provided by a display adapter 318 which connects the bus 308 to a display device 322, such as a video monitor. The WVl}~DLd~iVI~ has resident thereon and is controlled and ~vuldil,d~e,l by operating system software such as the Apple System/7, operatingsystem.
~a preferred embodrment, the invention is ;. . .l .l~. . ,.~. .i. .~ in the C++
~ 'g ,.. ;.. g language using object-oriented ~lVg.~.. ; .~ prhniqll~q C++ is a compiled language, that is, programs are written in a human-readable script and this script is then provided to another program called a compiler which generates a machine-readable numeric code that can be loaded into, and directly executed by, a computer. As described below, the C++ language has certain rh~rAct~rictirc which25 allow a software developer to easily use programs written by others while still providing a great deal of control over the reuse of programs to prevent their destruction or improper use. The C++ language is well-known and many articles and texts are available which describe the language in detail. In addition, C++
compilers are commercially available from several vendors includimg Borland 30 T ~ l, lnc. and Microsoft Corporation. A~ ldi~,ly, for reasons of clarity, the details of the C++ language and the operation of the C++ compiler will not be discussed further in detail herein.
As will be understood by those skilled in the art, Object-Oriented Plu~ lll;llg (OOP) techniques involve the definition, creation, use amd destruction 35 of "objects". These objects are software entities VIIIlJl;Dil~g data elements and routines, or fur~ctions, which manipulate the data elements. The data and related functions are treated by the software as an entity and can be created, used and deleted as if they were a single item. Together, the data and functions enable objects to model virtually any real-world entity in terms of its rh~r~rtrricti~c which can be WO ~6/13026 PCT/~JS95/10632 - g l~,L~ led by the data elements, and its behavior, which can be ~ L~d by its ddta .~ alli~ulaliull functions. In this way, objects can mûdel concrete things like people and UJlll~/U~ l, and they can also model abstract concepts like numbers or "", ~"~ ,.1 designs-S Objects are defined by creating "dasses" whidh are not objects ~ lv~b, but whidh act as templates that instruct the compiler how to construct the actual object.
A class may, for example, specify the number and type of data variables and the steps involved im the functions whidh uldl~uldL~ the data. An object is actuallycreated in the program by means of a special flmction called a ol~ll u.l.,~ which uses the corresponding dass definition and ~ tinnA~ such as al~;
provided during object creation, to construct the object. Likewise objects are destroyed by a special function called a d~tl u~lul . Objects may be used by using their data and invoking their functions.
The principle benefits of object-oriented ~.. -~;~ ." ,.- ,.;,)~, t~rhniTl.oq arise out of 15 three basic ~lill.i~le~j en d~uldLi ~l" polymorphism and inhf~rit~nf~ More specifically, objects can be designed to hide, or ~ , all, or a portion of, the mternal data structure and the internal functions. More particularly, during program design, a program developer can define objects in which all or some of the data variables and all or some of the related functions are r~ iPn~l "private" or for use 20 only by the object itself. Other data or functions can be declared "public" or available for use by other programs. Access to the private variables by other programs can be controlled by defining public functions for an object which access the object's private data. The public functions form a controlled and consistent interface between the private data and the "outside" world. Any attempt to write program code which 25 directly accesses the private variables causes the cornpiler to generate an error during program ~ ~)mril~til~n which error stops the compilation process and prevents the program from being run.
Polymorphism is a concept which allows objects amd functions which have the same overall format, but which work with different data, to function dirr~ Lly in 30 order to produce consistent results. For example, an addition flmction may bedefined as variable A plus variable B (A+B) and this same format can be used whether the A and B are numbers, characters or dollars and cents. However, the actual program code whidh performs the addition may differ widely depending on the type of variables that comprise A and B. Polymorphism allows three separate 35 flmction ~1~fini~inns to be written, one for each type of variable (numbers, characters dnd dollars). After the functions have been defined, a program can later refer to the addition function by its common formât (A+B) and, during compilation, the C++
compiler will determine which of the three functions is actually being used by t ~ ., i ; 1~ the variable types. The compiler will then substitute the proper flmction WO 96/13026 r~ a., "10632 - 10 - ~
code. Polyll.u.~l ihll. allows similar functions whidh produce amalogous results to be "grouped" rn the program source code to produce a more logical and clear programflow.
The third principle which umderlies object-oriented ~I~ )~, ,.. i .. ~, is s inh~ritAnfP, which allows program developers to easily reuse pre-existing programs and to avoid creating software from scratch. The principle of inhPritAnf~ allows a software developer to declare classes (and the objects whidh are later created from them) as related. Specifically, dasses may be r1~cionAtPd as subdasses of other base classes. A subdass "inherits" and has access to all of the public functions of its base 10 dasses just as if these function appeared rn the subclass. All~ aLiv~:ly~ a subclass can override some or all of its inherited functions or may modify some or all of itsinherited functions merely by defining a new function with the same form (overriding or mn~iifi/ Ation does not alter the function m the base class, but merely modifies the use of the function in the subclass). The creation of a new subclass 15 whichhassomeofthen]nrhnnAlity(withselectivell,n.lir;.,,li...~)ofanotherclass allows software developers to easily customize existing code to meet their particular needs.
Although object-oriented ~II -~;I ~1 l l l l l l i l l~, offers ci~nifi--Ant irnprovements over other Ul~r,"" I . . . i 1 g concepts, program development still requires 5i~nifi~Anf outlays 20 of time and effort, especially if no pre-existing software programs are available for mnrlifil Ation Consequently, a prior art approach has been to provide a program developer with a set of pre-defined, intercomnected dasses whidh create a set ofobjects and A~l~litit~nAI mic~ ~llAn.or~u5 routines that are all directed to ~, r~. " i. g commonly-~ll.uull~ d tashs in a particular environment. Such pre-defined classes25 and libraries are typically called "frameworhs" and essentially provide a pre-fabricated structure for a working application.
For example, an framework for a user mterface might provide a set of pre-defimed graphic interface objects whidh create windows, scroll bars, menus, etc. and provide the support and "default" behavior for these graphic interface objects. Since 30 rldlll~wulh~ are based on object-oriented techniques, the pre-defined dasses can be used as base dasses and the built-in default behavior can be inherited by developer-derined subclasses and either modified or overridden to allow developers to extend the rldlll~wulh and create ~lctnmi7Pfl solutions m a particular area of expertise. This object-oriented approadh provides a major advantage over trA~litir~nAl lJlu~
35 since the ,Ul~;l-lllllll~l is not changing the original program, but rather extending the hil; I ;I-h of the original program. In addition, d~v~lu~ are not blindly worhing through layers of code because the framework provides dl~ -1 guidance and modeling and, at the same time, frees the developers to supply specific actions unique tQ the problem domain.

CA 022026l4 l997-04-l4 WO ~16/13026 r _ I/U~

There are many kinds of rla~ wul~ available, depending on the level of the system involved and the kind of problem to be solved. The types of frameworks range from high-level application rld...~wulks thdt assist in developing a user interface, to lower-level rrameworks that provide basic system software services such S as e nmm.mi~Atinnc printing, file systems support, graphics, etc. Commercialexamples of àl~li aliull r.a l....U~ include MacApp (Apple), Bedrock (Symantec),OWL (Borland), NeXT Step App Kit (NeXT), ând Smalltalk-80 MVC (ParcPlace).
While the framework approach utilizes all the principles of ~n~ Arsl11Atinn, polylllvl~i~ and ;~ in the obiect layer~ ând is a sllhstAntiAl illl~luv~lllt:
10 over other ~l~'g r~ tPf~hni~ c there are ~iffi~llh'~C which arise. Application rlalll. .. Ul~ generally consist of one or more object "layers" on top of a mnnn1ithi~-operating system and even with the flexibility of the object layer, it is still often necessary to directly interact with the underlying operating system by means of âwkward procedural calls.
In the same way that an application framework provides the developer with prefâb nln~tinnAIity for an application program, a system rramework, such as that included in a preferred embodiment, can provide a prefab fi1n~tinnA1ity for system level services which developers can modify or override to create .. ~l.. i,.. ~l solutions, thereby avoiding the awkward ~lu~duldl calls necessary with the prior20 art application frameworks programs. For example, corisider a display r~dll~wulk which could provide the fmm~lAtinn for creating, deletirlg and ll~dlL~UIdlillg wmdows to display illrullllaLiol~ generated by ân d~ dliu-~ program. An a~ dtioll softwdre developer who needed these capabilities would ordinarily haveto write specific routines to provide them. To do this with a rramework, the 25 developer only needs to supply the rhArA"t~riCtifC and behavior of the finished display, while the framework provides the âctual routines which perform the tasks.
A preferred embodiment tdkes the concept of frameworks and applies it tl--uu~lluul the entire system, including the alululi dliol~ dnd the operating system.
For the commerciai or corporate developer, systems integrator, or OEM, this means 30 all of the advantages that have been illl lCtrAt~d for a rla...~wul~ such as MacApp can be leveraged not only at the dlu~ aliull level for such things as text and user interfaces, but also at the system level, for services such as printing, graphics, multi-media, file systems, I/O, testing, etc.
Figure 4 shows a schematic overview of a computer system utilizing the 35 object-oriented window manager of the present invention. The computer system is shown generally as dotted box 400 and several d~li.dLiu-- programs (of which application programs 402 and 418 are shown) and an operating system 404 are provided to control and coordinate the operations of the computer. In order to simpliry Figure 4, the interaction of the application programs 402 and 418 with the CA 022026l4 l997-04-l4 wo 96/13026 PCTIUSg5/10632 operatingsystem404islimitedtothei,.1r.,.. l;.,..~dealingwiththescreendisplays.
As shown in the figure, both application programs 402 and 418 interrace with thewimdow manager portion 420 of the operating system 404. The window manager 420, in tu~n, sends information to the screen buffer 412 as !srhrm~tir~lly illustrated by 5 aFrow 408.
However, in accordance with the invention, and, as shown m Figure 4, application programs 402 and 418 also directly send i ~ to the screen buffer 412 as illustrated by aFrOWs 410 and 428. As will ll~iu~rL~I be explained in detail, application programs 402 and 418 provide display i,.r.., ...~li...~ directly to the 10 window 420 and retrieve stored i.. r.. ~l i.. , from window manager 420 when a window display is changed. More specifically, when a window is changed~ window manager 420 l~.ulll~uL~s and stores the visible area of each window. This storedvisible area is retrieved by the respective a~li aLiull program and used as a clipprng region mto which the a~li~aLiul~ draws the display information. Repainting or 15 drawrng of the windows is p~lrulllled ~ p~u~ly by the alululi~aLioll programs in order to increase the screen repamting speed.
The application displays are kept separated on the display screen because the window manager 420 I~UIIII~UL~ the window visible aFeas so that none of the areas overlap. Thus, if each application program, such as application program 402 or 20 application program 418 draws only in the vi3ible area provided to it by the window manager 420, there will be no overlap in the displays produced by the screen buffer.
Once the display i, . rl .. ~ l il )l l is drawn into the screen buffer 4l2 it is provided~ as indicated by aFrow 414, to a display adapter 416 which is, in turn, connected bycable, or bus, 424 to the display monitor 426.
The intPr~rtirn of an application program with the window manager is illustrated in more detail in schematic diagram Figure 5. As ~ viuu~ly m~ntirlnP~I, the window manager (illustrated as box 510 in Figure 5) is an object-oriented program. A~-uldill~,ly, an a~ aLiull program 508 interfaces with the window manager by creating and manipulating "objects". In particular, each application 3û program create3 a window object, for example, window object 500 in order to rr~mmllnir;lt~ with window manager 510. The alululi~aliull program 508 then ..."."...,.~ withthewindowobject500asshowncrhPm:ltir~llybyarrow502.
The window manager itself is an object which is created when the operating system is started and creation of a window object causes the window manager 510 to create 35 an associated window on the display screen.
Since many window objects may be created simll1t~nPr~llcly in order to ciml]lt~nPr,llcly display many windows on the display screen, each window object500 rr,mmlmirltPS with the window manager 510 by means of a data stream 504.
Data strearn 504 is created by creating "stream" objects which contain the software Wo 96113026 r~".,~ r-~

" ,.~ . . " _ . ,.1,~ necessary to trarlsfer; . . r~ from one abject to another. For example, when window object 500 desires to transfer; - - r~ - to window manager object 510, window object 500 creates a stream object which "streams" the data into wimdow manager object 510. Similarly, wh_n window manager object 510 5 desires to transfer i. .r~ back to window object 500, window manager object 510 creates a stream object which "streams" the data mto window object 500. Suchstream objects are ul~v~ tiul~al in nature and not described im detail herein. The stream objects which carry data from window object 500 to window manager object 510andthestreamobjectswhichcarry;.. r.. ~1i.,.. fromwindowmanagerobject510 to window object 500 are illllctrAt~d collectively as arrow 504.
As shown in Figure 5, window manager object 510 consists of three main parts: the visible area manager 506, the shared data area 512 and the window list 514.
The visible area manager 506 is an independent task which is started by the window manager 510 when the window manager 510 is created. As will be h~.~.udrl~ l 15 explained in detail, the visible area manager is l~un~ible for managing the portions of the wmdow which are visible on the data display screen. To this end, it l~U~ JUl~ a window's visible area when either a window, or another wmdow located in "front" of the window is changed. It also performs a number of other h....~ g tasks, such as the repair of desktop "damage" which occurs when 20 windows are reoriented or resized and expose ~.~viuwly-covered areas of the umderlying "desktop".
The shared data area 512 comprises an area in shared memory and associated storage and retrieval routmes which together store illfUI . ,~aliul, related to the windows. The shared data area is created by the wimdow manager in shared 25 memory and a portion of the shared data area is assigned to each of the windows and contairls various window ~ mcluding a "time stamp" indicatmg the version of the visible area.
In order to reduce the use of a message stream to access the visible area, each window obiect 500 also mamtains a local "cache" memory which stores a copy of the 30 visible area of the ~:C~ t~ wmdovr. A time stamp is also stored m the local cache memory, which time stamp mdicates the last version of the visible area that was retrieved from the Window Server. When an d~ dliUII program begins a redrawing operation, it requests the visible area from the window object. The window object, in turn, retrieves a time stamp from the shared memory area and 35 compares the retrieved time stamp to the time stamp stored in the local cachememory. If the ~ f the two time stamps indicates that the visible area was not modified, then the copy of the visible area stored in the local cache memory is -usedforthel~dldwil~goperation. All~ll,aliv~ly,ifthetimestamp....-il.,..;~.... -indicates that the window manager has updated the vislble area, then a new visible _ CA 022026l4 l997-04-l4 area must be retrieved and stored in the local cache aIea. The retrieval of the time starnp alone is rnuch faster than the retrieval of the entire visible area so that the overall l~Vla~Villg time is reduced if the local cached copy can be used.
Window manager 510 also maintains a window list 514 which is illubl~alh, ~
5 imrl.om~nt~l as a linked list that contains an if lf~ntifirAfi~n number for each window currently in the system. In accordance with a preferred embodiment of the invention, each window is assigned a window "kind". Window kinds are selected from a kind hierarchy which generally follows the relative pObiliullillg of the windows on the screen. An illustrative kind hierarchy is as follows (wmdow kinds10 are illustrated starting with the window kind which normally appears im the foremost window position):
Foremost Position: screen saver, menu bar, menu, wmdoid (intended for floatmg palettes and other similar type of window), and document. Rearmost Position desktop.
The wrndow manager Allt~mAti~'Ally maintains the windows displayed on the screen in a manner such that windows of a srmilar kind are all pobiliul-ed together in a kind "layer". This ~usi~iul..l-g is accomplished by inserting "place holders" in the window list indicating divisions between kind layers. The window manager can then iterate through the window list until it reaches one of these place holders to 20 determine when the end of a particular kind layer has been reached in the start of a new kind layer begrns.
As ~ ViUUbly ~ -1, rn accordance with a preferred embodiment, the operating system is capable of rurlning multiple tasks cimlllfAnpnusly and, whenever two or more tasks are operating b; . . . -11 I''l-Ubly, there is a potential for mutual 25 ; .l~ ~ I ;., Such mutual i ~ can occur when two or more tasks attempt to access ~.;.. l l ~ l~f~.. -~ly shared resources, such as the shared data area or the window list. A~ulvil~gly, ~Ul~Ul~ y controls are necessary to manage such ;. l.-. ,.. l ;. ~. .c and to prevent unwanted i~ . An illustrative concurrency control technique known as a b~ll-a~ u~: is used in one embodiment. Semaphores are well-known 30 devices which are used to "serialize" concurrent access attempts to a resource. In particular, before a task can access a resource which is controlled by a semaphore, the task must "acquire" the semaphore. When the task is finished with the resource it releases the ~ for ?f ql~ ihfm by another task. Each semaphore generally has a request queue associated with it so that requests to acquire the semaphore35 which cannot be honored (because the semaphore has been acquired by another task) are held on the queue.
In the present system, b~ a~llvl~b are used to protect several different shared resources. rn particular, a global drawing b~...alul~vl~ is used to prevent the application programs from int~r?rtin~ with the window manager. Before accessing CA 022026l4 l997-04-l4 WO 96/~3026 PCT~US95no632 the visible area, each application program must acquire the drawimg b~l~ldllllul~. The drawing semaphore used in the present system has two modes: a shared mode and am exclusive mûde. In accordance with the rnvention, application programs may write in the screen buffer cimlllt~nPrnlcly with other application programs and S therefore must acquire the drawing semaphore in the "shared" mode. Since the application programs are kept s-eparate in the screen buffer by the wimdow manager, this ~;.. ll,.. ~P.. ~ access does not present a problem. However, the window manager performs ulu~laliulls, such as creating a new window, which can affect all windows and, thus, the window manager must acquire the drawing b~llla~l~Ule m 10 the "exclusive" mode. When the window manager hac acquired the drawing b~ Uld~l~U~ u~iv~ly, the dl~li dliul)c cannot acquire the semaphore and thus cannot write m the screen buffer. This exclusive operation prevents the a~",li dliul.s fromuv~lvvliLulgchangedportion~cofthescreenbufferbeforetheyhavebeen rnformed of the changes. ~ ~
In a similar manner, global be' Id~ Ol ~b are used to protect the shared data area 512 in the wmdow manager 510 which shared area is also a shared resource. A
similar local b~lllalullul~ is used to protect the wimdow list 5l4 from ~ ll ls access by different application programs using the Window Server. The specific ~. TIicitir.n and release of the various s~l.a~llul~b will be discussed in further detail 20 herem when tlle actual routines used by the programs are discussed in detail.The Window Server, which may also be referred to as a layer server, is used to allocate and manage screen real-estate for all running programs. The Wmdow Server m accordance with the present invention performs numerous f~mctions in addition to tr~-litit~n:~l Window Server functions. The functions include: recovery 25 fromtasksthatdiewhileholdingadrawingb~ll.a~l~ul~, userl.--r;~ ofthe display (changing bit depths, monitor positions) while the operating system is running; ~luy~lauulLer access to the desktop geometry; hardware windows, e.g allowingwindowstobe~-rPlPr~tP~lbyl-dl-lwdl~, use~ ri.,.l;~.~.insteadofevents for updates and activate/deactivate; iu~ull ulal~ m~n~Pm~nt of display devices.
Figure 6 shows the Wmdow Server 606 at systern level 608. The Window Server 606 is privately used by a variety of Clients 600 and 610 within the computer system. Seldom would there be a need for a ~lU~ldllUII~I to deal with the WindowServer 606. For example, the objects and portions ûf the system which create andmanipulate wmdows could be considereda Client of the Window Server 606.
Another example would be such entities as the document level window manager;~
pPrcl~n:llitif~c, such as a Mac or OS/2 adapter (to create and manipulate wmdows);
..,.,f;,g...,~i,...models(tol~-ol-rigul~displays); andthegraphicssystem(toquery and ll.al.i,uuldl~ display devices).

CA 022026l4 l997-04-l4 -16-:
In addition, the Window Server 606 can be extended by display device driver writers. For example, the Window Server 606 can be extended to ~ .lL
hardware wrndows 616, if the hardware supports them, and to add graphics filnrtirlnAlity 618. The ~~ ,iulls are shûwn in phantom broken lines in Figure 6 to 5 denote that they are r~ . of the Window Server 606.
The Wrndow Server 606 is an object-oriented system which divides available screen area among all running programs. There may also be window managers at other levels which use the system level window manager. For example, the system may include a document-level window manager which manages the screen space 10 within a document's window.
Window server Clients 600 and 610 create windows that have a certain bounds (an arbitrary area). The Clients may be system level 610 or non-system level 600. Based on the ordering of windows and how they overlap, the Window Server 606 can determine the visible part of each window. Clients are expected to restrict 15 drawing to this area.
To support special user interface features (e g., floating windows), the Window Server 606 defines a number of window kinds, as indicated by 620. These kinds are ordered and the Window Server 606 ensures that all the windows of one kind are in front of all windows of the following kinds. The full set of kinds is 20 described below, but it mcludes things like menu bar, windoid, r~rlrlmnrnt and desktop.
The Wrndow Server 606 also maintains an update area 604 for each window, which describes the part of the window that has been "damaged" due to window Illa~ uulaliulls. (Damage that is caused within the document itself is managed by the 25 document window manager. For example, the document window manager manages damage caused by view manipulation, invalidation, etC.2 The Window Server 606 notifies the Client 600 (such as the document window manager), as shown by 602, when one of its window's update areasbecomes non-empty. It also will erase the damaged parts of windows, which can be partially controlled by Clients (such as the 30 document window manager) on a wmdow-by-wrndow basis.
The Window Server 606 also notifies Clients, shown by 602, (such as the document window manager) when a window is activated or deactivated. The front-most window is the active window, all others are deactivated.
The Wmdow Server 606 also maintains infor n~tir~n about the display devices 35 that make up the desktop rn Desktop Display Device Info 614. (~onfignr~tion Programs 612 can query and modify this information to change bit depth, monitor positioning, and other hardware specific attributes of the displays.

wo 96/13026 r~ "v~

The following .1 ic....~i. ,.. refers to objects using object names preceded by a capital "T." For example, the system window object is referred to as TSystem Window.
Client Classes Certain classes allow Clients to create, destroy, and manipulate wmdows. For example:
1. TSystemWindow creates a new window. T~ .c~ i .g the object creates 10 the window; deleting the object destroys the window.
2. TSystemW ndo .. rJullv~al~ acts like just ike TSystemWindow, except ~Llv~ g the surrogate has no effect on the real window.
Figure 7 shows window creation. To create a window, the C7lient 700 (the document window manager or a personality) creates a TSystemWindow, passing in totheWindowServer706atthesystemlevel708thefollowing~.,.. rl~ the extent (position and shape) of the window (expressed as an area object in world ~vu~dillal~:b); an event receiver ID to identify the task that receives events and notifirAtion for the windowi the front-to-back ordering of the window; whether the window should be visible initialy; whether the Window Server shou d 20 A7ltnmAtirAIly erase damaged parts of the window; and the kind of wmdow.
The Window Server supports a basic set of u~lali~llb on a window. C7ients can obtain i r .... ,~ I i. - about a wimdow, including its event receiver ID, its current update area, and its current visible area as shown in Figure 7 by the arrow from the Window Server 706 to the Client 700. In addition, C7lients can modify attributes of 25 the window - they can dhange the extent of the window, hide or show the window, and brmg the window to the front of other windows of the same kind, as indicatedby the arrow from C7lient 700 to Window Server 706.
Pigure 8 is a flowdhart which v~lllvlL~Llal~s how a window is positioned by the window manager in response to information from the Clierlt. There are two 30 ways to specify the window p. ,~il i~ .. .;. .~" eadh having its own ~UIlSLl U~IUI. First, the Client can specify the window's kmd and whether it should be the frontmost or backmost window of that kind. The .1.~ as to whether this infnrmAtinn is given is indicated by the decision at 800. if kind and position are specified, the window is positioned 802. Second, if the kind has not been spècified, the new 35 window can be positioned 804 i.... r~ ly in front of or behind an existing window (thereby adopting its kind 806).
r ubda~s~ of TSystemWindow can be used to create hardware-specific windows. This will be discussed in depth in the Hardware Windows section below.
.

When a window is changed, the Window Server recomputes its visible area, (possibly) addirlg to the window's update area. It also sends n(-tifir~tinn to Clients when a window needs updating or when the active state of a window changes. Each window maintains a time stamp that indicates the current "version" of its visible 5 area. Clients can use this to detect when a window's visible area changes, andperform rncremental updates based on the current visible area and the old area.
A l the u~laliu~ on a window are available in the TSystemWindow class and the nearly identical TSystemWindowSurrogate class. The difference between the two classes is that there is a one-to-one mapping between "physical" windows10 and TSystemWindow instances. Creating the object creates the window; deleting the object destroys the window. This means that TSystemWindow instances cannot be copied or passed to other tasks. Instances of TSystemWindowSurrogate can be copied and passed around, and can be changed to refer to other windows. Deleting a Tsystemwindu~rJ~lllu~,aL~ object has no effect on the existence of the window on the 15 screen.
TSystemWindow dass can ..I~ lll global wrndow functions through a number of static member functions. For example, it is possible to get the windowr~n~inin~ a particular screen point and process a mouse click, or to stop and start system drawing.
The wmdow sends events to an application when a window becomes active or inactive, and when a wmdow needs to be updated because it is damaged. The primary Client for t~us service is the document window manager.
Instead of posting events, the window uses notification. TSystemWmdow andTSystemWindu~. S lll Ivy~aL~ canbenotifiers.
A shown m Figure 9, Client 900 can ask, as indicated by 906, either of these classes 902 to create interests, via Instance Creation 904, for A~lival~7il1dow This window has become active.
DeactivateWindow Another window has become active.
WindowUpdate This window is damaged and must be redrawn.
Window activation no~iri~aliùll is not necessarily synchronous with events being received by a ~ mrnt For éxample~ if the user clicks on an inactive wmdow and then starts typing, mouse and key events may be delivered to the doculnent prior to the activate noliri~aliu--. The benefits of using notification vs. events for activationarel)betterp~.~". ~ rP,and2) aneasier~ g,-", ;"~ model,which results in more m~ code.
Figure 10 is a block diagram which shows the int~r~rti( nc between windows, the Window Server 1004, and Event Server 1002 in a preferred embodiment of the CA 022026l4 l997-04-l4 wo 96~13026 PC'r/~S9~OG32 ,Ig present invention. The Window Server 1004 mamtains which window }eceives default events (e.g. keystrokes) using a default director lU06. The window whichreceives default events is always the frontmost (unless the document wmdow manager specified that the window could not receive default events).
- 5 The fl~ .. ; .. l i.. , . of who should receive default events is performed by an event server 1002. One of the windows 1000 will notify the event server 1002 (usmg a Client class~ each time a new window becomes frontmost. The Window Server will pass the event receiver ID of the window to the event server. The event server will use this . ~ll.,alio.. to ~7PtPrminr- who should get default events.
The window provides a drawing semaphore which protects access to the set of window vi3ible areas. Before modifying any visible area, the wirldow acquires this ~ellld~hul~ Before drawing rnto a visible area, a Client must acquire this semaphore im shared mode.
The effect of this convention is that when the wmdow needs to modify any visible area it blocks Imtil all the current drawmg up~ldLiulls finish. New drawing operations are not allowed to begin umtil the window is done. This insures that when a Client draws, the visible area is mdeed correct. Because a Client's drawing is clipped to the visible area by the document window manager, this insures that a Client won't draw into a part of the screen not assigned to it.
One problem that may be encountered is that a Client task may die while holding the drawing ~..,dl,hul~. System kernels do not release ~t llla~llul~ held by dead tasks. Tlle result is disastrous because a71 drawing c7PAf7lorkc, which looks like a ull~ L~ly hung system to the end user. This situation is remedied m a preferred embodimentbyaddingarecoverableb~,,,d~lu~l~f,TR~uv.:ld7,1æ~,aphul~)tothe system kernel. When a task dies that is holding this ~ll,dphol~, the kernel A-ltr,mAhrAlly releases it.
TSystemWindow and TSystemWindowSurrogate have member flmctions to aUow Clients access to this ~llla~ ul~ These member flmctions include the ability to acquire, release, and wait for semaphores.
Figure 11 is a block diagram f7rnnf" .~l, ,. l i. ,~ that for each display device that makes up the desktop, there is an IO access rnanager 1104. There may be one or more Client teams 1100 which have IO access m~nA~f rc TDisplayDevirf-~Anf7l 1102 areClientobjectsusedto1.""""".i."l,-withthedisplaydevice.
Display device IO access managers l lO4 are l~1 ol~i~le for l l .~ g and Illdlu~ul~lLillg the state of the hardware display device, such as monitor bit depth and position. Display device handles are used by ~ullrly,UldLiul~ programs to changethese attributes.
Display device driver writers must subclass TDisplayDeviceHandle to support the rArAhilitirs provided by their hardware. If a card performs a unique CA 022026l4 l997-04-l4 runction, such as video overlay with chroma keymg, for example, the ~ub~la~
would add member functions to TDisplayDeviceHandle to allow Clients to access this feature.
Cu~lri~;uldLiull prog-rams need to stop all drawing prior to le-uliri~,ulillg the 5 screen. Bit depth and monitor position are examples of things that the user can le~ullfi~;ule.
Figure 12 shows the elements and flow of u~elaLiullb between cul~rlguldLiu Tearns 1200, the Display Device r.alllewul~ 1206, the Window Server 1204, ând Display Device Access Manager 1212. The steps outlined below .. ,.. ~ .n~l to the 10 circled numbers of Figure 12. - -1) Cul.r.~;uldLiu.. team 1200 calls member runction of TDisplayDevi.^~^n~ll. 1202to request a le ~
2) This request is sent to the Display Device IO Access Manager 1212.
3) The Display Device Flcllllewul~ 1206 intercepts the request. R~.^.^.~ni7in~ it as a.. ~i~.. ,.li.. updaterequest,theframeworksendsarequesttothewindow handled by the Window Server 1204 (via a private Window Client 1208) to stop all drawing 4) When all drawing has been stopped, the Display Device rl.l...ewu.~ 1206 ~licpAt.^h.c the request, causing the subclass 1210 to perform the !~---"~;~".,.li.^n.
5) When the subclass completes the lè~ullri~;ul.lliul~, the Display Device Framework 1206 tells the window to resume drawing. The window will force the affe~^ted screen area to be redrawn by sending update notification to the windows on the display. The window also changes a graf devhe seed~ which is used by the document window manager to notice that a new graf device must be obtained.
TDesktopDisplay, described in the next section. can be used ir an application is interested in knowing exactly how the monitor .. ~ i - . has changed.
30 Access To Desktop Geometry Many applications will need access to the geometry of the desktop - a TGArea for the desktop as a whole and a TGArea for each screên that makes up the desktop.
A few examples of which Clients may use such a feature is as rollows:
The document framework needs to allow a zoomed wrndow to take up an 35 entire screen. To do this, it needs to know the size of the screen.
Documents will need to force a window that was pre~iously displayed on a much larger desktop (say, on a 21" monitor) to be visible on a smaller screen (such as a 9" monitor).

CA 022026l4 l997-04-l4 wo 96/13026 PCI~/USg5/10632 The cursor code needs to know the desktop geometry so it can pm the cursor to the screen.
Figure 13 is a Booch diagram showing the classes used for accessing the desktop geometry. TDesktopDisplay 1300 is an object which l~lU~ L~ the entire - 5 desktop, and has notifirAtir,n of bit depth changes and monitor position changes.
TDesktopDisplay 1300 ~ g~ L~ all of the displays that make up the desktop. It has - a TGrafCluster 1302, which is the rendering object for all displays. TGrafCluster 1302 is a collection of all of the rendering objects that make up the desktop. TGrafCl~ster has a member function for iterating through all .. ~ r l graf devices as well as a member function to get the desktop geometry as an area. A Client can ask a desktop display for its graf cluster. TGrafDevice 1304 is a rendering object. TGrafDevice 1306 l~~ 7ulJ~Ia~es for each mdividual display. These subclasses also mix m MScreenDevice, which is discussed further below.
Figure 14 is a Booch diagram depicting how each ~UIII~Ullc~ graf device is 1~1~) . CP. ,1 ".1 by a subclass of TGrafDevice and MScreenDevice. MScreenDevice 1404 adds compositing, sprite, and multitask syn~ ulli~,aLiull functions to TGrafDevice.
TDisplayD~vi.~IIal.dle 1406 makes queries upon the actual display device. Display Subclass object 1402 comprise bubLI~ that represent the display. TGrafDevice 1400 has been described above. The geometry of the di3play can be obtained by first asking the MScreenDevice 1404 for it's display device handle. TDesktopDi3play can al30 send notification when certam rnnr~ihnnc occur. For example, when the geometry has changed, or when the user has reFositioned the monitor the TDesktopDisplaycansend ~ ir;."~
~ Hardware Windows The preferred embodiment supports hardware windows by usmg polymorphic screen device objects to allocate, move and resize windows. Whether the window is drawn by software or hardware does not matter to the Wmdow Server.
The window can Arrnmmn~1At~ display devices that imr1r-mPnt wmdow flmrhnnAlity in hardware. Hardware is often used to accelerate window . ~ .g when moving windows, visible area rAIrlllAhnnc for wmdows, and update area rAlrlllAhnns for windows.
35 Internal Windows Figure 15 is a block diagram showing the windows of a Client Team 1500, and the windows of the Window Server 1502. The Window Server uses the class TlnternalWindow 1506 to internally represent a piece of screen real-estate in the Window Server 1502. Whenever a (31ient Team 1500, such as the document windo~

CA 022026l4 1997-04-14 wo 96/13026 PCTlUSgS110632 manager, creates a TSysternWindow 1504, a TlnternalWindow 1506 is created insidethe window.
Figure 16 is a Booch diagram ~ " ,. ,. .~l, ,. I; "~ TlnternalWmdow being subclassed in order to i~ )lc~ hardware windows. TInternalWindow 1600 is an S abstract base class for mternal windows. TXYZInternalWindow 1602 represents a hardware window subclass. In Figure 16,1602 It~ b~ b a hardware window subclass from a lly~ù~lleli~al XYZ Cul~ulaliv l. TFlatFram~, .rr.-.T..~ window 1604 l~JleSb~ a window which is suitable for flat framebuffers.
TlnternalWindow 1602 has the following l~ullbil,ilities: ~
1) I~lAintAinin~ the extent (position and size), expressed as a TGArea, ûf the windûw.
2) Moving the window when its position changes. For software windows, this means doing a copybits of the visible window contents. For hardware wmdows that employ hardware scrolling, this means writing some registers to move the 15 window.
3) Returningthefollowing illr...l.. I;..~ aboutthewmdow:
- Can it calculate it's own visible area? Software windows normally do not, the window does it for them. Some hardware windows can (They can do this because the hardware windows are constramed to be on top of all software windows). If the window can calculate its own visible area, then the window doesn't have to.
- Can it calculate it's own damaged area? Again, the Window Server does this normally unless the wmdow can do it itself.
4) Having setters and getters for the visible and update areas. Hardware windows need to keep these areas current if the hardware is ( AI~Illatin~ them.
5) Whenever a window changes position, the Wmdow Server hands the wmdow a list of it's internal windows in front-to-back order. Hardware windows can use this infnrmAtinn to determine visible and update areas.
6) Private huubek~ Ig for the wmdow, meanmg that subclassers don't have to worry about many details.
When writing hardware window device drivers, TlnternalWindow must be bub~labbed while mAintAinin~ the above responsibilities. If a device doesn't support hardware windows and looks like a flat frame buffer, then TlnternalWindow and TSystemWindow do not have to be c~ lh~lAccf~d The stock classes will behave lustfine.
Figure 17 is a Booch diagram showimg addition of new member functions to a system window subclass by the subclassmg of TSystem Wmdow 1700 and TlnternalWindow 1704. As shown, TSystemWindow 1700 can also be sub~labb~d, as illustrated by TXYZSystemWlndow 1706, if extra member functions need to be added to it. Generally, if TSystemWindow 1700 is subclassed, then CA 022026l4 l997-04-l4 wo 96/13026 PCT/rrS95/1~632 TInternalWindow 1704 must be subclassed also in order to add private handler member functions that actually do the work. The bul~ld~billg of TInternalWrndow is shown by lXY7:Tntl~rnAIWrndow 1708.

Display Devices - Figure 18 is a block diagram which shows that for each display device thatmakes up the desktop, there is a TDisplayDevice 1802 that lives rn the Window Serverl800. Thedisplaydevice~.. ;.,.lrcwiththedisplay'sIOAccess 10 Manager 1804 as necessary. TDisplayDevice 1802 resides rn the Window Server 1800. Display devices are l~*,o..ail,le for creatrng internal windows as well as . . .~l i.~l~; . .;. .~ device-specific ;. .r~ l that may be need to be referenced ky internal windows.
Creating Internal Windows Figure 19 is a block diagram illustrating how internal windows are created.
1) Client team 1900 ;Il~ lrr, a TSystemWindow 1902.
2) TSystemWrndow 1902 packages window ~ l r~ ~ into a TInternalWindowDescripfion 1504 and sends it to the diblJdl~ll~ 1908 of Window Server 1906. TlnternalWindowD~ liol~ 1904 has all the FArAm~tf~rg necessary to create a window (those described in Creating and Deleting Systern Windows, above), rncluding the window's size amd position (described as a TGArea). It can be subclassed to add new ~l dl I æ~ if TSystemWindow 1902 and TlnternalWindow 1912 are ~ulJ~la~ed and require A ~1A itinllAI ~JI LSLI U~liVI I ~ . I . Irl rl ~.
3) The winaow figures out which display device the window is on . It asks the display device to create a TInternalWindow 1912 via TDisplayDevice 1910. (The case where the wmdow spans multiple monitors is described in the next section, Spanning Moni~ors).
4) The display device creates either a TlnternalWindow 1912 (if it is a flat framebuffer) or a subclass (if it supports hardware windows or other A~lditinnAI
fllnrtinnAlity).
Spanning Morlitors Figure 20 illustrates by block diagram a window which spans three different monitors. In the example, monitor A 2000 is a simple frame buffer. Monitor B 2004 supports hardware windows. And monitor C 2006 supports a different kind of hardware window than monitor B 2004. The window 2002 is spannmg the three monitors.

CA 022026l4 l997-04-l4 Figure 21 illustrates the system used to enable the wmdow to span the three monitors. FigL~re 22 is a Booch diagram i1lllctrAtin~ the objects necessary to support the spanning of monitors. The window handles this by creating a subclass of TIriternalWmdow, TInternalWindowCluster (2202). TlnternalWindowCluster 2202 is an internal window that "has" three other internal wmdows (2102, 2104, 2106). The three component internal windows are created by the display device, as described in the preceding section.
When the window cluster 2100 is told to move, it turns around and tells it's ~UllL~Ul~ mternal windows to move and change their sizes as a~ lv~l;aLL- The same is true for all other window requests to the cluster, the cluster does someilllL-l~lL~Làlivll and passes them on the LUlll~Ul~L'lIL~.
The imrlPmPntnr has the choice of when to create internal window clusters.
One could try to optimize by creating clusters only when necessary (e.g. when a window spans dissimilar monitors), or choose a simpler solution where a cluster is created for every wmdow, even if the window is contained withm a single monitor.A simpler alternative to the above solution may also be considered: Whenever a window spans more than one monitor, it reverts to a stock software window. It can do this by calling inherited member functions of TlnternalWindow. This solution is simpler, but has the disadvantage that a display device does not know of 20 allwindowsonitsscreen. Thisir.,~ canbeusefulinA~fPlpratin~visibleand update region cA1rlllAtinnc An easy way for TXYZInternalWindow to revert to a stock TrlaLFi all.eBurrL-lWindow would be to inherit frnm TrlaLFIall,e~L Lrr~l~VIndow and call inherited member functions whenever it n~ds to revert.
Some hardware devices can only support a frxed number of hardware windows. In this case, it is the lL-~ul-~ibility of the TlnternalWindow subclass to revert to a stock software window when the number of hardware wmdows is exceeded.
It is ~ulLLL~ lalL~d that some TlnternalWindow subclasses will need to ...... ,.. llli.~llL-withtheircorrespondingTDisplayDevicetofigureoutwhenthe mAYiml~m number of hardware windows is exceeded. The TDisplayDevice subclass would maintain the coumt of existing hardware windows. TInternalWmdow would query the display de~ice to get this i .) ~. ., .,, ~ l i. ,, It is possible for a Client, when creating a system window, to request a 35 hardware window. This is done by directly i l ~ a Tsystemwindow subclass irlstead of TSystemWindow.
This is useful for applications that know they only work on a specific hardware device, such as applications that use the IBM Ac~ nMP~iiA II Playback wo 96/13026 ~ 2:/a/l~o~
-2~-card. This card is capable of de-u~ D2il-g digital video amd displaying it on an on-board frame buffer, but nowhere else.
There are times when a view may want to know what type of display device (or devices) it is bemg displayed on. This would allow TView subclassers to makeS use of some fancy features provided by hardware. TSystemWindow has a member fimction which returns an iterator that allows the Client to iterator over all - TDisplayD~:vi.. -TT,.. ,~lI.oC thatthewindowis~oD;tiul.~don. ViewS~la22~1Dcmuse this;.. ~.. ,;lli.. ~todeterminewhatdevicetheirviewisonandacta~ ul~iu.E;ly.
While the rnvention is described in terms of preferred embodiments rn a 10 specific system ~IIVilUlull~llt, those skilled m the art will recognize that the invention can be practiced, with m~.1ifi~ ~firm, in other and different hardware and software ~vi~ulUll~rllD within the spirit and scope of the appended claims.
-

Claims (23)

-26-Having thus described our invention, what we claim as new, and desire to secure by Letters Patent is:

1. An apparatus for allocating and managing a plurality of window displays for use on a computer system having a memory (306) with a system address space (608) and a program address space (600) in which a plurality of application programs (610) run, a display device (322), a plurality of client application programs (610), each of which generates graphic information for display in a parent window display, a device for receiving user window manipulation requests (320) and a system window server (606, 1502) in the system address space (608) which maintains stored data (604) that defines a location and size of a visible area for each of the plurality of parent window displays and which determines the stored data based on the position and size of the plurality of parent window displays, CHARACTERIZED IN THAT
a document window manager (1500) in the program address space communicates with the system window server (510, 606, 1502) to obtain the visible area data, receives the graphic information generated by the application programs (610) and directly controls the display device (322) to display the graphic information in the visible area.

2. Apparatus as recited in claim 1 wherein the document window manager (1500) comprises an update manager (1504) which responds to a user window manipulation request to change the location and size of a parent window display by determining new position and size of the parent window display and notifying the system window server of the new position and size.

3. Apparatus as recited in claim 2 wherein the system window server (510) comprises a visible area manager (506) which responds to a notification (504) from the update manager (1504) by recomputing the visible area data based on the new position and size.

4. Apparatus as recited in claim I wherein each of the plurality of application programs (610) runs in a corresponding program address space, has a main parent window display and has a document window manager (1500) in the corresponding program address space, which document window manager (1500) directly controls the display of graphic information within the visible area of the main parent window.

5. Apparatus as recited in claim 4 further comprising a plurality of child window displays in the main parent window display and wherein the document window manager (1500) in the corresponding address space maintains stored child window data that defines a location and size of a visible area for each of the plurality of child window displays, and responds to a user window manipulation request to change the location and size of the visible area by changing the stored child window data.

6. Apparatus as recited in claim 5 wherein the computer system includes a screen buffer (412) and a mechanism (416) for rendering the contents of the screen buffer on the display device and wherein the document window manager (1500) further comprises a drawing mechanism in the corresponding program address space for writing graphicinformation into the screen buffer (412) into each of the child window visible areas.

7. Apparatus as recited in claim 1 further comprising a drawing semaphore which is used by the document window manager (1502) to control the display of graphic information within the visible area.

8. Apparatus as recited in claim 7 wherein the system window server (510 606 1502) comprises a mechanism for eliminating the drawing semaphore to determine whethergraphic information is being displayed in any of the plurality of parent window displays and for preventing any change to the stored main window visible area data when graphic information is being displayed.

9. Apparatus as recited in claim 1 wherein the document window manager (500) includes a cache memory in the program address space which stored a copy of the data that defines a location and size of a visible area for an associated window display.

10. Apparatus as recited in claim 9 wherein the cache memory includes a location time stamp which indicates when the copy of the visible area data was stored in the cache memory.

11. Apparatus as recited in claim 10 wherein the system window server (510, 606, 1502) includes a mechanism for storing a system time stamp in the system address spacewhich indicates when the visible area data was stored in the system address space.

12. Apparatus as recited in claim 11 wherein the document window manager (1500)includes a mechanism for comparing the local time stamp to the system time stamp to determine whether the visible area data stored in the cache memory is a copy of the visible area data stored in the system address space.

13. A method for allocating and managing a plurality of window displays for use on a computer system having a memory (306) with a system address space (608) and a program address space (600) in which a plurality of application programs (610) run a display device (322), a plurality of client application programs (610) each of which generates graphic information for display in a parent window display a device for receiving user window manipulation requests (320) and a system window server (606) 1502) in the system address space (608) which maintains stored data (604) that defines a location and size of a visible area for each of the plurality of parent window displays and which determines the stored data based on the position and size of the plurality of parent window displays.

CHARACTERIZED BY THE STEP OF:

(a) . constructing a document window manager (1500) in the program address space which communicates with the system window server (510,606,1502) to obtain the visible area data, receives the graphic information generated by the application programs (610) and directly controls the display device (322) to display the graphic information within the visible area.

14. A method as recited in claim 13 wherein step (a) comprises the step of:
(a1) constructing an update manager (1504) which responds to a user window manipulation request to change the location and size of a parent window display by determining a new position and size of the parent window display and notifying the system window server of the new position and size.

15. A method as recited in claim 13 wherein each of the plurality of application programs runs in a corresponding program address space and has a main parent window display and step (a) comprises the step of:
(a2) corresponding a document window manager (1500) in the corresponding programaddress space, which document window manager manages the generation of graphic information within the visible area of the main (1500) parent window.

16. A method as recited in claim 15 further comprising a plurality of child window displays in the main parent window display and wherein step (a) comprises the step of:
(a3) maintaining stored child window data that defines a location and size of a visible area for each of the plurality of child window displays; and (a4) responding to a user window manipulation request to change the location and size of the visible area by changing the stored child window data.

17. A method as recited in claim 16 wherein the computer system includes a screen buffer (412) and a mechanism (416) for rendering the contents of the screen buffer on the display device and wherein the method further comprises the step of:
(b) creating a drawing mechanism in the corresponding program address space for writing graphic information into the screen buffer (412) into each of the child window visible areas.

18. A method as recited in claim 13 further comprising the step of:
(c) using a drawing semaphore in the document window manager (1500) to control the generation of graphic information within the visible area.

19. A method as recited in claim 18 further comprising the step of:
(d) causing the system window server (510, 606, 1502) to examine the drawing semaphore to determine whether graphic information is being generated in any of the plurality of parent window displays and prevent any change to the stored main window visible area data when graphic information is being generated.

20. A method as recited in claim 13 further including the step of:
(e) storing a copy of the data that defines a location and size of a visible area for an associated window display in a cache memory in the program address space.

21. A method as recited in claim 20 wherein step (e) includes the step of:
(e1) using a local time stamp to indicate when the copy of the visible area data was stored in the cache memory.

22. A method as recited in claim 21 further including the step of:
(f) storing a system time stamp in the system address space which indicates when the visible area data was stored in the system address space.

23. A method as recited in claim 21 further including the step of:
(g) comparing the local time stamp to the system time stamp to determine whether the visible area data stored in the cache memory is a copy of the visible area data stored in the system address space.