Virtual WindowSystems: A New Approachto SuppoitingConcurrent HeterogeneousWindowing Systems RitaPascale, Jeremy Epstein - TRW SystemsDivision ABSTRACT A "virtual window systeml' (VIWS)is a simple model of a window systemwhich can be used to host other more sophisticatedwindow systems. The VWS allows the window systemsto sharethe.phys_ical 9ppl.y in a controlledfashion. A VWS is analogousto the virtual machinemonitor (vMM) [MadnickT4]concept in operatingsystems, where a single ghysical compr¡ter-canrun multiple operatingsystems, each in itõ o-*n protectiondomain. Unlike the VMM concept, the window iysiems supportedby the VWS need close cooperationto perform'tasks,such as cut and pastebetween wináows of differentwindow systems. -- . This paperdescribes the VWS concept,discusses an architecturefor a VWS, describes limitations of the \l[VS concept, discusies some lessonslearned from the design and implementationof our prototype,and describesthe use of WVSs for various application domains.

Introduction MacOS and X; X-under-NeXTstepfrom pencom which Userswant to run more than one window svs_ combinesNeXT and X; and Domain from combinesApollols native tem (WS) simultaneouslyon a single platiãi.. ínr f¡to,llo_which WS and X. somesystems which combine usersare a very diverseset whose-neeãsrange from 1Ti:-*. threewin- debuggingto together(i.e., X11/l.IeWSand téachingto running a variety oiuppn *Y,tlq "."lironments catiolL ihe systeni developerneeds an r¡f;ãii* but three seemsto be.the maximum. By beingfu.nvi3¡v), debuggingtool ior window syrte*s an¿ tfreir áppfi- limited to two or three environments,-many of of the vWS are possible. cationl. lhe instructor needéa flexible .yrì"iñ'ìà llt^ :jli,.ges .not The thesesystems fulfill js the teachin as many environmenrsas possiUié-;-;;; 1l_tjln"rigl ability to run machine.The everyday userneeds'to *" .ppfU: mixed applicationsand this hasbeen argued as not tions built for more than one window system,ä'tr.h- being a great advantage. niquewhich we call applications". "mixed Goals We proposea generalsolution to allow many as many of the variousneeds of the windowing eìvironnientsto run cooperativetyf-iä ,,-.^_^t^o.meet refer to iias the "virtual window system,'iVWSj group' we need a small, but flexible :1-1t::-.usersystem conceprt. A wVS is a simple model of . ìinàoí base. To avoid the temptationof buildÍngÏÎ1?: an entire systemwhich canbe usedto hostott *orr-.ootrjr- new windowsystem' the sizeis to "t and minimal,using as few primitives titated window systems.Tltr ñ;t;ñtt..r.d'W'ú :: fj:,:tttl Deslte this minimality, we wish to are considered"'guests" on the vws prærotit'åiã 1l_l,o_ttlblt'. may be referredîo as gue.t WS. The Vws'.ir"*. flexible.The set of primitivesmust provide i:T1iT functionality disparateWSs to shareúe physicaldisplay i" ;;;;: to accommodateany window system':::.T* trolled fashion and provideì ã mecnanismfor com- municationacross Vy'Ss. The primitivesbetween the guestWSs and the c.al be into connection When comparedto similar systems,the VWS is YYI-.^tyt"m .grouped much more veisatile. Hybrid ws ånuironrJni, startupinformation, input data, and output ilglt:lll '$ority combinetwo parricularsystäms and provide,ltr'.uii: of the primitives deal with chang- Í-1t:Jn: such as requests ity ro run apitications fiom the t*ó ;Ñifiä wö, lo map and unmãp 11åjÏ.^ditptav,update onty. nxampiesof thesehybrid systemi utr ñiriãn windows, and changethe window T1i1-?:t'stacking order. trom Visior¡Vare which óombinósf"ficro.ofi'.äi-n_ ',' Overall, there are fewer than 20 primitiveswhich.is dowsand X; MacX from Macintoshwhich co, '-' -significantlyless than the 120

@bytheDefense^--".irotocolrequestsi"tr'"î''*'i[Scheifler90]. ResearchProjects Agency under Contract No. MDA 972- 89-C0029.

'92 - Summer USENIX June8-Junþ LZ, Lggz - SanAntonio. TX LL7 Virtual l{indow Systems Pascale,Epstein

Detalls of the Problem all supportedWSs, and this is the most common form of datatransfer. There are a number of problemsinvolved in hostingmany environmentsand protocols on a single Method platform.The main areasto addressare randomdev- ice accessesand overcomingdifferent protocols. Our solution provides a mechanismto control device accessand regulate inter-environment(and Access to the keyboard,mouse, console and intra-environment)communication. The VWS per- framebuffermust be regulated. Allowing each WS forms theseactions through three logical servers:an all input at all times would result in massconfusion input manager,an ouÞut manager,and a control since eachWS interpretsdata differently. A mouse server.The input managerroutes the input click in one environmentmay pop up a menu,while to a sin- gle designatedwindow system.The output manager in anotherit may causean applicationto exit, and in displayseach window system'soutput the yet another,the data format may not evenbe valid. on screen while handling window overlapping Unlimited access to the screen will allow guest and clipping. The control serveris inactive,except for administra- WSs2 to cause chaos by drawing on top of one tive duties.Figure 1 showsthe interactions another's windows, creating a confusing mesh between of the VWS guest partial windows. and the WSs. Each guestWS must be modified to virtualize Another difficulty is cut and pasteacross WSs. its device access. Input is receivedfrom the input Each systemsupports a differentmechanism through managerinstead of readingthe devices different protocols. A primitive method must be directly and drawing is performedin a virtual developedthat can cut across these various plat- framebufferand then sent to the output managerfor display. forms. One drawbackof being genericis that unique These modificationsare necessarysince there data formats are not supported. For example,h X is no direct accessto the hardwaredevices. The guest must resource ids (instead of the actual WS [Scheifler90], also requestservices of the threeVWS serversusing data) can be cut and pasted;this id is only useful minimal primitives. A possibledrawback to the vi¡- within that particular instantiationof the X server tualizedouÞut is that there is no advantageof using and is not meaningfulto any other WS process.At intelligentgraphics boa¡ds unless they the very least,ASCII text can be transferredbetween can utilize the virtual framebuffers. In the WVS environment,there is always one 2By guestwindow system,we mean a window system active WS which receivesall input from the input environmentthat is supportedand hostedby the vi¡tual manager. Any other running system is passive, window system. meaningit can sendupdates to the screen,but does

oaaaa

Figure 1: VWS Interactions

118 Summer '92 USENIX - June 8-June 12,lgg2- San Antonio, TX Pascale,Epstein VÍrtual Window Systems

not receiveany input. Interpretationof the input is pasted.At a minimum,guest WSs must supporta the responsibility of the active window system, canonicaltext format for interoperability.Additional meaningit is up to the guest\VS to sendthe input formats-maybe supported,but their interoperability eventsto the appropriateclients and processthem as is less.likely. This may be a disadvantagèto sys- dictated by its own internal protocol. The input tems that have unique data forms, such as resource manager'sonly interactionwith the input is scanning ids in X. for the attentionsequence which activátesthe control The primitives sent from the guest \VS to the server. The control server is activatedstrictlv on control server are connectionrequests, cut data certainkeyboard input, not clicking on an icon.'This and paste requests.The control server respondsto the is becausemouse position (at thelime of the click) pasterequests with the most recentcut is up to interpretationper guestWS. data that meetsthe criteria specifiedby the guestWS. The only primitives f¡om the guest WS to the With minimal changes,existing WSs can input managerare connectionrequeits and requests be modifiedto work within the VIVS environment.How to ring the bellr. lnput managerprimitives to the closelythe window system'simplementation is tied guest\ryS provide keyboard and mouseinput, initial- to the hardwaredictates the amountof chanee. ization data, and notification of X is selection and very modular and encapsulates deselectionby the user. its device-usage; therefore, it was quite simple to change. We The output server controls the mapping and modifiedthe MIT X11R4 serverfor Sun ha¡ãwarerc rffSs unmappingof windows from the various as acceptinput from the input serverand displayoutput well as handlingstacking order, screenupdates and throughthe outputmanager with a few hundiedlines cursor_imaging. Becauseno sophisticatedgraphics of code. Modifying the Macintosh WS would be operationsare provided,the outputmanager is much much more complicatedbecause of its closerelation- simpler than the output componentof ãn ordinary ship with its hardware,but we believethat even this windowsystem. Performance is the costof this sim- can be overcome. plicity, but having such base primitives makes the ouÞut .managermore adoptive of other WSs. A Details on Vl{S Uses disadvantageof this schemeis that the screenback- The VWS exhibitsgreat versatility in its ability ground is not for use by any guestwindow system. to handle a wide variety of needs in a minimãl A mechanismis provided to draw helping lines for 'and amountof code. WVS neither enhancesnor detracts placing, moving resizing windows, but other from the given graphicaluser interface;if the guest applicationsthat draw directly on the screen back- WS is poor, it will remain that way. ground,such as vine and xroach Below we in the X Window further explainrhe usesof the VWS. Systemare simply not supported.These applications are generally decorative and were considered DebuggingTool expendable. The VWS can be appliedto paradigmssuch as The following primitives are supported - from debuggingWSs and applications.New versionsof the guestWS to the outputserver: the same window system can be tested under o connectionrequest the VìVS environment.For example,X11R4 can be run ¡ window map and unmaprequests at the sametime as X11R5 and differencesin capa- o cursorposition change bilities of both can be monitoredsimultaneously. o cursorimage change In the samelight, the sameWS can be run while o window update test- ing different versions of client applications. For o raiseand lower window requests example,one could start three X11R4 servers,and o draw dashedbox request(for placing, moving test a different window manageron each. and resizingwindows) We a¡e able to run the OSFMotif mwm, OpEN o load a colormap LOOK olwm, and MIT twm window managerssimultane- The output serverprimitives to the guestsWSs ously; each is connectedto a different instanceof provide initialization data and window- map ack- the X server. nowledgements;other requests do not requireieplies. Another advantageof the VWS testingenvi¡on- The control server starts new WSs. switches ment is that resource grabs are limited to the betweenWSs, and providescut and paste'operations environmentthat they were initiated in. rWSs. -only In X, a between Cut and pasteis the inieraction client can "grab" exclusive accessto any and all between windowing environments. Íne control devices,including the serveritself. In the VIVS sys- server providesno interpretationof the data to be tem, these grabs are limited to the instantiationof the server that requestedthe lock. This allows the ffi outputfunction, but on our developeran easierway out of a potentialdeadlock Sunsystem the bçll is partof theleyboard, so we put this situation. functionin theinput manager.

'92 - Summer USENIX June8-June 12,lgg2 - SanAntonio, TX 119 Virtual l{indow Systems Pascale,Epstein

The VWS is an effectiveway to test graphical based on Mach 2.5. A secure environment is user interfaces;however, performance benchmarking achievedby running multiple instantiationsof the X results have no meaningin this environmentsince ItrS and the MGR WS; one at eachsecurity level to all processesare ultimately sharing the same CPU be displayedon the screen(e.g., one seryercontrols and job scheduler. The main testing advantageis all secretwindows on the screen,a different server varying visual resultsdue to different configurations handlestop secretwindows). The VWS keepsthe and avoidanceof detrimentalserver hangs. workspaces separate and allows cut and paste accordingto the security policy implemented.This TeachingTool architecturegives us a high degee of trust without Becauseof its ability to run va¡ious envi¡on- relying on the correct functioning of a large and mentsand configurations,the VWS can be usedas a complexwindow systemsuch as X. teaching tool for all of those environmentsrather Anotheradvantage of this highly flexible secure than requiring one machinefor each platform. For VIWSbase is that the guestWS is entirelyuntrusted. comparisons,the VWS can display X11R4 and This meansthat any window systemthat can be run X11R5 seryers and thei¡ various applications. on the VWS can be used in a secureenvironment Differences are manifestedin a more memorable without having to go through the extensiveprocess way when they are capturedon a singledisplay. The of accreditation. samegoes for varyingwindow managers. Multi-Processor Currently,only three window systemsare run- Environments ning on our prototype VWS. They are X11R4, Becausethe VWS consistsof severalcooperat- X11R5 and Bellcore'sMGRr With the additionof ing processes(input managçr,output manager,con- Macintoshwindows, Microsoft Windowsand Presen- trol server,and guestWSs), it is able to use multiple tation Manager,this systemwould be a very useful processorswithout additionalinvestment. For exam- and inexpensiveteaching system. Rather than buying ple, the X servercould run on one processorwhile three or four machines,one platform would suffice the MGR serverruns on a differentprocessor. for all requirements. Results Mixed Applications The design and implementationof the VWS In today'scomputing environment there are a took two man years. Modification of the X11R4 half-dozencompeting "standard" window systems; server required less than four months for a junior X, Macintosh, Microsoft Windows, Presentation programmerto incorporatethe necessarychanges. Manager, and SunView chief among them. \/lVS Upon the release of X11R5, modifications were allows usersto run applicationsbuilt for more than adaptedin less than a week, We adoptedBellcore's one window systemsimultañeously. \ile can run edi- MGR window systemto the VIWS with less than a treson X11R5,Motif on X11R4,and spot(a pointer month. Using ports and multi-threading,fundamen- trackingprogram) on MGR. Theseprograms do not tal aspectsof Mach-likeoperating systems, attributed run as well (if at all) on the other systemsmen- to the bulk of the modifiedcode. Much of the low tioned.X11R4 did not haveeditres at the time of its level communicationcode in the X S/S had to be release;X11R5 does not supportMotif unlessit was rewrittento use ports;using an operatingsystem that compiledwith the backwardcompatibility flag; spot supportedsockets would have savedimplementation is an MGR specificapplication which doesnot exist time. for X11R4or X11R5. Runtime improvementscan be made by using Again, once other WSs are integrated,the sys- faster hardwareand implementingthe VWS in an tem will becomemuch more useful.For example, environmentthat supportedsockets (rather than ports with Macintoshand SunView integrated,a softwæe as in TMach) and sharedmemory. Otherbenefits to developercould use a documentprocessing program usingsockets over ports is that socketscan be priori- developedfor a Macintoshwhile using development tized. Without this ability, previously simple tools designedfor the X Window Systemand Sun- processeshad to become multi-threadedto force View system. prioritization on port messageretrieval. For exam- ple, our X serverhas one threadper client in addi- SecurelVindow Systems tion to severalcontrol threads. While multi-threading Our specificimplementation of the VWS is for has its benefitsin allowing many activities to occur a highly-secure multi-level window system at once, there is a performancecost in context [Epstein9l]. It was developedon a Sun 3/60 run- switching, and a general overheadburden. Despite ning TMach, a prototype trusted operatingsystem our poor ha¡dwareconfiguration, the systemis not intolerable. With some enhancements,including aMGR those mentioned above, performance would be [Uhler88]is a freelyavailable window system. It greatlyimproved. is far lessflexible than K but it is fasterand smalle¡. t20 Summer'92 USENIX- June8-June L2,1992 - SanAntonio, TX Pascale,Epstein Virtual \{indow Systems

Running benchmarkson the VWS for com- Application Interface,'Bell Communications parisons with unchangedWSs has proven to be Research,1988. much more ',4 difficult than expected.Currently we [Epstein9l]Jeremy Epstein, et. al., prototype83 have some preliminary results from xllperf that Trusted X Window System", published in show the X11R4 server running under VWS yields P_roceedingsof the SeventhAnnual Computer 50 to 75 percentof the runtime speedscompared to SecurítyApplications Conference,San Anlonio the X11R4 serverrunning directly on the hãrdware. TX, December1991. Window manipulations(such as raises,lowers, circu- lates, maps, and unmaps) performed comparably Availabitity whereasgraphics operations did not performas well. A seriesof technicalpapers are availablefrom In the graphicsarea, the VIVS systemcompared best the authorson our VMS implementationto suppof on tests of direct copiesrather than stippledpat- a highly trustedversion of X. The sofrware ,terns5. Also, simplerìequests like lines iisèlf is ani tectan- not availableat this time. gles performedsignificantly better than more com- plex shapeslike circlesand ellipses. Author Information Our VWS implementationis less than 20,000 Rita Pascale is a Programmer on TRW's lines of heavily commentedC code (about 6,000 Advanced Computing Systems project building a statements).A significantfraction of that is due to trusted version of the X Window Systèm. securityrequirements. By contrast,an X11.R4server lighly Sheholds a B.S. in ComputerScience from Virginia andMotif windowmanager total about400,000 lines Tech. Her U.S, Mail addressis L FederalSvstems of code,including support libraries. Park Drive, Fairfax VA 22033. She can be rãached Our implementationcan be improvedwith fas- electronicallyat [email protected]. ter machines,hardware that can handlemanv frame- JeremyEpstein is the Lead Engineeron TRW's buffers,tuned operating systems as well as a number AdvancedComputing Systems project building. In of otherthings. Despite the addedoverhead, the per- his previous life, he was a lead engineer with formance is acceptablefor the typical user. The Addamaxdeveloping trusted UNIX systems. more intensive the load, -performance Jeremy the more the has been working with will downgrade. UNIX since Version 6, and still refusesto use "csh". He holdsa B.S, in Com- Conclusion puter Science from New Mexico Tech, M.S. in ComputerSciences from PurdueUniversity, and is The a¡chitectureand implementationof the working on a Ph.D. in InformationTechnology at VWS systemhas achievedour goalsof minimality GeorgeMason University. His U,S. Mail addrèssis andflexibility. As a proof of conceptexperiment, the 1 FederalSystems Park Drive, Fairfax VA 22033. notion of a VIVS has proven itself useful for build- He can be reached electronicallv at ing trustedwindow systems.We feel it is applicable [email protected] in other problem domains as well, and offers significant advantagesover alternate architectures. Thereare limitations to our implementation,but may be acceptable,given the payoffsof being able tô operatein a heterogeneousenvironment. Also, some of our limitationsâre specificto security. If shared data betweenWSs is allowed, as is the case in unsecuresystems, the memory usageand perfor- mancewould improveimmensely. Future work includes researchinto different hardware, different operating systems and more guestwindow systems. References [MadnickT4]Operating Systems, Stuart Madnick and JohnDonovan, McGraw Hill,1.974. [Scheifler90]X Window System, Second Edition, Robert Scheifler and James Gettys, Digital Press,1990. [Uhler88]Stephen Uhler, MGR C Language

SStippleO patternsa¡e as stencils to indicate where to d¡aw andwhere not to draw.

'92 Summer USENIX - June 8-June LZ,1rgg?- San Antonio, TX t2L