Search Images Maps Play YouTube News Gmail Drive More »
Sign in
Screen reader users: click this link for accessible mode. Accessible mode has the same essential features but works better with your reader.

Patents

  1. Advanced Patent Search
Publication numberCA1288873 C
Publication typeGrant
Application numberCA 534240
Publication date10 Sep 1991
Filing date9 Apr 1987
Priority date28 Apr 1986
Also published asUS4899136
Publication numberCA 1288873 C, CA 1288873C, CA 534240, CA-C-1288873, CA1288873 C, CA1288873C
InventorsGary R. Steinbach, James G. Sandman, Jr., Donald R. Woods, Marian H. Beard, Perry A. Caro, Kevin J. Mackey, Jennifer B. Hsiao
ApplicantGary R. Steinbach, James G. Sandman, Jr., Donald R. Woods, Marian H. Beard, Xerox Corporation, Perry A. Caro, Kevin J. Mackey, Jennifer B. Hsiao
Export CitationBiBTeX, EndNote, RefMan
External Links: CIPO, Espacenet
Concurrent display of data from two different display processors and userinterface therefor
CA 1288873 C
Abstract
ABSTRACT OF THE DISCLOSURE
A multiprocessor system comprises concurrent display of video data reflecting the operation of two processors in discrete portions of a single display screen with a user interface adapted for interaction with both processors. One processor controls the entire display while allocating a portion of the display screen for the use of the other processor which processor emulates a target processor system, for example, the IBM PC. To fully emulate another target processor system requires emulation of its screen facility and abstractions used in the display operations of the targeted system. The one processor is a general purpose host computer system having a central processor with real resources including I/O devices, main memory, a video display for displaying information on the display screen of the display and user input means, e.g. a keyboard and a mouse, to the host computer to provide input to the display screen. Also included in the system is at least one emulating computer having a processor emulating the target processor unit with interface means for emulating the previously identified real resources for the emulating processor including means in the host system responsive to the input/output of the emulating processor for sharing of the central processor real resources by the emulating processor.
A user interface is represented on the display screen in the form of metaphoric objects, called icons, with which the user can interact by changing the input focus to a designated object by visually pointed to it via the input means, which thereafter permits manipulation of the designated object or interaction with data input/output relative to the designated object. This input means is also used to initially change the input focus to either the allocated emulating processor screen portion or to the remaining portion of the central processor display screen prior to interaction with the metaphoric objects in a selected screen portion, the change of the input focus causing subsequent user input via the input means to be directed to the selected screen portion until interrupted by a change in focus input to the other of the screen portions by the user via the input means. An icon may be a representation of virtual object, such as a virtual floppy disk, that is accessible in either the host system world or in the emulating processor world even though the virtual floppy disk may have a filing system alien to the host system world. Facilities are also provided to permit transferring of displayed data reflecting the operation of one processor to the control of the other processor in response to user inputs selecting the data to be transferred and indicating the destination of the selected data on the display. More specifically, if data from each processor is displayed in a discrete portion of the display screen, the user may select data in one processor's controlled screen portion and transfer it to the other processor's controlled screen region, and vice versa.
Claims(23)
1. In a multiprocessor environment wherein at least two display processor means are capable of independently and concurrently operating to display data as separate images on a single display screen of a display, comprising a first display processor means for processing and displaying images on said display screen, main memory means for said first display processor means including memory allocated for storing information representative of said first display processor means images, memory controller means under the control of said first display processor means to store and update said information in said memory means, display memory means having a storage configuration comparable to the configuration of said display screen, display controller means under the control of said first display processor means to periodically scan said display memory and display the information therein onto said display screen, at least one other display processor means in said environment for processing information for display, said other display processing means having allocated memory in said main memory means of said first display processor means for storing information representative of the entire output from said other display processor means, window manager means in said first display processor means capable of creating and tracking window ports in said display memory, one of said window ports being designated for emulating the screen display of the output from said other display processor means, said display controller means causing the simultaneous display on said display screen of both the images of said first display processor means and of said other display processor means via said designated window port.
2. The multiprocessor environment of Claim 1 wherein said environment includes a user interface on said display screen including metaphoric objects with which a user can interact by using input means, said input means to also initially change the input focus for said input means to either said designated window port or to the remaining area of said display screen of said first display processor means prior to interaction with a metaphoric object present in a selected screen portion.
3. The multiprocessor environment of Claim 1 wherein said first display processor means can only read information from, but not write information to, said other display processor means allocated memory in said main memory.
4. The multiprocessor environment of Claim 1 which includes means for capturing information displayed in either a portion of said display screen dedicated to said first display processor means or displayed in said other processing system designated window port and transferring the captured information to the other thereof.
5. The multiprocessor environment of Claim 4 wherein said captured information may be copied to the other thereof.
6. The multiprocessor environment of Claim 4 wherein said captured information may be moved to the other thereof.
7. A system comprising:
first processor means for producing first image data defining images; the first processor means comprising a first processor for executing a first set of instructions to produce the first image data;
second processor means for producing second image data defining images; the second processor means comprising a second processor for executing a second set of instructions to produce the second image data;
display means for presenting images; the display means comprising a display screen on which images are presented;
the display means comprising combining means for operating on the first image data and the second image data to produce combined image data defining combined images that include a first image area and a second image area, the first image area of the combined images being defined by the first data and the second image area of the combined images being defined by the second image data; the display means comprising a display screen on which the combined images are presented;
user input means for receiving signals from a user, the signals including transfer request signals, each transfer request signal requesting transfer of data from a source that is one of the first and second processing means to a destination that is the other of the first and second processing means; and data transfer means for responding to the transfer request signals by providing the destination with control of data being transferred; the information transfer means comprising first form means for providing control of data being transferred in a form suitable for operations of the first processor if the destination is the first processing means; the information transfer means further comprising second form means for providing control of data being transferred in a form suitable for operations of the second processor if the destination is the second processing means.
8. The system of claim 7 in which the first image area is a bounded area and the second image area is a remaining area outside the bounded area.
9. The system of claim 8 in which the bounded area includes a window.
10. The system of claim 7, further comprising display memory means for storing the first image data and the second image data; the first processor being connected for providing the first image data to the display memory means for storage; the second processor being connected for providing the second image data to the display memory means for storage; the combining means being connected for accessing the first image data and the second image data in the display memory means.
11. The system of claim 7 in which the first processing means is a host system, the first set of instructions being host system instructions; the second processing means is an emulator for emulating a target system having a central processor for executing a set of target system instructions, the second set of instructions being the target system instructions, the host system instructions being different from the target system instructions.
12. The system of claim 11 in which the transfer request signals include a pause signal for requesting that operation of the second processor be paused; the data transfer means further comprising means for responding to the pause signal by pausing operation of the second processor.
13. The system of claim 11, further comprising a memory device with stored data that can be accessed either by the first processor or by the second processor: the transfer request signals including a first access signal for requesting that the first processor access the stored data and a second access signal for requesting that the second processor access the stored data; the first form means comprising first access means for responding to the first access signal by providing the first processor with access to the stored data; the second form means comprising second access means for responding to the second access signal by providing the second processor with access to the stored data.
14. The system of claim 13 in which the memory device is a floppy disk drive, the stored data being stored on a floppy disk that can be accessed either by the first processor or by the second processor.
15. The system of claim 13 in which the stored data is stored so that it can be accessed by the second processor as if it were stored in a memory medium different than the memory device.
16. The system of claim 15 in which the memory device is a fixed disk drive, the stored data being accessible by the second processor as if it were stored on a floppy disk and accessible through a floppy disk drive.
17. The system of claim 16 in which the combined image includes an icon representing the stored data and a symbol representing an emulated floppy disk drive; the first access signal including an open signal requesting that the icon be opened; the second access signal including a load signal requesting that the icon be loaded to the emulated floppy disk drive; the first access means comprising open means for responding to the open signal by presenting a window showing a directory of the stored data as part of the combined image; the second access means comprising load means for responding to the load signal by permitting the second processor to access the stored data as if it were stored on a floppy disk.
18. The system of claim 17 in which the first access signal further includes an eject signal requesting ejection of the stored data from the emulated floppy disk drive; the first access means comprising eject means for responding to the eject signal by permitting the user input means to receive the open signal.
19. The system of claim 15 in which the memory device is a fixed disk drive, the stored data being accessible by the second processor as if it were stored in a fixed disk drive different than the memory device.
20. The system of claim 13 in which the transfer request signals include a boot signal for requesting that the second processor be booted; the second form means further comprising means for responding to the boot signal by booting the second processor in a configuration that provides access to the stored data in the memory device.
21. The system of claim 7 in which the source is the first processing means, the destination is the second processing means, and the data being transferred indicates a sequence of characters in a text appearing in the first image area;
the second form means comprising converting means for converting the data being transferred into text data suitable for the second processor.
22. The system of claim 21 in which the converting means converts the data into keyboard scan codes suitable for the second processor.
23. The system of claim 7 in which the source is the first processing means, the destination is the second processing means, and the data being transferred indicates a bitmap appearing in the first image area: the second form means comprising bitmap copying means for copying the indicated bitmap into the second image area.
Description  (OCR text may contain errors)

CON~URRENT DI~PLAY OF DATA FROM TWO DIFFERENT
DISPI~Y PROI: E5SORS AND U~ER INTERFACE THEREFOR

Cro~ ReIerence to E~elated Application Th;~ applica~io~ i~ directly related to the ~ubject matter of Pate~t Application Serial No. 535,548, filed. April 27, 1987, assigned to the same assignee herein.

Background of the Illvelltion ve~tio~ relate~ to video display processor systems for di~play of video data or info~mation OIl a ~ingle display screen of a ra~er scan type video play and more p~ic~larly to ~ulta~eou~ly displayi~g video data reflec~llg th~ operatio~ of t~o proce~ors in discrete port;ion~ of a single display screen and the u~er i~terface therefor. Such a multiprocessor ~y~t~ may comprise a Iqrst display praces~or, e.g. a ho~t computer ~ystem, having a dsplay capabil;ty for ~multaneou~ly displaying both the video 20 data of the first proce~or and the video data of at least one other display proce~or, ~ich may, for e2ample, be the emulated display processor of ~M
target system central processor, e.g. the IBM PC, whic~ other display proces~or is co~ected to the host computer. The ho~t computer system allocate~ a portio~ of it~ display ~creen for emula~ion of the display screen 25 en~ironment of t~e emulated display processor.
~. .

' ` ' ' ' ' ' : ` ', , , ' .
'', ' ' ' ~.

3L;~ 8~7~

Since the early 1970's, the development and advancement of raster scan display systems for displaying video information on a video or CRT display has progressed at a fairly rapid pace. Egamples paramount in the adYa~cement of this area of a~t include, inter alia, the use of bitmaps which are memory representatio~s of the pattern of information to be presented on the display screen of the video display, the bitblt or raster op routine which is a fi~ndamental bitmap operation for the bit block transfer of a memory block of in~o~nation iil the display memory from one locatioll to another location in that memory, and the division of a bitmap display into several 10 regions, also referred to in the art by mally other terms such a~ viewports, files, ports, ~1vindows, pages or layered bil;maps, to provide separate display of video in~ormation in independent sereen regions. The processor systems controlling 9uch multi-region screens may include, for e~:ample, means (1) for t~e ma~ipulation of displayed data presented or preseIlt in the different 1~ region~ of the display screen, (2) for the relocation of either e~tire regions iucluding the displayed data therein to other por~ons of the display screen or beneath or on top of other display regions of the display screen and (3) for the relocation of displayed data in one screen region to another screen regio~. Examples of sllch system~ are the Xero2c ~010 Professional 20 Wor1~station or Information System first commercially introduced by Xerox Corporatio~ in April, 1981 and the Xerox 1100 SIP ~or the Xerox Smalltalk-~OTM System first commercially introduced in Nove:mber, 1983 and pre~iou~ly described with pictorial representations i~ Volume 6~) of BYTE of August, 1981, published by BYTE Publications, Inc., a subsidiary 25 of McGraw-Hi~ c. See also USP 4,414~62~ which discloses a raster display system for processing and displaying a plurality of superimposed pages on a single display screen. Further, USPs 4,533,910, 4,450,442 and .

- : ' .; , . ' 4,50~,775 respectively disclose ra~ter display system3 for (1) creatiag and displaying video information in dif~erent regions on a single display screen, (2) displaying a plurality of display files from separate processors in superimposed relationship alld i~ any desired combination thereof on a 5 single display screen and (3) di~playing several superimposed bitmap layers, each repre~eIltative, for e2cample, of a ~findow port, alld wherein all layers` are displayed, as ~uperimposed, and are run~ng si~mlltaneously so that ally one of the windo~ may be iD.teracted ~ith at any ~me.

10 Ill recent ~mes, with the i~troduc~io~ of the rnicroprocessor-based IBM PC
~ T~q a~d i~ more rece~t follow-ons, such a~9 the I:BM XT and t~e IBM AT (all collectively hereinafl;er referred to as the ~3M PC' produced by the I:BM
Corporation ~d ~th its high level of placement in the business community and general consumer market, there has been a ~umber of manufacturers 15 and developer~ developing ~ystem~ that have been either desig~ed to be an equivalent to an I~3M PC or de~igned to emulate an I13M PC via an emulati~g sof~rare environment. The wide accept~ce of the DBM :PC has also created a huge sof~are i~dustry ca$e~ing to the I:BM PC market, including emulatet or equivalent ver~ions in that marlcet, for various kinds 20 of application~, e~g. Lot~ 2-3TP'I, Word~tarTM, Mullimate~M, SymphonyTM, Frsmework ~M, Multiplanl'M, Turbo Pa~calT~, C Compiler (l~icrosof~
Pascal Co~piler (Micro~oftTM) a~d Cobol Compiler (Micro~of~TM), etc.
Manufacturers a~d de~elopers have fiou~d tlbat i~ order to mai~ their own perso~al computer based system viable ill the market place~ they m~st 25 also make some provi~io~ ~or runni~g D3M PC application and programs .. . . . . .

:~- ;' .

., . ~

~L~8~37~

since many customers or poteIltial customers already have IBM PC
equipmerlt in use in day to day business and work.

~ - For the most part, these competing manufacturers and developers have 5 provided in their syste~ separate hardware and/or softwa~e for emulating the IBM PC which may be booted and ru~ separately, while their own proprietary ~ystem is i~activated, to permit the run~ing of IBM PC
applications and program~ already in the ha~ds of I:BM PC users. 'VVhile users of 9uch competitive ~y3tems ca~ process data or ~ applicatio~s or 10 program~ applicable to either l;he proprietary system or to the IBM PC
emulated or equivale~t system provided in the same machine, there has been no offering of a means by which the proprietary system ca~ be ru~ning simultaneou~ly on the same display facility with the IBM PC emulated or equivalent system so that D3M PC applicatiolls and pro~i~g could be 15 carried out while the proprietary system is also concurrently ru~ g and to filrther pe~nit the t~ansfer ofdi~played video data and/or application and prograrn files from one such syste m to the other for ~urther use or proces~ing.

Su m m ary ofthe Inven~on Accordi~g to tbi3 invention, a m ultiprocessor system com p~ses concurrent display of~;~eo data reflesting ~he operation of ~o processors in discrete portions of a single display screen with a user interface adapted for interaction ~nth bo~h processors. O ne processor controls ~he entire display while alloca~ng a por~o~ of ~he display screen for ~he use of the other processor which processor ernulate~ a ~arget processor system,for exam ple, .. . .
:
: ' :

: -:
. . .;' . ,. ~

~L~88873 the IBM PC. To ully emulate another targeg processor system requires emulation of its screen facility and abstractions used in the display operations of the targeted system.
-6 More specifically, the multiprocessor system comprises a general purposehost computer having a central processor having real resource~ including VO devices, mairL memory, a video display wit~ a display bitmap memory for display information that i~ destined ~or display o~ the display screen of said display aIld user input mealls" e.g. a keyboard and a cursor control 10 device or mouse, to the host computer to provide user input to the display screen. A user interface o~ the display screen include~ metaphoric symbols with which the user can interact with by using the input means to selectively change l;he focus of the input means to a designated symbol visually poinbd to via the input means to thereafter pe~it manipulation 1~ of the designated ~ymbol or interac~ion with data input/oul~ut relative to the designated sy~nbol. As, previou~ly indicated, the ~y~tem also includes at least one emulating computer having a processor emulating a target proce~,sor ~ystem and further include~ interface mean~ for emulating the above identified real resources ~or the emulating processor which is 20 responsive to the i~put/output of the emulati llg processor for communicative sharing of the ce~tral processor real resources by the emulating processor. There are also ~aeans in the interface to direct user i~put via the input means as i~put for either the ce~tral processor or the emulating processor. The input means also initially changes the input 25 focus to either the allocated emulating processor screen portion or to the remaining portion of the ceIltral processor display screell prior to interaction with the metaphoric symbols in a selected screen portion. The ... .. . ... . . . . . ... . .
.` ' . , ' .
.:
- .
.
. ,~; . , , ~ , :
- . . ~

, . . . .
.
- . , .
.

~1 ;2t~3~3873 change of input focus caUSeS subseque~t user input via the input means to be directed to particular selected screen portion until interrupted by a cha~ge in focus i~put to the other unselected ssree~ po~ion, which is accomplished by the user via the input means.

Facilities aI'8 also provided to permit transferring of displayed data refleeting the operation of one processor to the control of the otller processorin respon~e to user i~puts selecting the data to be trallsferred and indicating the destination of the selected data on the display. More 10 spec~fically, if da~a from each processor is displayed i~ a discrete portion of the display screen, the user may select data in one processor's controlled screen portion and l;ransfer it to the other prosessor's controlled screen regiont and vice versa.

1~ A more specific aspect relative to the foregoing is that the display e~viro~nent is desiglled to emulate the I13M PC display by providiIlg all of the information which would appear on the PC display in a portion of the host system display called the PC emulator window. The display screen of the host system represent~ an abstraction of the busi~ess office metaphor 20 and includeg software applicalio~lg, called ~TiewPoint" supported by basic workstation (BWS) software to support those applications. The office metaphor includes an office desktop as well as a representation of the emulating proce sor as the PC emulator, which is represented as a metaphoric icon or symbol on the host syst2m screen, which, when 25 "openedl', reveals a~ emulated PC window. The display screen of the host sy~tem also shows other objects beside the PC emulator window, and some of those objects are other icons for the PC emulator or for the host system .
.. , ~ .
' ' ' . : :

~' ,;~' " ' ` . , ' ~ .
,:

3l2~ 73 operation or for both. Other objects represented in iconic form are in and out baskets, waste baskets, documents, folders, messages, file drawer~, printers, etc. Further object~ are basic workstation (BWS) windows and property sheets associated with the operation of either processor alld for 5 each of the above mentioned objects. This ability to display both an emulated PC display scree~ and, in the remainder of the display screen, the co~ventiollal display scree~ of the host system is aIl impor~t feature of thi~ inveIltion. The host system processor loads the info~mation to be displayed into a bitmap memo~y from both display data read from the PC's 10 emulated maiIl memory allocated in the host system's main memory as well as display data read from the ho~t sy~tem's mai~ memoIy.

Another feature of this invention is that the configuration of the PC
emulator may be freely chosen, i.e., the configuration of the PC emulator 15 can be preselected prior to booting of the emulator. The co~figuration i5 arranged through a properl~ sheet associated with the emulator icon. For e~ample, the user may opeIl the emulator property sheet and select a COllfigllratiOl:l that includes a physical floppy disk drive, which is the actllal tloppy drive of the host system, one or more emulated floppy drives, and an 20 emulated fixed disk~ The emulated fixed disk a}ld emulated floppy drives~
as selected, are not physically prese~t, bu~ are present as allocated file space on the host system hard disk. The user may also select a memory size of 128, 25~, 384, 512 or 640 K Bytes, which appear~ a~ emulated main memory located in the host system mai~ memory. The emulator will 25 appear as an icon OIl the display screen, which wherl selec~ed aIld opened bythe user, having been previously configured, results in the booting of the PC

.

.
,: . .
, . , . : ~, , ~ ,-~ .

~2~ 373 emulator in the configuration previously established via the emulator property sheet.

A~other important aspect of this invention is that means is provided for caphlring information displayed in either portion of the display screen dedicated to th~ respective display processo~. Provision is made ~or the captured informatioIl to be copied and in ome cases moved to the display portion of the other.

Ihere are several techniques in which infor~nation may be transferred betwee~ the desigllated screen portions of the two display processor means.
The fi~t data transfer technique is a copy of selected text between the PC
emulated scree~ d a BWS window of the host system. To copy out of the emulated screen, the user selects a command in the PC emulator window header te~ned "Pause", causing the operational state of the PC emulator to be f~ozen" with the emulator di~play window now being under the co~trol of the host central processor. Also, the emulating processor is frozen suspending the running of a current PC progra~n. The user then selects the data in the emulator window to be copied, which data is highlighted by the host system to indicate selection. The user then initiates a copy operation to traIlsfer the selected data to a BWS vrindow as the destination, causing the host central processor to copy the selected data into the ~elected BW~3 window. To continu~ operation of the PC emulator, the user selects a comma~d in the PC emulator window header termed "Resume", causing the - 25 operational state of the PC emulated to be "thawed" with the emulator display window now being under the coIltrol of the emulating processor and the PC program resumes from e2actly the same point at which its operation , ' ' .' ~. . '' `- ' ' '' ': '.
: . -' ~

, ,~' . ' ~ .
.
.
. ~ , .

' ~L2~8~73 was suspended. To transfer data from a BWS window into the PC emulated screen, the user selects data in a BWS window at a time when the PC
emulator is not in a frozen state but rather its ru~ing or "thawed" state, and the selected data i9 highlighted. The user then initiates either a copy or 5 move operation to tl~ansfer the selected data to the P(: emulated window as the de~tin~tion, causing the host central processor to generate a series of emulated keystrokes equivalent ~o the keystrokes that would be necessary for input of the selected data and provide those keystrokes to the keyboard port of the PC emulating procgssor via the host s~stem. If the PC emulator 10 is ru~ing a program which will display input keystrokes, the data will appear i~ the PC emulated window, but in any eveIlt this input of keystrokes will be unter the control of the PC emulating processor.

The second data trallsfer technique is a trallsfer of a block of data 1~ corresponding to a virtual floppy disk from conl;rol of either processor to the other. The data itself i3 on the host system rigid disk, a~d does not actually move from one memory location to another, but control over the access to the emulated floppy disk icon and access to its rigid disk location is moved.
The block of data is called a virtual floppy, meaning that it i3 formatted to 20 appear to be a floppy disk to the PC emulator. At any given time, the virtual floppy disk i~ available to, at most, one of the processors" but never both. When represented as an icon on the BWS portion of the display screen, it may be elected and moved or copied onto one of the emulated floppy drive syrnbols as cor~lgured in the PC emulator window and shown 25 in the window header thereby placi~g it under the control of the P(:
emulator processor. When loaded in this manner on a~ emulated floppy drive of the PC emulator, the virtual floppy may be r emoved by "clicking"

. . ~

~88873 with the system mouse directly over the emulated floppy drive symbol, the mouse screen cursor at this point representing in miniature the virtual floppy disk, and using the mouse to relocate this special cursor on the desktop of the display screen. At the point of reloca~ion, the virtual floppy 5 disk icon will appear on the desktop of the display screen, and the data represented by the virtual floppy will be under the control of the host system processor.

The third data trans~er tech~ique is also a transfer of a block of data, either 10 on the host sys~m rigid disk or on a real floppy disk loaded in the host system physical floppy drive. Unlike the transfer of a virtual floppy disk, however, these ~ansfer~ of data require that the PC emulator be in a state from which it must subsequently be booted for further operation. If the floppy i~ in the drive, it~ contents may be transferred to PC emulator control 15 by booting the PC emulator configured to include the physical floppy drive.
Similarly, the conten~ of the emulated fixed disk, represen~ed by a block of reser~red space on the host system rigit disk, may be placed under PC
emulatur con~ol by booting the PC emulator configured to include the emulated Iq~ed disk. Conversely, to transfer the floppy or emulated fixed 20 di~ to BWS d~sktop control, the operation of the PC emulator must be halted, freeing up the physical floppy drive aIld the emulated fi~ced disk from i~ controL Icons OIl the display screen represe~ting these sources of data may ~hen be directly accessed to obtain the data stored in these emulated media.
The fourth data transfer technique is a transfer of an actual bil;map of a selected part of the PC emulation wintow i~to a BWS desktop window, ,: `'', ~.. , ' ' , : .
, - , . .

`
.: ~
', '`' ~ ' ' ` .': `

~. . , , ,:

~8~373 using a utility of ~he host s~stem processor. This technique cannot be used ~or transfer o~ data to the control of the emulatin~ processor, but can transfer data generated by the emulating processor to the control of the host system processor. In effect, this particular host system utility takes a snapshot of the s~lected part of the display screen via a selection of data stored in the display bitmap memory, which may be comprises of all or part of the PC emulator window displaying graphics or alphanumeric information, and transfers it to a BWS window of the host system.

Various aspects of the invention are as follows:

A multiprocessor system comprising a general purpose host system having a central processor having real resources including I/0 devices, main memory, a video display for displaying information on the display screen of said display and user input means to said host computer to provide input to said display screen, at least one emulating computer having a processor emulating a target processor unit, a user interface on said display screen including metaphoric objects with which the user can interact by using said input means to selectively change the focus of input for said input means to a desi~nated object visually pointed to via said input means to thereafter permit manipulation of the designated object or interaction with data input/output relative to the designated object, means to allocate a portion of said host system display screen as an emulated display screen for said .. .. .

~X~ 3 emulating processor whereby video information to be displayed by said emulating processor is presented for display in said allocated emulating processo~ screen portion concurrent with the display o~ video information by said host system, means in said interface means to direct user input via said input means as input for either said central processor or said emulating processor said input means to also ini~ially change said input focus to either said allocated emulating processor screen portion or to the remaining portion of said central processor display screen prior to interaction with said metaphoric objects in a selected screen por~ion, the change of said input focus causing subsequent user input via said input means to be directed to said selected screen portion until interrupted by a change in focus input to the other of said screen portions by the user via said input means.

A multiprocessor system comprising a general purpose host computer,having a central processor capable of executing under an operating system of a first kind and having real resources including I/0 devices, main memory, a video display for displaying information on the display screen of said display and user input means to said host computer to provide input to said display screen, a user interface on said display screen including metaphoric objects with which the user can interact by using said input means to selectively change the focus of said input means to a designated object visually pointed to via said input means to thereafter permit manipulation of the designated object or interaction with data input/output relative to the designated object, lla .. ..
.:

~ , .
', ~L2~

at least one emulating computer having a processor emulating a target processor unit and executing under an operating system of a second kind that is inhomogeneous with the operatiny system of said first kind, interface means for emulating real resources of said emulating processor comprising means responsive to the input/output signals of said emulating processor for sharing of said hos~ computer real resources by said emulating processor, means in said inter~ace means to allocate a portion of said display btmap memory and a portion of said display screen as an emulated display screen for said emulating processor whereby video information to be displayed by said emulating processor is presented for display in said allocated emulating processor screen portion concurrent with the display of video information by said host system, means in said interface means to direct user input via said input means to the control of said emulating processor, said input means to also initially change said input focus to either said allocated emulating processor screen portion or to the remaining portion of said host processor display screen prior to interaction with said metaphoric objects in a selected screen portion, the change of said input focus causing subsequent user input via said input means to be directed to said selected screen portion until interrupted by a change in focus input to the other of said screen portions by the user via said input means.

~88~ 3 In a multiprocessor environment wherein at least two display proceissor means are capable of indepeindently and concurrently opera~ing to display data as separate images on a single display screen of a display, comprising a first display processor means for processing and displaying images on said display screen, main memory means for said ~irst display processor means including memory allocated for storing information representative of said first display processor means images, memory controller means under the control of said first display processor means to store and update said informiation in said memory means, display memory means having a storage configuration comparable to the configuration of said display screen, display controller means under the control of said first display processor means to periodically scan said display memory and display the information therein onto said display screen, at least one other display processor means in said environment for processing information for display, said other display processing means having allocated memory in said main memory means of said first display processor means for storing information representative to the entire output from said other display processor means, window manager means in said first display processor means capable o~ creating and tracking window ports in said display memory, one of said window ports being designated for emulating the screen display of the output from said other display processor means, llc '~ ' ; ' . -. i ~2~18~73 said display controller means causing thesimultaneous display on said display screen of both the images of said firs~ display processor means and of said other display processor means via said designated window port.

In a data processor having a display for displaying information on the screen of said display and user input means to said processor for input to said display screen, a user interface on said display screen including metaphoric objects with which a user interacts with via said input means, said objects including a emulator which when opened via said user interaction produces an emulation window emulating the display screen o~ a target processor unit, emulated drive means represented as metaphoric objects on said screen, means to configure said emulator to bind said emulated drive means to the opera~ion of said emulator, means in said emulation window to indicate the presence o~ said emulated drive means.

A virtual object for use in the user interface of a multiprocessor system adapted to display data capable of being generated from at least two different data processors, said virtual ob~ect representative of physical data medium with the data content thereof accessible by either of said data processors, means in said user interface to format said virtual object to a selected filing system.

In a data processor having a display for displaying information on the screen o~ said display, a user interface on said display screen including metaphoric objects with which a user interacts via input means to access said objects, an emulator for emulating a user display of a target processor unit and forming part of said user interface, said metaphoric objects including a lld ' ~2~38~3~73 virtual floppy disk representation capability of being formatted relative to the fi]ing system of said emulator and transferred for insertion into emulated drive means bound to said emulator, the memory for said virtual floppy disk represented via a pointer to an allocated portion of memory for said data processor.

In a data processor haviny a display for displaying information on the screen of said display, a user interface on said display screen including metaphoric objects with which a user interacts via input means to access said objects, an emulator for emulating a user display of a target processor unit and forming part of said user interface, said emulator having an operating and filing system with instruction set alien to that of said data processor, said metaphoric objects including a virtual floppy disk representation capability of being formatted relative to said alien filing system and moved for insertion into emulated drive means bound to said emulator, the memory for said virtual floppy disk represented via a pointer to an allocated portion of memory for said data processor.

In a data processor having a display for displaying information on the screen of said display, a user interface on said display screen including metaphoric objects with which a user interacts via input means, said objects including emulated drive means, said interface means including an emulator of a target processor unit and represented in said user inter~ace via a window emulating the di~play screen of said target processor unit, said emulated drive capable of being under the control of said emulator or said data processor at the direction of the user via said user interface.

lle .

.' -. .
:: :
- . : . . .
,: , In a multiprocessor system including at least two data pro~essors adapted to operate simultaneousl~y sharing the same display to display data on its display screen, portions of said display screen allocated for separate display of data independently generated by said data processors, user interface means for said display scr~en to selectively access either allocated portion of said display screen and means to transfer displayed data from the allocated screen portion of one data processor to the allocated screen portion of the other data processor.
In an emulator comprising a portion of the user interface of a data processor for displaying data on a display screen under the control of said processor, said emulator emulating the color display of a target processor unit, means for color mapping in monochrome said color display comprising a plurality of patterns with each pattern representative of a different color, said patterns represented by a predetermined number of adjacent pixel positions on said display screen, each color being represented in terms of darkness from the lightest color wherein all pixels in the pattern are in a first state to the darkest color wherein all pixels in the pattern are in a second state, colors in intermediate darkness and lightness represented by at least one of said pixel positions in each pattern being in said second state.
A system comprising: first processor means for producing first image data defining images; the first processor means comprising a first processor for executing a first set of instructions to produce the first image data; second processor means for producing second image data defining images; the second processor means comprising a second processor for executing a second set of instructions to produce the second image data; display means for presenting images; the display means comprising a display screen on which images are presented: the display means comprising combining means for operating on the ~irst -llf-image data and the second image data to produce combinedimage data defining combined images that include a first image area and a second image area, the ~irst image area of the combined images being defined by the first data and the second image area of the combined images being defined by the second image data; the display means comprising a display screen on which the com~ined images are presented;
user input means for receiving signals from a user, the signals including transfer request signals, each transfer request signal requesting transfer of data from a source that is one of the first and second processing means to a destination that is the other of the first and second processing means; and data transfer means for responding to the transfer reguest signals by providiny the destination with control of data being transferred; the information transfer means comprising first form means for providing control of data being transferred in a form suitable for operations of the first processor if the destination is the first processing means, the information transfer means further comprising second form means for providing control of data heing transferred in a form suitable for operations of the second processor if the destination is the second processing means.
Other objects and attainments together with a fuller understanding of the invention will become apparent and appreciated by referring to the following description and claims taken in conjunction with the accompanying drawings.
Brief Description of the Drawings Figure 1 is a functional block diagram showing the major components of the multiprocessor system of this invention.
Figure 2 is a schematic diagram illustrating the soft-ware architecture of the multiprocessor system of Figure 1.
Figure 3 is a schematic diagram illustrating the hard-ware architecture and typical screen display abstraction used with the multiprocessor system of Figure 1.
-llg-.

- , - ' .

, . - . , :~ ~ , ~, :
.:. , ~ 88873 Figure 4 is an an enlarged view of the display screen of Figure 3 showing a desktop with various sundry metaphoric icons or symbois.

Figllre 4A is similar to Figure 10 and sho~ls the view of the open wi~dow for 5 the load~r symbol or icon illustrating various software applications and their statu~.

Figure 4B is a view of the property sheet for a particular application.

10 Figure 5 is a view of Figure 4 with the document entitled, ~he ViewPoint Story" opened a~d its content displayed o~ the screen.

Figure 6 is the same view as Figure 4 e:ccept with the emulator icon selected.
re 7 ig tha same view a~ Figurc 4 except with the emulator icon property ~heet opened to view for purposes of configuration of the emulator.

Fi~ure 8 i9 the same vie~ a~ in Figure 7 with further emulator propertie~
20 d;splayed.

Figure 9 is the same view as i~ Fi~e 8 with further emula~or properties displayed.

2~ Figure 10 i the same view as Figure 4 except with the PC emulator icon ope~ed displayin~ the PC amulatio~ window.

,.

..: ~ , .

-- ' ~ ' ' ' ' ' ''' '' ;""; ' ' ' ~ ' ' ' . ' ~a.28~3~373 Figure 11 is a view imilar to Figure 10 except with a ~Tirtual floppy disk loaded into an emulated floppy drive iIl the co~figured emulation wi~dow.

Figure 12 is the same view as Figure 11 except with the PC emulator option 5 sheet opened for viewing.

Figure 12A is a view of the option sheet for the PC emulator when ~Display Optionsn i~ voked upon opening of the PC emulator.

10 Figure 13 is the same view ag Figure 11 e~cept with "floating items" in the emulator display po~up menu displyed.

Figure 14 is the same view as Figure 11 with "Show Keyboard" selected.

15 Figure 15 is a state aIld transition diagram for operation of the PC emulator via the emulator ~rindow.

Figure 16 is a view of the emulated filxed disk property sheet when activated.
Figure 16A i~ a vie~v of the emulated fixed disk opened to reveal its directo2 y of data files.

Figure 17 is a view of the virtual floppy disk property sheet whe~ activated.

... . . . . . . ... . . .... .... . .. .. ~ ..... .. ......

~. , - ~ .

. :' '' ` . ', ~ :' .

8~73 Figure 17A is a view of the virtual floppy disk property sheet when the command "ReRead" has been invoked.

Figure 17B i~ a view of a virtual floppy disk icon opened to reveal its directory of files.

Figure 18 i~ a view of the physical dis~ drive property sheet when activated.

Figure l~A is a view of the physical disk drive property sheet when 10 activated with the [MS-DOS] file system specified.

Figure 18B is a view of a directory of an actual floppy di~k in $he physical floppy drive openedvia the physical floppy drive icon.

15 Figure 18C is a view of the same directory as shown in Figure 18B but accessed via the PC emulation window on a ~DD~ prompt.

Figure 19 i~ a flow chart illustrating configuratio~ of the PC emulator via it~ property sheet (Figures 7, 8 ant 9).
Figure 20 is a flow chart illustrating reco~ ration of the PC emulator via its op1;ion sheet (Figure 12).

FigureR 21A ant 21B ar~ flo~charts illust~ating trans~er OI data between 25 the PC emulator ~vindow and a BWS window.

.. , . 1~--`' ''~ ~..' ', .

, .

B7~

Figures 22A and 22B are views of the user interface display for the purposes of illustrating a transfer of text or data to the PC emulation window from a BW~3 windo~.

5 Figure~ 23A and 23B are views of the user interface display for the pur~oses of illustrating a transfer of te~t or data to a BWS window from the PC
emulation willdow.

Figure 24 is a flow chart illustrating the se~up and initialization of a virtual10 floppy disk.

l?igure 25 is a view illustrating access to the content of a virtual floppy diskvia either the BWS desktop or the PC emulator window.

15 Figures 26 and 2~A are view~ illustrating acce~s to the content of an emulated fi~ed disk via ei~her the BWS desktop or the PC emulator ~nudow.

Figure8 27-27D are news illu~trating trans:fer of data, either graphic~ or 20 text, from the PC emulator window to a BWS wi~dow.

Figure 28 is a block diagram for e~plaining the maImer in which the host system receives user input info~nation.

2S Figure 29 is a flowchart for e~:plaining the stimulu~ level operation.

... . .. .. . . . _ . . . ... . .. . .. .. .. . . ... .... .

.

- ~ . .
- : . .: :, . .
.: .

.

312~ 3 Figure 30 i~ a flowchart tracing the events of the Notifi1er after receiving a call from the stimulus level.

Detailed Dzscriptloll of the Pre~erred Embodiment~

Table of Conte:llt~ of Detailed De~crip~on Seclion Pa~s I. System Over1~iew 17 D:. User Interface 23 A. Icon Type~ 25 B. IcoIl Operation and Windows 30 m. PC Emulator and Its (: o~figuration and Reco~lfigura~on 35 IV. Emulated Fixed Disk (EFD) Icon 55 V. Virtual Floppy Disk Ico~ ~8 VI. Physical Floppy Drive Icon 66 V~. MS DO~ a~d ViewPoint File Name~ d ~e 7
Vm. Flowchart 13xemplification of PC
Emulator Conf'iguration and Reconfiguration 74 IX. Data Transfer Between PC World and ~iewPoint World 80 X-. ~onochrome and Color/graphics Display Modes for PC Emulator 92 XI. Input Mechallism and Methodology 98 A. Irlvoking Icon Functions 107 .
~ .

. . .- ~ .
;. .' ~ . ~: ' 1. Selecti~g the PC Emulator Ico~ 108 2. Request Property Sheet 110 3. Openi~g the PC Emulator Icon 112 B. Data Transfer Between System processors 115 1. Move/Copy Input 116 2. Exit/Boot Tr~sfer 120 3. Freehand Drawing 121 I. System O~rer~iew.
Reference is now made to FiguIe 1 wh0rein there is illustrated the major components of the multiprocessor system 10 u~ilized in this invention. The emulating processor 12 ill system 10 comprises a processor that is capable of e~ecutiIlg sequence~ of the same instruc~ons and ins1;ruction set which a 15 central processor of a target system can e~cecute. This means that if one of those sequences of in~ructions is presented to emulating proce3sor 12, it will perform operatio~ which permit it to coIltinue to e~eeute that sequeuce to completion. While e~cecutiIlg the sequence, it will provide output signals and receive input sig~als like those of the target system. An 20 e~ample of such a target system i5 the IBM PC.

Emulati~g processor 12 shares its resources through an environment that is part o'` host system 14. These shared resources include VO devices, memory alld display which are all under the control of host system 14. Host - 25 system 14 is modified by a comb~atio~ of hardware a~d software to provide emulated I/O and memorg for emulati~g processor 12. This system provides appropriate input signals e~pectet by the target processoF system in , . , 8~373 response to output signals from emulating processor 12. Thus~ when emulating processor 12 makes output calls, i~ is ac~ually making them to host allocated resource~, such as allocated memory in host system 14 or to emulated VO ~unctions, and these calls are handled by system 14 as shared 5 resources of its own environrnent. On the other hand, emulating processor 12 ;s conte~t that it i9 operating with its o~n resource3 and has no reali~ation that the~ remo~e resources are actually shared with another ~ystem. The~e modificalions ~ syste~n 14 are made without sacrificing its OI iginal capabilit;ies but ratherby supplementing it~ capabili~es so that the 10 resulting system i~ more ro~us~ d interactively use~ul in ways not contempla~ed via operation of host syste~ 14 per se.

Details cnncer~ing emulatirlg proces~or 12 and host sy~tem 14 illcluding the emulated interface enYiro~me~t in sy~tem 14 for proces~r 12 are described 15 iu detail i~l previo~ly r~ferenced Canadian patent appllcation Ser No. 535,648.

Emulation of a target proces~or sy~tem would be cumbersome and not a~
use~l if a user were ~ot able to de~l with ho~t system 14 as if it~ user 2 interface were the target sy~em beirlg emula~ed. Thus, it i~ al~ impor~t to emulate the tsrget proce~ s user interface i~ a ma~er which doe~ not sacrifice aIlt disrupt the e~tablished ~l~er interface capabilities of host ~y~te m 14 a~d yet provide~ e m ulated user iDLterface of the target processor sy~te m user i~terface that is readily recogllized by user 18 a~ the 25 display auld user environnnent of the targeted processor sy~te~n. This emulated interface i~ i~tegrated wi~h ~he hostsys~e m userinterface to form i~tegrated user i~terface 16. Interface 16, ~herefore, integrate~ together .. . . .

': ' ' . , the visual user interface of two different inhomogeneous video processor system~ into a friendly environment with shared compatability in the tra~sfer of data between the two dif~erent systems. The emulated user interface of the targeted processor system, i~ functions and operation is a primary fiocus of thi~ invention.

To understaIId i~terface 16, it is use~ul to briefly discuss as background the basic software architecture of host system 14 and also describe some attributes common to the user interface already adopted for host system 14.
Figure 2 is a low level diagra~atic over~iew of the sof~ware archltecture of system 10, and generally depicts the flow of commands through the system software between emulating processor 12, host system 14, VO
devices and user input. The double headed arrows represent 15 communication path~ via i~terfares between softl,vare components shown.
The heavy line at 21 represents the mai~ memory of sysbm 14 which is the primary interface betwee~ VO processor 22 and host pro-~essor 20 both of which are part of host system 14.

20 Emulating processor 12 comprises PC board 30 which contains a 80186 processor for esecuting target processor system code, e.g. MS-DOS and BIOS in the IBM PC. VC:) processor 22 is a 80186 processor comprising PC
ha~dler 32 a~d device handlers 46 written in 80186 assembly code i~
firmware. PC handler 32 ha~dles reque~ts from PC board 30 :for transfer 25 generally to PC t'agene9 34 in host processor 20. Such requests would, for e~ample, be requests to memory for ~instruction sequences, requests to VO
devices under the cont~ol of host ~ystem 14, e.g. a rigid disk memory at , . ~

.. . . .
, . . .
.
` .: . , . . , : ' : ,, .
. ,. , ~
. . . .

drives 24 or printer 28 and the transfer of data to allocated memory space in main memory of host system 14 for display in an allocated region Oll the display screen of display 45. In the case of the physical floppy drive, also represented at drives 24, the software handling is of a minimal level 5 because the functions involved are mostly hardwired so that requests from PC board 30 are handled directly by handlers 32 and 46 to the physical floppy drive at 24.

Host processor 20 comprises a Mesa processor for esecuting Mesa code 10 which is a derivative form of Pascal and is defined in the Mesa Programmer's Manual and Mesa Language Manual available from Xero~
Corporation. Each of the block components shown in Figure 2 is written in Mesa code and represent the fundamental code organization blocks for processor 20. All these bloc~s are found in the 2~erox 608~ worl~station.
lB Processor 20 includes an operating system 42 called 'tPilot" that is called on demand by ot~ier interfaced program such as a Viewpoint applications 36, basic wor~station (BWS) 38 and NS filing system 40. The Pilot operating ~ystem provides the basic facilitie~ needed when calling on main memory, ~vhich call~ may b~, for example, for program e~ecution from BWS 38 or 20 from PC board via handler 3a and PC "Agent" 34. Further information concernillg Pilot i~ fou~d i~ the ~erox Development Enviror~ment Product Overview aIld in the Pilot Programmer's Ma~ual available from Xerox Corporation. Operating 9y9tem 42 would al90 provide the facilities needed to write to disk drives 24 via Pilot "heads" 44 and device handlers 46. Pilot 25 "heads" handle the e~ecuted calls to the software handlers 46 i~ I/O

.. . . . ..... . .. . . . . . . .
.

' "' ;~ ,,: ' .

.

~L2~ 373 co~trollers that provide the low level tracking to disl~ drive sectors for storage of data transferred via handlers 46 to memory media of the drives.

NS filing system 40 represents a tree s~ucture hierarchy of Mesa files with 5 explicit code references as to their interconnection and relationship. BWS
38 represents a 3eries of software ~acilities for providing ser~ices to ViewPoi~lt applications 36. ViewPoint applications 36 are the underlying programs for supporting objects a~d bodies of data on display 4~ includi~g dal;a o~ginating from emulating processor 12 communicated via PC agent"
lQ 34 and applications 36 to display 45. Additio~al info~nation on ViewPoint and ViewPoint application~, ~W~ a~d NS filing including the developme~t of applications a~d programs supporting those applications is provided in one or more of the following publications of Xero~ Corporation: Xero~
Developrnent Environment: Concep~ and Plincipals, 2~DE User's Guide, 15 Se~ices Programmer's &u~dej ViewPoint Applicatioll Developer's Guide, Xeros YiewPoint Programmer'~ Manual alld the Xeros ViewPoint User's Guide. PC "agent" 34 mediate~ between high level code applications of the Mesa enviro~ent to the left of line 23 and the PC enviroDment below line 21. User 18 i~ placed in an abs1;:raction of the l~pical of fice environment via20 display 45 and employs a familiar desktop metaphor present on display 45 to illteract with a PC application, which is another ViewPoint application 36, alld this interac~oll passe~ input to ~he PC "agent~ 34 for ultimate delivery to a PC application running on PC board 30. PC "agent" 34 also traps output from PC board 30 for transi'er to and presentation on display 2~ 45 .--21--..... ~ ... .. , . ., .. _ .... ..... ... . ... ... . ... . .

- - '; ' ' ' ' .
-. , ~, ~ .

' User input 26 represents conventional input devices, such a3 a keyboard 29and cursar control device or mouse 27 connected to system 14. Input 24 ma be input data for that portion of display 45 assigned to host system 14 or conversely may be input data for that portion of display 45 allocated to 5 emulating processor 12. I~ the fiormer case, translation of the input signals through handler~ 46 is focused to appropriate ViewPoint applications 36 desig~ated to receive such input. In the latter case, translation of the input signals through handlers 46 i8 trallslated into appropriate character set of ~he emulated system, e.g. IBM scan codes via PC agent" 34 to ~he keyboard 10 input of emulating processor 12, which, in turn, may provide this as output for presentation in the PC allocated portion of display 45 relative, for e~ample, to a running PC application.

F;gure 3 is a high level representation of the hardware architecture of host 15 system 14 and include3 a view represeutative of display screen 50 of display 48 illustrating an office de~ktop metaphor employing various abstractions of the typical office environment. It i5 important to understa~d the basic methodology present in the ho t system display of the ofi~lce desktop metaphor to also understand the emulated di~play of the target system 20 processor and the interaction between that emulated display and the desktop display of host system 14. The display screen 50 showll in Figure 3 is a miniature of the display screen shown in Figure 4.

~ Figure 3, VO devices axe specifically shown connected via controllers to 25 host system 20. VO processor 22 is responsible for servicing these-controllers. The components connected to VO processor 22 include Ethernet controller 41 eonnected to Ethernet transceiver 37 and l~thernet .. . . _ . . . . . .. .
, - , .

,, ', , , :'`'' ' `, ' . ' - ' . ' ' ' ' ' .
, : ' .: , ' .

~288873 commullication medium 39; rigid disk con~;:roller 43 connected to rigid disk drive 35; floppy disk controller 47 connectsd to floppy diSk drive 25; and se~ial controller 49 connected to receive input 9i~nals ~rom keyboard 29 and input ~ als from mouse 27. Further details relating to thi9 architecture 5 and operation is found in Canadian Patent Application Serial No. 535,648.

Mou~e 27 may be, for example, an optical mouse of the type disclosed in USP 4,521,772. Mou~e 27 ha~ two button~ or micro~witches 31 a~t 33 which sre respec~vely referred to a3 the lef~ but~o~ and the right button.
10 The leflc button is refe~Ted to as "pointn and the right buttoll is referred to a3 "sdJus~". As is common with mouse 27, the movement of the mouse housing on a surface causes display c~or 52 to visually move on screen 50 in the same direcl~on of mouse housing movement. Point button 31, when pressed and released, i9used to i~dicate an object on screen 50 or to an item within 15 an object on ~ en 50. 'rhis poi~t fimct;ion is referred to as "clickin~' the mouse button 31 or 33. Clicking also is ud to iden'dfy the dow~ and release movement of a keyboard key. Adjust button 33 is used in combination with lePc but~ 31, for e~ample, i~ selectio~ of test wherein point button 31 ;s a refere~ce pointer to t}le beg~nning place of te~t to be 20 selectet and right button 33 i~ a second pointer to end place of te2t e~compas~ed by the combina'don of these two selectiona II. U~er Inter~ace.

25 As previously indicated, screen 50 represents the of~lce metaphor and visually displays ob~ects 49 in Figure 3 representing common of~lce abstractions comprising pictorial representa'dons of real of~lce objects, such : ~' ~L~8~3~373 as a desk top~ inbasket, outbasket, documents, file folders, ets. These symbols are refeITed to as icons representi~g cu~ent working environment of user 18 alld are inteIlded to suggest these f~miliar offllce objects. Desktop54 i~ a halfl;one representation and is the primary view of ViewPoint 5 applications that user 18 sees on display screen 50 and there~ore occupies the entire screen 50 a~d appears under all objects 49 displayed on the screen. Desktop B4 resembles the top of an office desk~ together with sulTounding equipmerlt used in the office environment.

10 Message area B6 is the header at the top of scree~. 50 for displaying system messages to user 18. In the e2cample shown there is aIl indisation of the number of ~ree pages lef~ on rigid disk drive 35. Ot er messages would be prompts to suggest the next action to be taken by a user such as in~Jok;ng a ~MOV13> command ~rom moving aII object to another placP OIl screen 50 16 snd display of the message in header 56, l?lease specify a destination". The triple bar ~ymbol ~8 at the left end of header 66 is a l~a~sient or pop-up me~u activated via mouse pointer button 31 held in its down position, thereby visually producing a menu which con s a list ot' command items which may be, for e~cample, Date and Timen, ~End Session" ~logoff), 20 "Spelling Chec~er", etc., which should be self evident as to their usage.
These subcommands are invoked by moving ~he cursor pointer with button 31 still held in its down positio~ over a selected item, which is then highlighted by system 14 to ind:icate to the user its potential selection. At this point, if button 31 is released by the user, the selectiqn is accomplished,25 the pop-up menu visually disappears and the commalld item selected is initiated.

: : ` ' - ~ , . ~ . . ~ . .
.; ~ . , ', ' ` . ' - ~' ' , 9LZ~38~73 Other commands for performillg functions on objects 49 rnay be invoked from keyboard 29. These functions include <DEI.ETE >, which will delete the object and it~ co~tents, <COPY> which will copy the object and its corltents to another desktop lGcation, < MOVE > which w~ll move the object 5 and its colltents to another desktop locatiorl, <PROP'S> which will open a wi~dow displa~nng proper~e~ or parameters for a par~icular object and pro~ide alternative choices for these parameters and ~OPEN> which open~ a~ object to reveal the contents of the object in a BWS window, if the object is design~ted to have a coEltent, fior example, a document conteIlt. An 10 obiect for a program, such as mail program icon 92, which is a binary file, can~ot be accessed via the < OPEN > funct;ion. Every object on the desktop 54 has a property sheet.

A. Object Type~.
Figure 4 ~ows in better detail a number of objects 49 also called "icons"
that might typically appear on desktop 54. These icons are present in the Xero~c 8010 and 6086 workstation and will be briefly identified as to their meaning a~t fu~ct~on.
It is of i~terest to ir itially note that the icorls 49 on desktop 54 are aligned vertically a~d horizorltally according to an invisible orthogonal grid on desktop 54. Thus, their piacement on desktop 54 is rlot arbitrary and the application soPcware ~or desktop 54 is capable of determ~ning and kaeping 25 track of the location of icons on the surface af desktop 54. The locations ofeach square in the desktop grid are listed in the desktop software so that at any give~ time, the deskt;op application can deteImine the X, Y location of --~5--. . . . . __~ _ .. . . . _ __ _ . ... .... . . . .

~, . ' .

icons on its surface and also help to determine whether the positioning of one ico~ on top of another on the desktop is a pe~nissible functiom For example, the ~opping or rele~sing of a document icon onto a file folder icon or on a printer icon, are both permissible functions; the dropping of one 5 document icon o~to another document icon is not a pe~nissible function.
;

Many ofthe icons may be opened via the <OP13N> function to reveal their content, such as a list or dire~tory of files or the conte:nt of a document. In this sellse, ic~ns 49 are container~ representing pointers to files and other 10 bodies of data stored at drives 24.

Icon 60 is a directory di~ider which when opened contains a plurality of directory icon~, one of which i~ icOIl 62. Directory icon 62 serves as a source of icons represe~ting shared and remote ob~ec~s that. the user may access, 16 such ag filillg a~d printing services. Directory icon 62 represents an organizatio~ OSBU" a~d when operled, provides a series of services available o~ the network or LAN, ~rhose iconic representations may be brought onto desktop 54.

20 Ihe ne~t series of icons to be identified are data icons. Icons 64 represent document~ that appear on desktop 54. Document icon 64A is entitled ~Simple Text Doc" a~d docu1nent icon 64B is entitled "The ViewPoint Story, although part of its title will not display since the icon face is not suf~lciently large to display all of the title. However, the title portion 25 displayed still functions a~ a visual pointer for that particular document.
These doeument icons may be copied, moved or opened to display the content of their documents as well as their full titles. Also shown is icon 66 : - .
. . , ' ' ... . . . ..
' , . ' . ,~

,~ . . ''` ~. :
' . :. . ' , .~ .

~LZ~3~3873 ~' whlch is a Blank Mail Note. lhis icon may be copied or moved or opened, and a message typed in the open window of the icon and the icon closed after message typing. Mail icon 66 may then be moved to outbasket icon 72 where it is dropped or released and elect~onically sent to an addressee of the note. Icon 68 is a file folder into which document icons 64 and mail note icon `' 66 may be placed. Opening of folder icon 68 will reveal a directory lisling object~ contai3led in the folder either by alphabetic~l order or chronologically by version date, any one of which may be opened in the '~ folder or moved from the folder and placed on desktop 64. Icon 70 is a bla~k spreadsheet which may be opened to provide a spread of financial data, for e~cample, and may be al80 be copied or moved and placed in ~older icon 68.
. ~ .
The nest serie3 of icons to be identified relate to surroundizlg ~umiture or equipment i~ an offilce enviroIlment. Icon 72, previously alluded to, is an 15 ou~asket for electronic mail messages while icon 74 i8 an i~basket for receiving inco~ing eleetronic messages, such as mail note ~con 86. Inbasket icon 74 displays a mail flag 76 in licating t}iat there is mail to be retMeved by the addressee named on the inbasket. Icon 74 may be opened to reveal a mail ~indow t~rough which mail notes 66 may be accessed and opened or 20 may be moved to desktop 54 and opened for readi~g.

} Icons 80 are file dra~vers for storing data icons and may be opened revealing a directory displaying the titles of documents or folders they contain, which may then be individually opened or removed or copied from the file drawer.
Icon 80~ i~ a personal file of a user while icons 80B and 80C are file drawers L
of groups of users, for e~ample, for a par~cular project. Icons 82 are file drawer divider icons from which a series of icon file drawers, such as icons ,,, - ... .. . . . . .. . ~ .
j; -- : :

., ~! ~
.~., , `

~s~a~

: 80 may be acce~sed. Divider ico~ 82A represents file drawers residing on a remote file server called "The Big Application" and divider icon 82B
represents f~le servers for a ~articular organization~ "OSBU North" within a company.

Icon 84 is a representation of printing resourse called S~abiscuit". The actual printing device may be directly connected as printer 28 or may be remotely located. Document icons 64, mail note icon 66 or folder icon 68 may be moved or copied and dropped onto printer icon 84 a~d their content .~ 10 will be p~inted by local printer 28 which is represented by icon 84. Divider ~: Icon 86 may be open to reveal a plurality of dif~erent printers that are remote and accessible via LA~ 39, ~d may be selected as a printer for priDting the content of document~, mail notes, spreadsheets, folders or the like. In the particular de~ktop ~4 here, the remote printer Seabiscuit" has been placed on Desktop 54 and printable items dropped on this icon will be ` ` properly formatted and se~t to this par'dcular printer.
~ ' .
Dvider icons 82 and 86 are, thus, groups of file drawers or printers that eliminate the hierarchy of going through individual drawers or p~inters separately located on desktop ~4 thereby saving desktop space.

Wastebasket icon 88 i5 a container i~to which, for e2cample, mail notes, docume~ts or folders may be dumped for disposal but are retrib lable since they are still in the container. The metaphor here is that user 18 changes :: 25 hisiher mind about destroyiIlg (deleting) a document or the like and 2 ~ - -,; , . : ~

-- , ~`: '' " ' ' ' .- j : . .
::: , ~ ', , .

~8~38~73 ~`
removes the document from the wastebasket by opening icon 8~ and moving the document ico~ back onto desktop 64.

Icon 7~ is a freehand drawing progra:m comp~ising a canvas which the user ~' 5 may copy graphics into or use palette tools to produce free hand drawings.
Icon 79 ig tne U8er profile for desktop ~4 which contains a listing of various Vie~Point applications present and supporting desktop 54. Various parameters of these applications may be edited upon opening the user profile icon to change, for ea~ample, the location of BWS w~ndow structures.
Icon 70 repre~ents a program or application loader into which a program may be loaded a~d run on de~ktop 54. For example, mail program icon 92 comprising a mail access environment may be moved or positioned onto loader icon 90 to load this ViewPoint application in the runtime environment. Figure 4A shows the loader icon opened revealing in window 91 a directo~y of applications in the loader which are either running or idle as inticated at status 93. "Auto Run" 95 reveal whether an application `~ that i~ idle i~ set to automatically run upon booting host system 14. In w~ndow 91, the application for the PC emulation is shown selected, which is already set in a running mode of operation. To change va~ious properties of this application a loaded, the <PRC)P'S> command may be invoked revealing the property sheet 97 as sho~vn in Figure 413 for the PC emulation applical~oll. Property sheet 97 incl.ldes a parameter listing which may be cha~ged~via cursor 52 and mouse point button 31 to invok.e desired selection 2~ alternatives as shown. The advantage of loater 70 is that user 18 caD force - ~ various applications to be ir~ an idle state so that applications not necessary ~`~
.
~9 - :
.

.
~' ' ` .` ` . :
, `: ~ ` ` . : . "

: ~ ~., ~L2~ 73 .

to a particular user session are not also running, thereby improving e2ecution perfo~nance of host system 14.

B. Icon Operation3 and Windows.
. ~
RefereIlce i9 now made to Figure 5 in relation to the opening of an icon to view its contents. Figure 5 is basically identical to Figure 4. In the illustratio~ showIl, document icon 64B has been previously selected and ~i the~ ope~ed. Thi~ selectio~ is made by mouse left point button 31 being `i 10 clicked ovcr icor 64B. l~e gyst0m response to this selection is to cause the icon to be highlighted, in the same way as represe~ted with icon 94' in Figure 6. Thu9, ~e focus of the attention ot^ the s~stem via desktop 54 has been directet to this particular ico~ 64B. The llext function is to open the icon which in the par~cular e~cample here is accomplished by pressing an 15 cOPEN> key on keyboard 29 which openg the icon container to reveal window 104 co~t~aini~g the data content of the document1 "A Story of ViewPoint". At this poi~t, the position for icon 64B becomes blank except for its title ant repre~ents the outline 64B' of an opened document. Window 104 overlaps part o~ desktop 54 but may also be expanded to cover the entire 20 degktop. Other objects may also be ope~ed on the desktop.

~; Windo~ 104 contains a header 106 which includes a title position 108 for the document, and va~iou9 wirldow commands. The use of mouse point button 31 over the comma~d, "Close", will close the window to returrl it to b 25 its ori~nal icoxl form on desktop 54. The '13dit" command, when invoked~
will permit editing of the document. Command symbol 110 is for pagination, which when invoked divides the document into` a series of '':

: , ,, . . ,: . :
' ~ , ' , . :
; : . :

.
- ' . :

.

~L21~8~3~3 printable pages, dividing the document tegt so aS to permit a masimum allowed lines of text to appear on each given page. Pagination is necessary ~; particul~rly when te~ has been added to or deleted from a document.
1~ changing the position of text from page to page irl the document. Comma~d ,;~ 5 symbol 112 i9 a window ma~ager and triple bar syrnbol 114 is a pop-up menu with additional commands in~olvi~g window attribute~ that may be i~voked or changed.
.
Vertical ~crollbar 116 will permit scrolli~lg of the docume~t vertically up or down ~ithin window 104. The length of central scrollbar 116 between po~itions 116B and 116C represents the full length of the document presentable in window 104 while diamolld symbol 116A represents the par~cular page in the document being displayed in the window. Since diamond symbol 116A i~ at the top of bar 116, the page being displayed in window 104 i~ the first page of the document. Invoking of mouse point button 31 a~ywhere along bar 116 w~ll cause the document to be moved to ~; the document page represented at that point along bar 116. Scrollbar portions 116B and 116C peFmits page by page scroll, respectively, up and down whe~ invoked by mouse point button 31. Scrollbar porlions 116D ~d 116E represent li~e by line scroll,respectively, up and down when invoked by mouse poillt button 31. Clicking mouse point button 31 over any control point 120 invokes a tDp/bottom operation, e.g. where there are a series of overlapping ~nndow~ on display screen 50, th~ clicking of the left point button at point 120 will place ~he invoked window on thethetop of ~he other , .
2~ windows~ Clicking the sam e point again in the sam e window will put it ~` beneat the other windows. Pressing point button 31 down and holding it in any control point 120 and moving mouse 27 will move the entire window ; ~ --31-- --.. . .
.
.

, .2~38873 . .

104 to another location on desktop 54. Pressing adjust button 33 down and holding it in a~y control point 120 and moving mouse 27 will resize window 104, i.e. either enlarging or ~educing the overall dimensions of the window.
Invoking poin~ button 31 over either end of horizontal scroll~ar 11a will 5 cause horizontal left or right scrolling of the document.
';
Reference is again made to Figure 4 to complete the brief description of ` icons on desktop 54. The se~eq of icons in the lower lef~ corner of desktop 64 involve the emulated user interface of this invention. Icon 94 i~ the PC
emulator which, when opened preseIlts a display window emulating the display screen of the target qystem, e.g. the IBM PC display screen. Icons 96 and 98 are virtual floppy icon3 which besides being objects in the i 3 e~vironment of desktop 54 are also insertable representations of floppies tha~ may be inserted into emulated floppy drives of a confilgured PC
emulator represented by icon 94. Icon 96 contains a version of M~DOS
~'~ operating sy~tem which may be loated into aIl emulated floppy drive of the ~` configured PC emulator 94 from which PC emulator may then be booted.
, ~ Icon 98 represent~ other vi~al floppy icon which may contain a unique ~` name and various sof~ware programs and application3. Icon 100 is an emulated fixed disk representation which may be co~figured into the PC
emulator. Both virtual floppies 96 alld 98 and emulated fi~ced disk 100 are ac~ually pointers to real disk locations allocated by host system 14 on its rigid di~k drive 35. Ison 102 i a pointer to the physical floppy drive 25 o;
host 3ystem 14. Icon 10Z may al~o be configured into the PC emulator so as to be under the control of emulating processor 12. Again, the PC emulator .. .. . .. . . . . . . .... ........ .. . . . .. . . . .
.. ~.

~`' : : , . . .

.. ..
, .

. , .

~ 288~
~, , 94 is sharing resources of host system 14 although it believes that these resources are fully under it~ own exclusive use.

.` As used above and in this description, the t~rm "emulated has specifis 5 reference to an actual VO device via emulating software and in this sense is the opposite to physical, which has speific reference to an actual VO device such as floppy disk drive 25. The term ~virtual" has specific reference to the ~` role of some medium such as a floppy disk or diskette via emulati~g softl~vare. As used herein, the term disk" also has reference to "diskette or 10 disk", as the floppy drives employed may be 3~", 5" aud 8" coIlfiguration.
~ The ten~ cor~iguration" when referenced to the PC emulator has specific '~ refere~ce to the assignment of physical and emulated devices to the PC
~ emulator and these devices will symbolically appear in the PC emulation ~: - window when configured. The import~t functions to under~d for the15 purpose of this disclosure are the ico~ invoked functio~s of ~OPEN>, ~; <COPY>, <MOV13~, <PROP'S> and cDELETl3>. These functions can be invoked via any user input 26 but, as previously e2plained for the purpo~es of thi~ particular implementation, are invoked via a selected key on keyboard 29. U~er la can move an object, e.g. a~ icon or text inside an 20 open window, from one location O~L desk~op 54 to ano~her by seiecting it withmouse point button 31 and clicking the <MOVE> key. At this point the cursor shape will change from the arrow configuration at 52 to either a symbol indicati~g a move selection has beeu invoked or a ti~y representation of the object selected. The originally selected icon also 25 becomes unhighlighted and a message appear~ i~ header 56 requesting an indica~ion as to where t.he object's destination is to be on desktop 54.
Destination i5 indicated by user 18 clicl~ing either mouse button 31 or 33 at ~; - 33--... . _ ~ .. .. . .. ... .. . . . .... . . . .. .. . . . .. . ... . . .
,. .

.

: . .
.

~28~313'73 , -` ~ the 3elecl;ed de~ktop destination. The <COPY~function is the same as ~MOVE> e~ccept the selected object ig not deleted from its original location on desktop 54. When user 18 designates the point of destination with either mouse button~ th~ copied object is released at the new 5 destination, the copied object becomes selected and the original object elected, the latter ha~ring not been changed in ~y way. ~he invoking of the <DEL13TE> function will delete the object after confirmation via a mes~age in header 56. Confirmation after the <DEL131~13> selection ca~
be specified in the user profile found in user profile icon 79 not to be 10 operatiollal. Lf so, any deleted object ~rill need no corlfilmation and the deleted object is placed in the wastebasket icon container at 88. All objects on the desktop 54 and bodies of data in objects have properties which may be displayed by pressing the <PROP'S> key after a particular object has been selected. An appropriate property sheet will be displayed for the selected 15 object showing parameters pertaining to the object. These parameters may be altered by edits to parameter location~ using mouse point button 31.
-Again with re~erence to Figure 2, all of these object~ on the desktop includi~g desktop 54 are ViewPoint applications 36 comprising active 20 so~are compone~ts con~ected in a relationship defined by a tree s~ucture hierarchy in NS fili~g system 40 using generic facilities to perfo~n the `~ various object functions set by localion address in BWS 38. Fur~her details concerrling th.se relationship~ and functiorlality may be found in the ~ previouslymentioneddocumentation.
; 25 ~ .

- . ~ . . ~ .
.
.~: ~ . . '. . . ', , . ` ~

: . ' - '`' : - , ; :
~' , ' : .: . . . . . .
.
.- : .

~LZ8~3873 .~ .
III. PC Emulator and Its Coni~guration a~d Reconfiguration.

, ~ .
E~ilanation will now be directed to configuration of the PC emulator 94i employing also icons 96-102. Figure 6is identical to Figure 6 e~cept that ;`~i 5 cursor 52 via mouse 27 has been moved over PC emulator icon 94 and mouse point button 31 has been clic~ed to selecg icon 94. The system has responded by highlight icon 94, as indicated at 94' in Figure 6 by reversing the video of the icon.

It i~ of interest to note that in configuring PC emulation icon 94, or for that matter copyiIlg, moving or maili~g of icon 94, what is ac~ually being copied ~,` is the configuration i~formation stored in memory for the particular instance of the icon and not the emulation per se. Thus, icon 94 is a pointer to a particular configured PC emulator. Two or more copies of PC emulation 1~ icon 94 on desktop 54 permits multiple installce3 of various configurations i` thereby allo~ing user 18 to eatablish alternative configurations prepared in advance. In any case, a PC emulator icon may be preconfigured before booting the PC or may be reconfigured on-the-fly, that is, during a user PC
emulation session requiring re~ooting of the sytstem after reco~figuration.
With PC emulator icon 94' highlighted, a PC emulahon session may be started by pressing the <OPEN~ key. Assuming that the emulator has already been preco~lgured, the PC emulation window will appear and the system may be loaded and booted. l'he PC emulator icon may also be preconfiguredtoimmediatelybootfrommemorywhenthe <OPEN~ key~s pressed at this point.

,`` . ~ ' ~ ,;. , ."`: ` ~ ' . ' ~ ~:` ', ~ ~ :
:

81~7 :. .
The user may conf~lgure the PC emulator by activating the emulator property sheet 122 by prssing the <PROP'S~ key. Emulator property sheet 122 is ~hown in Figure 7. Sheet 12Z is like any other standard ~'~ window, e.g. window 104, ~o that further description a~ to the window `` ~ header and verlical/horizontal scrollbars is not necessary for this wi~dow or later described window~, exsept in cases of different commands appearing in the window header. Sheet 122 has a header identifying it as the PC
emulator properties window and the commands ~Done, "CaIlcel" and "Default ". The command "Done" in this window, as ~ell as other windows, 10 will cause the changes made initiated in the property sheet to take effect.
The command "Cancel" will close the property sheet leaving icon 94 in its highlighted state and not enforcing any parameter changes that may have been selected in property sheet 122. The command "Defaults" causes certain parameters in property sheet 122 to system chosen parameters.
15 Sheet 122 al~n corltain~ a number of parameters including a label ideDLtifierdesired for the parl~cular icon contai~er, the number of disk drives desired r~ for the confi~ration and their combination, whether the emulation will be ~ . ~
booted from an emulated fia:ed disk or from a configured floppy drive, ~hether the system is to boot upon opening of PC emulator icon 94 and ~" 20 whether display cptions, i.e. the PC emulatio~ parameters as configured should initially appear upon opening of PC emulator icon 94. The selections are made with t~e mouse point button 31 and are alterllative if there are multiple choices o}l a given parameter line. The configuration shown in -- Figure 7 i9 the inclusioll of a floppy drive and a rigid disk in the popular 25 configuration of the PC-XT. Co~ ration details are hidden from view but furtherchoices andconfiguration changes for disk drives can be made by .- .. . . .. .....

- ~
' . ' : . .

. .

- :
. . ~ , ~ , ~a2~ '73 choosing "Other" in the "Disk Drive" configuration line to select a configuration other than the default configuration now shown in sheet 122.

The activation of "Other" is shown in Figure 8, thi5 parameter having bee~
5 selected, a5 indicated by being highlighted. This action brings into the configuration selection, the assignment and /or loca~on of emulated floppy drives at the parameter lins designated "Floppy Co~figuration", Physical floppy drive of system 14 at the parameter line designated "Physical Floppy" and the emulated fixed disLc at the parameter line tesig~ated 10 nFixed Disk".
.
Note that property sh~et 122A will present only valid choices. If only two drives are in the config~ration, the choices O and 1 (and none) will appear for physical floppy drive. The section of "emulated floppy drive" is implicit:
15 all drive~ Ilot designated as physical are assumet to be emulated and will accept virtual floppy disks. I the Fixed Disk [YES]'~ choice i9 invoked, an emulated fixed disk will be bound to the PC emulator. Regardless of MS-DOS assigllment of devices to drive~, the symbol indicating the presence of ~the emulated fixed disk always appear~ to user 18 in location 126E. User 20 1~, of course, has the option of specifying no fi~ced disk by selecting "Fixed Disk [NO]". No symbol appears at 126E in this case. The desired selection becomes ef~ective UpOIl booting the PC emulation.

:If the "After Opening Window [BOOT PC]" parameter is set, the PC
:~` 25 ~ emulator will automatically be booted whenever PC emulator window 124 is opened with the preconfigured parameters. If the "When Opening Window [DISPLAY OPllONS]" is set, an options-while-openi~g sheet: 135, .
~ .. .. .. .

~.: : ,:
:.~: , ~ , .
~ :
, ' '91 28~387~3 shown in Figul e 12A, will be displayed whenever an < OPEN ~ function is i~voked on PC emulator icon 94. The PC emulation window will not appear until the command "Start" in the comma~d bar of sheet 135 i~ invoked.

If Details" in property sheet 122 is i~voked as shown highlighted in Figure 9, the additional parameters shown in property sheet 122B below "Details"
will be displayed. Thes~ additional parameters are fairly obvious.
"AutoRepeat" is a place where timing values may be specified as applicable to keyboard operation. 'Initial Repeat Duration" controls in milliseconds 10 the amount of time a key on keyboard 29 must be held down before automatic repetition of that key functio~ begins. "Ensuing Repeat Duration" controls the amount of time in milliseconds between repeating keyboard invoked characters. "Display Adapter" is for the selection of either a Color Graphics display or a monochrome display. "Memory Size"
15 invokes the amount of main RAM memory that is to be allocated by system 14 for use in connection with an emulated device. The memory size shown selected is for l28 kilo bytes of RAl!ll. When the PC emulator i5 booted, system 14 forces other applications usin~ real memory to be swapped out onto rigid disk drive 35 to acquire the necessary Rl-M memory. These 20 applications, if active during PC emulation, will continue to operate but more slowly due to their rigid disk drive access. A porlion of the allocated memory on boot may also have MS-DOS swapped in from tloppy disk drive 28 into allocated RAM memory. "Printer" selection allow~ either a printer directly attached to the wnrkstation, e.g. physical printer 28 connected to 25 host system 14, or a networked Interpress printer, providing industry standard fio~at~ing of electronically held documents for printing. "Page 3~3--~ . .

- '; , ~ : ' . , :

. .
. ~ . . .. . .
.

~L~8~873 Size" is default at 8.5 ~ 11 but may be changed as to page orthogonal orientation or page size as shown.

Additional operakional info~mation relative to configuration is discussed in 5 coImection with Figure 19.

The parameters having been selected in property sheet 122, the sheet may be disposed of by initiating the ffDone" command leaving PC emulator icon 94 in the highli~hted fo~m 94' ~hown in Figure 6 while also invoking the 10 parameter selecl;iong made to PC emulator icon 94. At this point, the ~OPEN> key may be pressed, which will open the PC emulator window 124 as shown in Figure 10, leaving behind an open iconic space 94A visually i~dicating to user 18 'chat this icon has been opened.

15 Window 124 pr~vides an emulated PC srreen within which user 18 may i~teract in the same manner as with an IBM PC. Window 124 includes emulated PC screen 125 through which the user communicates with all PC
programs. The PC emulator header involves three components: a device bar 126, a message s~lbwindow 128 a~d a command bar 130. Device bar 126 20 represent~ iu symbolic form the physical floppy drive, emulated floppy drive8, a~d emulated fiaced disk as these drives have been configured into the PC emulation via property sheet 122. Device bar 126 comprises four dif~erent location~ *om 0 to 3 shown respectively at 126A, 126B, 126(; and 126D for up to four emulated floppy drives or three emulated floppy drives 25 and the physical floppy drive. Location 126E in device bar 126 i5 for indicating the presence of an emulated fi2ed disk in the conffguration. The configuration selected and shown is as highlighted in sheet 122A in Figure ,~ :

~ ~ . ' , ' , ,' 1.2~38~373 8 comprising three floppy drives in locations 126A, 126B and 126C with location 126A or position 0 being chosen for the physical floppy drive, representative of system physical floppy drive 25.- .As shown in Figure 10, the physical floppy drive is shown in grey outli~e at location 126A while locations 126B and 126C show in solid outline emulated floppy dri~,7es. The configuration as previously set in property sheet 122 includes an emulated rigid fia:ed disk wi'ch its symbolic outline at location 126E with its iconic form shown at 100. However, sillce the devices represeuted by icon~ 100 and 102 are now bound to the PC emulator configuration as booted, the fimction key for <OPEN> after selection of either icon 100 or 102 on desktop ~4 will not be respollsi~7e. These devices are only accessible either in system 14 or PC emulator 94 and cannot be accessed co~curTently by both systems. Once a se~sion with the PC emulator has been completed and the "Close" command in command bar 130 is invoked, icons 100 ~d 102 are unbound from the PC emulation aud may be opened via desktop 54 using the ~OPEN> fimction. Of course, these icons could also be opened to reveal th~ir contezlt during a PC emulator session if they are not part of the PC emulator configuration i~ operatiom Message sub~vindow 128 is where status and error messages are shown to the user in cormectio~ with PC emulator operation and running of PC
programs. Thus, the subwindow is independent of the global message area of system 14 in header 56.
' Reference i9 now made to other commands in command bar-130 in PC
- emulator window 124. The '~boot" command will cause the PC emulator to be bouted if it i8 not already automatically booted via the parameter set in - ~ 40--.
- . . . .

' ': '' ' -` , , :

.

~L28~8~73 emulator propert~ sheet 122. If a floppy is currently in dri~re O at location 126A, this drive will be employed as the boot device. Otherwise, the PC
emulator will be booted from partition ~pecified for the emulated f'ixed disk at 126E, if included in the configuration. In this particular case, MS-6 DOS is residellt at the allocated partition for the emulated fixed disk. If~either floppy drive 126A nor emulated fixed disk 126E can be employed, a message will be displayed in subwindow 128 indicating this fact.

As previou~ly indicated, the ~Close" comma~d causes the PC emulation 10 window 124 to return to iconic form 94 after confirmation by the user, te~ninating~ PC emulation activity. All devices in the PC emulator configuration are unbouDd and are available for general purpose use from desktop ~4. Also, before closure of PC emulation wirdow 124 can be activated, the PC emulator will require the user to unload any virtual 15 floppy di~ks ~l;ill loaded in configured emulated floppy drives at 12~B and 126C aIld to return them to desktop 54.

I~e "Pause" command is a~ important command in PC emulator usage i~
the transfer of data between the PC and ~TiewPoint worlds as will be 20 explained later. The invoking of l'Pause" suspends all PC processor activity as distinguished from a processor being placed l:n an idle state. PC
processor ~ill be in a "frozen" state ru~ning a halt routine that suspends the execution of code. This: frozen state allows the user to select data in PC
screen 125 to be copied i~to a ViewPoi:llt application, such as all opened 25 document ico~ 64. The data copied ca~ be data displayed on screen 125 since the operation of the PC smulator has been halted . ~ 4 1 .
;.. . - , . . ..
, . . ..
. .
. .

, ~L2~ 73 During this frozen state~ a "Resume" command replaces "Pause" command in co~nand header 130. When the user wants to continue PC operations, the "Resume" command is invoked permitting the PC emulator to be "thawed" and ea~ecute instructions at processor 12 beginning at a point 5 where it left off executing instructio~g prior to invoking the "Pause"
command. These and other po~ible states of the PC emulator will be discussed in filrther detail in co~ection with Figure 15.

The command "Show Options" displays what is termed an option sheet 136 10 shown in Figure 12 and has nearly the same contents as found in property sheet 122 when "Other and nDetails" (property sheet 122B in Figure 9) are invoked. At this point, the user may change the default device configura'doII as originally set in properl;y sheet 122 as well as the other parameter~ shown. Beside the com3nallds "Cancel andnDefaults" in option 15 sheet header 138 a~ in property sheet 122, there is the command "Resonfigure whieh in~oke~ any changes made in the option sheet to be applied immediately to the PC emulator configuration. Changes rnade will be immediately reflected i~ PC emulator device bar 126, allowing the user tn reboot from the ready state either from emulated fixed disk or perhaps 20 after the user has loaded media, such as the MS-DOS 3.1 virtual ~loppy 96, into an emulated floppy drive of the reconfigured PC emulator.
Reco~lgurations require confi~matio~ si~ce there will be an interrllption of aIly running PC program and require rebooting since there has been a cha~ge in configuratioIl. If a virtual floppy is present in all emulated floppy 25 drive, such as illustrated i~ drive 1 at location 126B in Figure 12 and this drive location i~ changed to the physical floppy drive or is removed from the ,,.. ,., ~ - ~ :. , lZB887~

configuratiorl, any attempt to reconfigure will be caneelled until the virt~al floppy is withdrawn from the floppy drive and I eturned to desktop ~4.

It should be noted that any changes made in option sheet 136 are only 5 effective for present PC emulation session and upon ending the- current session aud closing of the PC emulator window, any parameters cha~ged in optiou sheet 136 will revert to default settings previously established in the original configura~on of the PC emulator property sheet 122.

10 Additional operational information relative to reconfiguration is discussed in comlection with Figure 20.

The "Show Eeyboard" command cause3 the PC emulation keyboart 140 to appear on desktop 54 in the lower portio:a of PC emulator window 124 as 15 sho~n in Figure 14. Keyboard 140 comprises the main PC virtual keyboard 140A and the ~ight side virtual keyboard 140B. There is also a function keyboard 141 comprisi~g ten keys for ten corresponding keys present along the top of keyboard 29. These function keys perform special functions such as center~ng text, te~t bold, text italic~, te~ underline, text or character 20 superscriFt and te2~t or character subscript both in PC emulation or ViewPoint.

It should be noted that keyboard 29 is generally interpreted as the input for ViewPoint applications of host system 14 but whenever the PC emulator is 25 runnin~ and whenever the mouse point button 31 is clicked in PC window 124, the input focus for mouse and keyboard input is directed to the PC
emulator a~d keyboard 29 will be interpreted as the virtual PC keyboard _ ~, . .. . .... .

;
- .

~ :' ' ~L281~3~373 direc~ng keyboart input to PC emulating processor 12 in the manner e~plai~ed in detail in patent applicatio~ Serial No. 535,6~8. Thus, user 18 must initially clic}~ button 31 i~ PC emulatio~ wi~dow 124 to establish input focus to the PC emulator.

By clicking "Sho~ Eyboardn in header bar 130, the virtual PC keyboard ~rill appear so that the overlay of the PC keyboard key~ on actual L~eyboard 29 i~ visually understood by the u~er. With input focu~ in PC window 124, u er 18 may type input via keyboard 29 into PC ~creell 125. Virtual 10 keyboard 140A as disE~layed in Figure 1~ is also opera~ional via mouse point button 31 by moving mouse 27 to move screen point cursor 52 over selected l~eys and clicl~i~g mouse point butts~ 31. Typed characters ~ill then appear in PC screen 125.

15 When the input foc~ ha~ bee~l set to PC ~n~dow 124 and the PC virtual keyboard i9 in efflct, co~ver~io~ &om hoat system font characters, also referred to as NS characters, l;o IBM scaIl codes i5 llecessary. All keys on keyboard 29 generate their o~ Imique positio~ codes on both down s1;roke a~d up stroke of each key. When keys~okes are detected, the scan codes are 20 developed by PC ~Age~t" 34 alld p~ssed through handlers 32 and 46 where the conversion takes place and the co~verted code i8 ~a~sed via PC Agent"
34 to ViewPoint applicatiolls for display on PC scree~ 125. The co~version ~rom NS characters to I13M scan codes iq illu~at~d in Table I.
.

25 Reference i~ mate ~ow to Figure~ 10 and 11 ~rherein in Figure 10, virtual floppy 98' is ~howll highlighted because it ha~ been ~elected. With the < MOVE ~ fiallc~o~ invoked, virtual floppy 98' may be moved na mouse 27 --4~ -.: = . ........... . . . .

' .
' ~ . `" ' ' .

~88~3'73 Table I
_ __ ___~ _ ___ __ Ilown Up Down Up Do-wn Up K~y Code Code Key Code Code K~y Code Code (He~) (Hes) (He~) (H~) (Hex) (He~) __ __ __ __~ ~_ ___ __ A 1E 9E 2 03 83 Pg Dn 51 D1 B 30 BO 3 04 84 Insert 52 D2 C 2E AE 4 05 8~ Delete 53 D3 D 20 AU S 06 86 PrtScr 37 B7 _ __ __ _ __ _ __ ___ E 12 92 6 07 87UpCursor 48 C8 F 21 A1 7 08 88DnCursor 50 DO
G 22 A2 8 09 89BackCur 4B CB
H 23 A3 . 9 - . . OA 8AFwd Cur 4D CD
I 17 97 F1 3B BBNoOp 4C CC

K 25 A5 F3 3D BD + 4E CE
L 26 A6 F4 3E BEBackSpac OE 8E
_ __ __ _ _. __ _ ........................... . . _~
M 3Z B2 F5 3F BF R/L Tab OF 8F
N 31 B1 F~ 40 CO R Shift 36 B6 O 18 98 F7 41 C1 L Shift 2A AA
P 19 99 F8 42 C2 , 33 B3 _ __ __ _ __ __ _ __ __ Q 10 90 F9 43 C3 . 34 B4 S 1 F 9F E5C 01 81BackSlash 2B AB
T 14 94 CTRL 1 D 9D _ 27 A7 U 16 96 ALT 38 88 , 28 A8 V 2F AF Return 1 C 9Creversecl ' 29 A9 W 11 g1Caps Lock ~A BA OC 8C
X 2C) ADNum Lock 45 C~ = OD 8D
_ _~_ _ __ , " _ _ .. , __ Y 15 9S Scrol l Lock 46 C6 ~ 1 A 9A
Z 2C AC Horne 47 C7 1 1 B 9B
O OB 8B Pg Up 49 C9space 39 B9 1 02 82 End 4F CF
, __ __ _ _~ _. _ __ _ --4~--: ' : . ' ;
. ~ .
.
: ': i ~ ' - : :

~88873 to any emulated floppy drive, e.g. in location 126B or 126C in this illustration. During this movement of the representation of icon 98, cursor 52 takes on the representation of a miniature floppy disk as shown at 98" in Figure 10. Irhis representation gives user 18 the visual appearance of 5 actually moving a floppy from its original location on desktop 54 to a floppy disk drive in PC emulator 94. Once icon 98" is positioned over the selected emulated floppy disk drive, mouse point button 31 i~ clicked, dropping ~loppy 98" "into" the emulated floppy drive at a designated drive locatiom The re~ult i~ that the floppy is loaded into the selected drive a~d user 18 is 10 informed that thi9 ha~ been accomplished by the appearance of the virtual floppy label appearing at the selected floppy drive location. An e~ample of this section is illustrated i~ 13 igure 11 whereby a virtual floppy disk icon 96labeled Xerog DOS 3.10" has been copied and inserbd i~ virtual floppy drive 1 at location 126B via a tiny icon 98" and the floppy label appears at 16 that location. It should be no~ed that vir~ual floppy disl~ ico~ 96 ~eed Ilot be copied, as a practical man~er would normally be moved to drive location 126B and, therefore, removed from desktop ~4.

Local;ion 126F in device bar 126 of PC emulation window 124 is a printer 20 symbol. Documents or data files accessible irl the PC emulator may be directed for printing by clicking the mouse point button 31 over the printer symbol 126F. The data that had been directed by the PC program to the PC
printer port of emulating processor 12 will be co~verted to make an Interpress master, i.e., folmatted for pri~ting bg an Interpress printer. This 25 ~ conversion is indicated as in progress by the horizontal oscillation or movement of arrow 138 poi~tiug to use Interpress master symbol 139.

, , , . .
: ` ' ' ` . ~ ' :

. . -`:

Interpress printing means that user 18 intends that the ultimate destination of the data to be printed is a laser printer connected to local areanetwork (LAN) 39, ~uch as Ethernet. Interpress printing is based on a "print file" that grows as the particular PC program invoked sends bits 5 through what the PC emulator believes to be a printer port. User 18 causes a file to be ~ onverted to an Interpres~ master by clicking the mouse point button 31 over the Interpress master symbol 139 in device bar 126, whereupon cursor 52 will change to a small Interpress mas~er icon, indicating that the prepared Interpress master may now be dropped 10 anywhere desired OII desktop 54, including o~to an Interpress printer icon ~4 which will send the ma~ter over LAN 39 to this co~ected printer, named "Seabiscuit", for print out. Printing can be stopped midway by invoking the ~STOP~ function from keyboard 29. Any PC application capable of producing an Interpress master may do so leaving the master on a floppy 15 (real or virl;ual) disk or on the emulated fixed disk for eventual transfer to printer icon 84.

Locai;ion 126G is a t~iple line symbol representing a pop-up menu which, when irlvoked via mouse poi~t button 31, produces, as an eacample, pop-up 20 menu 142 sb.ow~l in Figure 13. Menu 124 a~ shown is when Interpress printing has been invol;ed. If losal printing, either serial or parallel port, has been i~voked, the commands for these selections will have been replaced by the command, ~terpress printing", so that it can again be invoked, if desired. The selection of a fu~ction in this menu is accomplished .
25 by moving cursor 52 over one of four menu functions, mouse point button 31 still being maintained in its down or pressed position, and thereafter releasing button 31 over the function selected. At this point of release, the ., .... ... .. ... . ., , . . ..... _ _ . . ... . . . . .
. .

: - :
.. . . .
` ' ~
.. . . . -.
, :. . . . : , - . ,. .
: , : .. .... .
, . . . .

~ ~38~73 pop-up menu will disappear arld the f1mction selected will be initiated. The functions shown in Figure 13 all in~olve printer parameters such as a se~ial port or parallel port type printer, paper size at the printer and whether bits collected for printing but not yet converted into an Tnterpress master should 6 now be discarded. Menu 142 is an auxiliary menu for local printing accomplished by local printer 28 of either the serial port or parallel port type. Thi~ change ~rom Interpress to local printing is accomplished without requiring the PC emulator to be rebooted. As with any local printer, it is the userts responsibility to 'load" the paper size appropriate for the pages to 10 be printed. The user caII over~de at this point the default set in emulator property sheet 122B by invoking the "Set Paper Size" command in pop-up menu 142. This action produces a simple option sheet containing the paper size choies for selection and change. This paper size affects only Interpress printing since, as already noted, local pAnting requires that user 18 load 15 the desire`d paper manually. The "Discard Printing" command causes the print file in pI'OgI'e9S to be delel;et and will immediately cause the creation of a new print file if bits for printing are still bein~ emitted by the PC
program.
.

20 When the Interpress implementation determines that there is not enough main disk space for preparation of an Interpress master, the implementa~on will put the PC emulator automatically into a "Pause"
state so that no program can emit any more bits for printing. A message is posted to user 18 notifying this condition. The "Resume" and "Discard 25 Printing" commands are available at this point. User 18 may print the --48-^
.. . . .. , _ ... ... . , , . _ _ . ... . . . . . .
, . . .
..

~, ' ':

` ~: , , . : :

~L~8~3873 print file immediately, freeing up disk space but risking discontinuou3 output, or free up file space on disk 3~ in some other way.

A typical user action sequence may be as follow~: ~

In the followi~g scenario, user 18 wishe3 to edit a docume~t using WordStar, printi~g successive dra~s on his local printer until satisfied with the results, then printing a final copy on a networ3~ laser printer via icon 84.
10 From the open PC Emulation Window, user 18 t.ake~ the following steps:

1. User 18 invoke~ pop-up menu 142 in the printer slot 126G of device bar 126 to ~ntch to local pri~lting, either serial or parallel port. Menu 124 at this command positio~ cha~ges to the command, '~terpress printing".
16 Af~er a co~llmation, this discards any Interpres3 printing that had been previously accumulated.

2. Runs the WordStar application in the PC emulation window 124. User uses ~WordStar's "print" comma~d, which produces drafts on local printer 20 28.
:
3. Ready to print a final copy, user 18 switches to Inte~ress printing via pop-up menu 124. If user i8 wanted to change the page size to, say, landscape, user 18 would use pop-up menu 142 to bring up the page size 25 options and choose 11x 8.5.

:: ~

., . ... _ . .. ~ .. . ., .. , .... . . , .. . . . ... . ~ . . . ..

. . . ~ . . .
.: . . . . , ~ -, . . . . . .
: ~ : . . . ..

~ILZ~8~

4. User 18 then invokes the WordStar's "print" command one last time.
The arrow 138 oscillates horizontally to indicate that the PC emulator is sending bits for printing. Eventually, it stops, and WordtStar itself displays a message that printing is complete.

. Finally, user 18 click3 the mouse point button 31 o~ the printer symbol 139 in the device bar 126, whereupon the cursor changes to a tiny Interpress master, a~d the message "Please iIldicate a destination with either mouse butto~t' appear~. User clicl~s o~ce more on the icon 84 for "Seabiscuitn, the 10 closest p~ter in the building, for e2catnple. After several seconds7 the print file's conversion to Illterpress format is complete and the master is queued for tra}lsmission to the Seabiscuit" printer via icon 84 pointer.

Having explained i~ detail the PC emulator interface in the form of PC
15 emulation window 124, reference will now be made to the different PC
emulator livindow st~tes and tra~sitions as illustrated in Figure 15. Figure 15 represents in flow form the dif~erent modes of operation of the PC
emulatorvia user input.

20 The PC emulator is, to begin with, considered from its nonactisle state and the PC emulation window is closed as indicated at 144. The PC emulator icon 94 ha~ already been preconfigured as previously discussed via its property sheet 122. The PC emulator i9 made operational by first selecting PC emulator icon 94 and then invoking < OPEN> as pre~7iously explai~ed.
25 The PC emulation window 124 will appear. At this pointt the PC emulator is in "Ready" state 14~. In state 146, icon 94 is open but the PC emulator ~r ha~ ~ot been booted unless the parameter, "After Opening Window LBOOT

. . , . .. . . ..... , . . . . _ .. . . . . .. .. . . . _ ._ . . _ .. . ... .. .
. ,.. ,..... , ~ . .

3L28l38'73 PC]" has been previously invoked in property sheet 122, and t~e invoking of this parameter is indicated by dotted line 148 in Figure 15.

Ill "Ready" state, the commands Close", Show Options", '13Oot", ~Show 5 Keyboard" are available. In state 146, i~voking "Show Options" permits the parameters in option ~heet 136 (~igure 12) to be changed and applied to the emulation as indicated in Showing OptioIls" state 150. As shown in Fi~re 12 and indicated in Figure 1~, option sheet 136 may be cancelled.
Changes may be made at this point to the configuratiorl in device bar 126.
10 Howsver, any emulated floppy drive removed by reco~figuration with virtual floppy media in its drive will have to have the floppy media removed before invoking reconfiguratiom Also while in state 150, it is not possible to load virtual floppy media or to boot the PC emulator.

15 After reco~iguration, the user invokes the "Reconfigure" command in optio~ sheet 136 which causes the reconfi~ratio~ to occur in device bar 126, the option sheet 136 to close and return to ~eady" state 146.

During a session of PC emulator operatio~ occurring after reco~figuration 20 via optior sheet 136 and/or rebooting, the user may return to "Showing Options" state 160 from "Ready" state 146, "Running" state 152 or ~Paused"
state 1~4, invoke the '~Defaults" command to return the reconfigured emulatIoII to the default parameters as originally set in property sheet 122.

25 In "Read~" state 146, physical floppy or virtual floppy media may be loaded, respectively, relative to devices at locations 126A, 126B, 126C or 126D. At this point, the PC emulator may be booted to ru~ PC applications, either ~1 , . ............. ..

:
'1;

37~

~rom the emulated fiaced disk, or from MS-DOS loaded via a virtual floppy into an emulated floppy drive, or from a physical floppy disk in physical Qoppy d~ive 25.

5 With the PC emulator booted, the emulator is in "Running" state 152. In this state, PC applicalions can be lo~ded and run via the insertion of actual floppy media iIl physical floppy drive 25 or virtual floppy media into emulated floppy drives bouIld to the PC emulator configuration, or from the emulated fixed disk.
From the "Running" state 154, the ~Pause" and "Show Options" commands are available and a floppy disk may be removed from or inserted into physical floppy drive 25 and read to.and written from. Also, a virtual floppy may be removed from or movet into an emulated floppy drive. Data may 15 also be read from and written to the emulated fi2ced disk. The l?aused"
state 1~4 may be initiated by invoking the 'l?ause" comma:nd in comma~d bar 130 of PC emulation window 124. In "Paused" state 154, all data st;ructures in the PC world are intact,~ but the operation of PC emulating processor 12 ha~ been stopped. It i~ now possible to select tea:t or graphics 20 displayed in emulation window 125 and copy the same to an opened BWS
window on desktop ~4. It is also possible to remove floppy media from an emulated floppy drive but is not possible to load such a media because the PC emulator i9 in its "Frozcn" state 1~4.

..
-`
:
,~ . . .
- , , ~ -:
:
' 3'73 I~ state 154, it i9 also possible to reconfigure the PC emulator by invoking the "Show Options" command as is in the case of "Ready" state 146 and "Runnin~ state 152.

While in 'l?aused" state 154, the command "Pause" in bar 130 is visually substituted by the command Resume" which is a visible reminder that the PC window 124 is frozen. As previously indicated, the loading of floppy media is illegal in state 154, as it could allow apparently instan~eous swapping of disks in this state such that, for e~cample, the PC emulator upon retur~ to "Running" state 162 would permit the PC emulator to seek data on one floppy and then read/write from the other which would destroy previously written data.

~cer reconfi~ration or a selection and copy ~om PC emulation screen 125 1~ ha~ been accomplished i~l "Paused" state 154, the "Resume" comma~d is invol~ed, re~ing the PC emulator to "Running" state 152 and permitting the conti~uance o~PC opera~don~ and programming.

It should be noted that the PC emulator may be booted or rebooted from ~Running" state 152 and ~Paused" state 154 and the PC emulation window may be closed in any of the states 146, 150, 162 and 164. Also the "Cancel"
command between "Show~ng Options" state 160 and state~ 146, 162 and 164 returns the user to the state from wilich option sheet 136 was invoked without applying any changes to the PC emulations.
Figure 1~ state3 may be summarized by the following set of rules:

--~3--..

. i .:: :

.
. .
. ~ , .
,; ; ' , -' , .

3~3 1. The "Close" command is always available. It cancels any changes to the option sheet, stops emulator operation in the "Running" state 152 and closes emulation window 124.

6 2. It is acceptable to eject and load media in "Ready" state 146 and "Runningn state 152. Only eject is allowed in "Paused" state 154 and ~ShowiIlg Options" state 150.

3. The "Show Optiorls" command is always available, e~ccept when 10 already i~ Showing Options" stat 150.

4. The ~boot" command is always available, e~cept when in "Showing Options" state 150.

15 5. The Cancel" command in the option sheet always returns to whichever of the other states one came from, whether the "Ready" state 146, "Ru~illg" ~tate 152 or "Paused" state 154, and simply causes option sheet 136 to disappear.

20 6. Any command that is about to discard the current boot sessioll requires confi~mation. This includes: "Close" and "Boot" while in "Running" state l5~ or "Paused'i state 154, and "Reconfigure" and "Close" while "Showing Options;' state 160 if arriving at that state from "RumLing" state 152 or "Paused" state 1~4.

7. ~ The invoking of the "Pause" command will free~e the operation of the PC emulator preventing f~ther input to PC emulation window 124. Th . . . ~ 5 4 ._ . ~ :

-.

"Pause" command changes to the "E~esume" command. When the '~Resume"comm~nd is invoked, the PC emulator commences operation at the point where it left offi~ the execution of instruction~ and input to PC emulation window 124 i3 pos~ible.
IV. Emulated lFixed Di~k (EFD~ Icon.

Reference is now made to Figure 16 which show~ desktop, 54 with emulated fi2~ed disk (EFD) ico~ 100 having been previously selected and the 10 <PE~OP7S> fimction invoked activati~g and displaying on desktop 64 emulated fixed disk property sheet 156. The emulated fixed disk repre~ented by icon 100 is in reality rese~ed or allocated ~pace on rigid disk drive 35 a~d i9 accessible from both desktop 54 and from PC emulation wintow 122 when bound to the PC co~lguration. 15P D icon 100, therefore, 15 represe~ts a pohter to that file space on drive 35. Although a user may make or have as many copies of icon 100 as desired, they will all b~ pointers to this same allocated disk space. There may be several desktop collfigurations on the same worl~statiou, only one of which may be in use at any one time, and the reser~red disk space in drive 36 for emulated fi2ed 20 disk 100 will be shared by all desktops on the same worl~statioIl. The icon may be deleted by invoking the <DELJ3TE> functioIl with confiImahon.
However, this action will have no ef~ect o~ the actual storage of any data in the PC reserved disk space on disk drive 35. After icon 100 deletion, a new EFD icon 100 can easily be ret~ieved via directory icons 60 and 62 and the 25 new icon 100 would already have a pointer to the same reserved or allocated disk drive space. The associated property sheet 156 for icon 100, when activated, would also show the partition size parameters established. Icon . . ~ .
, - . , , . ~ ~
- , -. , .-- ' ' ' . ,: .',. . .

8887~

100 may be moved or copied via <MOVE~ or <COPY> functions to a folder, file drawer or outbasket icon. However, since ieon 100 is actually a pointer to reserved memory space on disk drive 36, filing or mailing of icon 100 serves little purpo~e. The operation < OP~3N > may be invoked o~ icon 5 100 revealing an open BWS window showing its file contents on disk drive 35. The~e files may be copied to de~ktop 54 as data structures, e.g.
documents, or transferred to file drawers 8 or to media in physical floppy drive 102 via the ~COPY> or <MOVE~ function with icon 102 indicated ~s the destination of that file.
EFD property sheet 156 in Figure 16 allows the user to establish partitions i~ the reserved disk space of EFD icon 100 into four partitions as illustrated. This must be accomplished before EFD can be utilized.
Changes to the partitions can be made also when EFD has been bound to 15 location 126E in the PC emulator. The user specifies in sheet 166 the number of diik page~ to be reserved and the desired file system for each partition i~voked, for e~ample MS-DOS 3.0 or Uni~. As shown in sheet 156, only partitio~ 3 has been activated for MS-DOS and the total page size of the fi~:ed disk re~erved space of 4,080 pages has bee~ set in partition 3.
20 There must be already be a suf~lcient number of pages left on disk drive 36 tn accommodate this total reserved space.

The file system established in each partition may contain program or data files. However, the partitio~ w~ll not contain a normal boot sector nor will it 26 contain the system files to boot MS-DOS but a partition can be made bootable by running an appropriate PC uhlity.
` .
~ ~ 6 6 ..

' .. : , , .

... . . ~

The active partition of EFD icon 100 is in use when icon 100 is opened, is the recipient of an object moved or copied to icon 100 when closed, or is the partition boated by th8 PC emulator. The user can chan~e the active partitio~ in property sheet 156 since this action does not actually affect the 5 data area of the emulated fixed disk.

The ~Allow Size Change~ parameter in sheet 1~6, when activated, permits changes in partition size parameters. If this parameter is not active, the "Repar'd~on" command will not appear in the header of sheet 1~6 but 10 rather the Done" command. With "Allo~ Size Changes" invoked, the user caIl edit the parameters of sheet 156 and reconfigure the partitions.
Invoking the ~epartition" command destroys all data on the emulated fi2~ed disk and e~tablishe~ the new partitions. When repa~tition is complete, property sheet 1~6 automatically closea All data formerly on the emulated 16 figed disk is no~r lost and each partition i~ initialized with an empty, and hence nonbootable, file system of the specified type, e.g. M~DOS. It should be recalled t~at to make the EFD icon 100 accessible to the running of PC
programs, the user must select the "Fi~ed Disk [Yes] parameter in the emulator property sheet 122 or option sheet 136 prior to booting or 20 rebooting.

PC utilities are available which install bootable file systems in fixed disk par~tions of EFD icon 100. Once this has beeh done, the PC emulator will boot from the emulated fixed disk following the PC convent~on, i.e. when no 25 real or vir~ual floppy is loaded in drive 0 in location 126A and the active partitiorl of EFD ico~ 100 has been properly chosen.

a7--.... .. .

. .
:
.~' ' ' .

~L288873 As previously indicated, while the emulated fixed clisk is part of the PC
emulator configuration, attempts to open E~D icon 100, show its property sheet, or move or copy a file to EFD icon 100 will not be possible.
Conversely, an attempt to i~clude the emulated fixed disk in the PC
5 emulator's co~~ ration while EFD icon is open or displaying its property sheet 156 will not be possible. If user 18 wishes to access the contents of the emulated fised disk from desktop 54 while the PC emulation window 124 is open, it is ~eces~ary to remove the emulated fixed disk from the PC
emulator configuration via option sheet 136 in Showing Options" state 150 10 and the ~econfigure" comm&nd. Upon reconfiguration, the E}~D symbol will di~appear from tevice bar 126 and the EE D on desktop 54 may now be opened. When icon 100 is opened, as exemplified in Figure 16A, the directory Mndow 157 of EFD icon is revealed and user 18 can select a~y of the data file~ in the contain@r, move or copy them to selected designations, 15 as previously esplained, or delete the files from the container. In Figure 16A, the file "Simple.t~ct" listed at 157 has been selected iII directory window 1~ and copied to desktop 54, as show~ at highlighted document icon 1~9'.

20 V. Virtual Floppy Disk Icon.

Reference is now made to Figure 17 which shows desktop 54 with virtual floppy icon 96 having been previously selected and cPROP'S> function invoked activating and displaying on desktop 54 virtual floppy disk 25 property sheet 158. If "Allow Format Changes" ha~ not been activated, the portion 163 shown below this parameter will be visually present by cannot be changed by user 18. The virtual floppy disk represented by icon 96 (or by .. . . .. . . . .... . . . _ . . .. ~ .. . .. . . .. , . " . .. . . .

:

~ .

3L288~373 icon 98) is ill reality reserved or allocated space on rigid disk drive 3~ and is accessible ~rom both desktop 54 and from PC emulation window 122 when the disk has been inserted into a~ emulated floppy drive at, for example, locatio~ 126B (d~ive 1) in window 122. A blank virtual floppy icon 98 is 5 available via <COPY~ function from directory divider 60. l'he space on disk drive 35 allocated for virtual floppy 98 is set dynamically when the tloppy is fo~matted.

~ irtual floppy disk icon 96 or 98 can be opened, moved or copied. When a 10 virtual floppy icon container is moved to a PC emulated drive in the PC
emulation wi~dow 122, there is no virtual floppy icon representation remaining on desktop ~4, i.e., icon 98 disappears from desktop 54 and therefore ca~ot be open or selected by user 18 and can only be accessed via the PC emulator drive where it has been inserted.
lB
A virtual iloppy disk represented by icons 96 and 98 may be formatted or i~itialized either by a PC application or by a ViewPoint application.

When a virtual floppy disk icon is opened, the listing of files is revealed and 20 the file~ in this container may be moved or copied to other similar PC
containers or to desktop 54 as a data st~cture, e.g. a document icon similar to copying files from a real floppy disk in physical floppy disk drive 25.
Other files compatible with MS-DOS may be copied into a virtual floppy disk icon container. Figure 17B shows the directory window 165 for Xerox 25 DOS 3.10 virtual floppy icon 96 opened via the < OPEN > function showing the list of files on this particular disk~

'~
:
.
' ' ` :
- ~ , ': .

, ~

~LZ~38873 When a vir~ual floppy disk icon is on desktop 64, it behaves like a data structure container, such as a file folder icon, allowing user 18 to select data objectj from within its open window. l~us, in Figure 17B, a Listed file can be selected and moved or copied from the directory to desktop 54. Moving or copyiIlg this icon is like moving or copying a folder in that the data within the container and present on ~he system main disk d~ive 3~ is drectly affected, and deleting a virtual floppy disk icon causes all of its contained files to be deleted from disk drive 35.

10 The content~ of a virtual floppy disk icon container may be moved or copied to the appropriate parl;ition of EFD iccn container 100 when the latter is o~
desktop ~4 and not bound to the PC configuration. A virtual floppy disk icon or its individual contents may be moved or copied to any ViewPoint contai~er, including a NS sl;ructured floppy disk present iIl physical floppy 15 drive 25, like any other data object~ with its content, on desktop 54 (e.g.
document icorl containers 64 and file folder container 68) mzy be copied to a floppy disk present in drive 25. Conventional PC commands may be employed to perform a compl~te bit for bit copy of a file from a virtual floppy disk inserted in an emulated driv~ in device bar 126 to a physi- al floppy 20 present in drive 25 bound to the PC emulator via physical floppy drive icon 102. On the other hand, a file in a virtual ~loppy disk icon container, formatted for MS-DOS, on desktop 54 may be opened and the file transferred to a physical floppy, formatted for MS-DOS, present in physi~al floppy drive 25 via the <MOVE~ or ~COPY> function to the opened 25 window of physical floppy drive icorl container 102. Also, one may move and copy files from a Xerox (ViewPoint) fo~matted physical iloppy i:n drive 2~ to an MS-DOS virtual floppy, or` from an MS-DOS physical floppy to a .
. . .
: .

.

~lZ8~38'73 ViewPoint ~1irtual floppy, since both kinds of media, here, are formattable in a way that is recognizable to the current sg~stem state. More on format compatability and file e~tension determination will be said later.

Virtual floppy disk property sheet 158 in Figure 17 allows user 18 to change tha icon label (title) or to change to another available file system other than,for example, MS-DOS, such as UN~. The parameters include its density, the mamber of sectors and tracLcs, file system and whether it is write protected. The ~umber of available pages on a particular virtual disk is the same volume allocated space on disk drive 35 so that the space allocated to a virtual floppy disk i~ the same, whether this container is empty or contains ma~y data files.

The "Reread" comrnand in the header of sheet 158 initiates an attempt to i~terpret the conte~ts of the virtual iloppy using the specified file system. Ifthi~. interpretation i~ successful, the bottom portion 163, ~Tirtual Disk" of sheet 158 below line 161 will disappear and then reappear as shown in Figure 17A with file system specific parameters showll as originally initialized including an indication of available remaining space and whether the vir1;ual floppy disl{ is a system disk or ~ot~ The information sho~ in bottom portion 163 or 163A may be different for other file systems such as, e.g., UNIX.

Activating "Allow Format Cha~ges" in property sheet 1~8 shown in Figure 17A makes the bottom portion 163 of the sheet shown below line 161 appear, replacing hottom portion 163A if present.

.

~, : - -- -- ... .. .
. ~ . : , . .

, ~

., ~ ': , , When the virtual floppy icon properties are first displayed, or when the command "Reread" i9 invoked, it is possible that the file system actually on the ~irtual ~loppy will not match the icon properties. This will always be the case for a virtual floppy icon freshly copied from a directory 60, or 62. In- 6 this situation, Allow Format Change3" will be automatically invoked to pe~nit the user to format the virtual floppy. The invoking of the command "Format" in the header of property sheet 158 causes the virtual disk to be reformatted according to the specific parameters changed in the bottom portdon 163 of the sheet, provided that the '~Vrite Protect" option in sheet 10 158 is deactivated. Also, activating '~7Vrite Protect" prevents the PC
emulator from writing on the virtual floppy disk, though it may still reach from the floppy disk.

If the virtual disk icon has been previously formatted, reformatting via the 15 "Fo~mat" command requires e~cplicit confirmation, via a prompt in header ~6, because this action will de~roy any data stored on the disk. ~Iost system 14 allocates enough disk space at drive 3~ to accommodate the reque~ted format for a double sided, double density disk of nine (9) sectors per track. This amounts to 720 pages of data, plus 14 pages of system 20 overhead. Ii~there is not e~ough system disk space, user 18 can try again by either first proceeding with a smaller format configuration or take action to increase available disk space in drive 3~.

- Table lI shows the amount of disk space required by the various possible 2~ disk fo~mats.

.

, 2~ 373 Table 11 Sid~s Sectors/track Pages Requlred ,, . ___ . - . .=
~ 8 374 Once formatted via property sheet 158, virtual floppy ico~ containers may contain any PC program or data files but do ~ot co~tain an M~DOS boot record or system files and, therefore, cannot be used to boot the PC
10 emulator. Virtual floppy containers intended for such use should be fonnatted and initialized usingPC utilities.

I~ the header of virtual floppy property sheet 1~8, the "Defaults" command ~ets the parameters invoked in the bottom portion 163 of the sheet as 15 follows: ~llow Format changes" set to o~, "Volume Label" beromes blank, '5Density" is "[double]" ant "Sides" is "~Two] and "Sector~JTrack" is "~9]".

A~ previously indicated, user 18 loads a virtual iloppy disk ico~, such as floppy disk icon 96 or 98, by moving the icon, via selection with mouse point 20 button 31 and the cMOVl3> function, to any emulated drive symbol ( locations 126A-126D) i~ deviee bar 126 of PC emulation window 122. This action makes data files and pro~ams in the floppy disk icon container accessible to run-time PC programs that e~pect to read aIld write to the specified emulated dri~Te. While the floppy disk is in the emulated floppy 25 drive, the PC emulator's specified file system format may be changed via a PC program.or utility so t-hat the file system specified in the floppy disk .~ 63 :

: ' ~, ~aZ~8873 icon's property sheet 158 may not match the file system actually recorded on the virtual floppy disk.

A PC program that formats floppies may fail for virtual floppies if the 5 program fo~nats larger-than-usual tracks and there are not a suf~icient number of rigid disk pages available.

User 18 may remove or "eject" a virtual disk floppy from a:n emulated disk drive by clicking the mouse point button 31 over the emulated disk drive 10 symbol and cursor 52 will revert to virtual floppy disk symbol 98'. The user may the~ by moving mouse 27 correspondingly move symbol 98' to an acceptable desktop destination, such a~ an open desktop space or a file folder ico~ on desktop 54, ant drop the virtual floppy disk icon by clic~ing agai~ either mouse point button 31 or adjust button 33. With the virtual 15 floppy icon o~ desktop 54, the contents of the floppy disk icon can be acce~ed from desktop 54 via the <OPEN~ and ~COPY3 or <MOVE~
fu~ction as previously explained.

Reference is llOW made to the flowchart in Figure 24 concerning the 20 configuration and initializatio~ of virtual floppy icon when bound to the PC
emulator. In this flowchart, as well a~ flowcharts of later described figures, the small boxes in the upper left hand corner of the larger operational boxes denote by a letter in the bo~c the action being taken by host system 14, PC
emulating processor 12 or user input. Thus, the inclusion of bo~ like that 25 below denotes a host system,ViewPoint action:

, ~ . .
, : ~
,~, 3L~88~373 The box below denotes a PC emulator action:

The bo~ denotes an operator or u~er input action:

icated at box 330, the user 18 may obtain a virtual floppy icon by opening a ViewPoint directory divider, such as directory divider icon 60, that include object~ used for PC emulation. ~Ia~ing opening this divider, 16 user 18 may select any of the objects for PC emulation out of the divider by invoking the c(: OP~> f~ction, one of tho~e objects being virtual floppy ico~ 98, a~d trans~erring the copied object to desktop 54, as already shown for example relative to floppy icon 98 i~ Figure 6. User 18 configures the PC to include at least one emulated 1Oppy ~ve, then open~ PC emulation 20 window 124, as per box 332. A~ indicated at box 334, the PC window 124 appears with the emulated iloppy drive 9~01s in the device bar 126. User 18 may~ then place a MS-DOS system disk into physical floppy driv0 25 and select the "Boot" command in header bar 130 to boot the PC emulator.
These~operations are indicated at box 336 in Figure 24. The PC emulator 25 would~ display the initiaI message and cursor prompt after having been ~ooted, a~ per bo~ 338, and user 18 may then select virtual floppy icon 98, as indicated~selected at ~8' in Figure l0, and move this floppy via small floppy :: ` : ~ ` :

~88~3 icon cursor 98' to the emulated floppy drive sllch as at location 126B as per bo2 340. The *opping of the miniature ico~ 98' on the drive at location 12613 will cause the display at location 12~B of the ico~ label for the particular virtual floppy so installed. This action also sets low level 5 microcode routing of floppy VO requests to the sof'cware emulator for the emulated floppy disk drive at location 126B. These functions are all sequentially indicatsd via bo~es 342 through 344.

At this point user 18 will want to run a MS-DOS utility to format the 10 virtual floppy disk inserted into a3l emulated floppy drive, as indicated at box 346. As a result, host system 14 will allocate file spac~ on rigid disk drive 36 for virtual iloppy 98 as indicated at bo2 348. Also, emulating processor 12 will isslle VO requests to provide format each tracl~ of the virtual floppy for the sele~ted MS-DOS filing system and verify the same 15 aIld ho~t system 14 will il~itialize internal data structures for virtual floppy 98. These functions are carried out respectively by PC emulating processor 12 ant host system 14 per bo~es 350 and 352 in Figure 24. There is on initialization, a list of the location of the tracks for each sector a3ld for each track a pointer to each page o~ which a par~cular sector/track will reside 20 and sector identification and size.

Vl. Ph y~ical Floppy Drive Icon.

Reference is now made to Figure 18 which shows desktop 54 with physical 25 floppy drive icon 102 having been previously selected and the <PROP'S>
function invoked activating and displaying on desktop ~4 physical floppy drive propert~ sheet 162. Icon 102 is available from directory 60 and . . . : . . 6 6 .

. ~ , ~LZ8~3873 represents, via its data struc~re as a ViewPoint application, the physical flopp~ drive 25 of host system 14. User 18 may have or make as ma~y copies of icon 102 as desired, but each such icon is a pointer to the same physical floppy drive 25. The deleting of icon 102 via the ~DEL~1~13>
5 func~io~ has no effect o~ any data because the icon is a pointer to drive 25.
IcoIl 102 may be moved or copied to a folder or file drawer containeI or to an outbasket, although such a~ action has no ef~ect on data contained on any physical floppy disk.

10 Floppy drive icon 102 may be opened via the <OPEN> function, revealing the contents of an actual physical disk currently ill drive 25. Figure 18B
displays such a file co~tent in directory window 167 for an actual disk present in drive 25. User 18 may move or copy data file~ and icon objeets to or from floppy drive icon 102 in the same malmer as a file drawer icon 80.
15 In figure 18B, the file Diskcopy.com" has been shown selected as highlighted at 169 and may be copied or moved to desktop 54 via eith~r the <COPY~ or <MOVE> function.

Host system 14 ~upports different file systems present on iloppy disks, two 20 of which are e~emplified in property sheet 162: the file systems of Xero~ andMS-DOS. The user caIl select the file system e~pected to be read or written by selecti~g either "[Xerox]" or "[MS-DOS]". The preferred mode of oper~tion is that the user have more than one copy of floppy drive icon 102 present on desktop 54 and set the properties of each ico~ to a particular and 25 dif~erent file system.

~. .

' - . . .
- , ~L2~

A "Reread" command will appear upon invoking the popup menu at triple line symbol 164 in a manner previously e~cplained. Invoking this command will cause an attempt to interpret the parameter3 of an actnal floppy-disk present in drive 25. The invoking of this command would be usually done after changi~g the file system parameter or after replacing the floppy disk i~ dri~e 25 with a different disk.

Parameters specific to a particular fle system occupy the bottom portion 166 of property sheet 162. In the case of Figure 18, the parameters for the 10 Xero~c file system are shown. VVhen user 18 selects "Allow Format Changes", the parameters displayed ill portion 166 may be edited and the "Format" commarld appears in the header of sheet 162 in place of the "Done" command. The "For~nat" command fo~nat3 and initializes the disk as set by the user in sheet portion 166, after which the "Done" reappears in 15 the header of sheet 162 and Allow Format changes" i~ dehighlighted or deactivated. At this point, the parameters in bottom portion 166 again cannot be edited. The user caIl place new phy~ical floppies in drive 25 to bnng about forma~ing cha~ges in the malmer just e~cplained. Invoking either the Done" command or the Cancel" command will remove physical 20 floppy disk property sheet 162 from view.

Figure 18A shows physical floppy disk property sheet 162 when the user specifies the "[MS-DOS]" file system. All the commands previously e2~plained-in connection with Figure 18 are the same here. As previously 25 indicated, Figure 1~B shows a~ esample of the file content of an actual floppy formatted to MS-DOS in disk drive 25 and when a floppy disk Icon 102 is selected and the <OPEN> function is invoked. Window 168 will .. . . ~ . ..

. ' . .

- , . . , :
- .

, 1~88873 open if the actual iloppy disk is a properly formatted MS-D()S. Hidden files, system files, a~d subdirectories ~ot belonging to the top level directory wiil not appear in window 168. Eowever, a user may open aIl MS-DOS file ide~tified a~ a subdirectory, CDIR>~, by selecting it with mouse point 5 button 31 and invoking the <OPEN> functioa, at which point the subdirectory content3 will be shown i~ window 168. In Figure 18B, the file "Diskcopy.com" is show~ selected (highlighted).

MS-DO~3 files, such as those shown in wi~dow 168 except for subdirectories, 10 may be moved or copied to ViewPoint containeIs, such as a folder icon or to desktop 54 as a data structure icon, e.g. a document ico~. A ViewPoint name will be invoked a~d appear in the format: [NAME.EXTFNSION].
Also an NS file type will be dete~mined and other at~ributes will be set to default values.
MS-DOS file~ may also be moved or copied to other MS-DOS icon co~tainers, such a~ MS-DOS formatted virtual iloppy disks 98 or the emulated fi2ced disk icon 100. All directory i:nformation of the transferred file ~ill be t~raIlsferred too.
Figure 18C shows PC emulation window 124 opened and configured to include physical floppy drive 25 at location 126A with a MS-DOS command "DIR" having been accomplished to show the the directory 167' of the di.,k in drive 25 which is ~A~ drive, and which i5 the same disk and disk directory 25 shown ill Figure 18B but being accessed now via PC emulatioll window 124.
As previously indicated ill Figure 18B, the "Diskcopy.com" shown in screen 125 has been selected (highlighted) at 169'. Thus, the file directory and ~lles .. .. .. , .. _ .. , . .. _ _ , . . ... ... . . . _ .. . . . .. ... .. _ .. . . .... . .

. , ' .' : ; .: ,., '; . ' :

: , - , , : . .
.
.

~288873 in the directory of a physical floppy in drive 25 may be acces~ed in the ViewPoint world or in the PC world.

An impor~t point is that when physical floppy drive icon 102 is assigned 5 or comqgured to the PC emulator, it is inaccessible from desktop 64 and the only way to access the data on a physical floppy in drive 2~ is via PC
utilities to perform a transfer of data, including a transfer of a file or PC
di~play screen data to the Vie~rPoint world.

10 VII. MS"I)OS and ViewPoint File Names and Type.

Table m below sllmmarize~ the foregoing MS-DOS window operations.

Table 111 __ _ Destination Container Source Object. _ - . ViewPolnt (VP~
EWiUnlaorContainer (including None _ _ MS~DOS File MOVE/COPY MOVE/COPY DELETE, PROP'S
MS~DOS DirectoryNOTALLOWEDNOTALLOWED DELETE,OPEN,PROP'S
VP non-~ontainerMOVEICOPY MOVE/COPY DELETE, OPEN, PROP'S
_ .. -vP container NOT,~LLO~IVE-- ~ ~J~ DELETE, OPEN, PROP'S

A specific set of ViewPoint object~ can be moved or ropied to a~ opened vlrtual floppy window or to its closed icon on desktop ~4. When the physical floppy drive is configured and in use by the PC emulator, its icon on desktop 54 ca~not be opened. Deletion of physical floppy drive icon 102 ~n desktop -~- . .. _.~ . .... . _ ----70----: ~

. . . ' ~, . . .
' ~ ' ' '` `.

~iLZ8~38~3 64 has no effect on the symbol at location 126A in device bar 126. If user 18 wishes to make physical floppy drive 25 accessible to PC programs, of course its corresponding icon 102 must be included in the PC emulator's disk configuration via its property iheet 122 or option sheet 136. If user 18 5 wishes to access a disk in physical floppy drive 25 from desktop 54 rather than firom the PC emulator while the PC emulation window 124 is open, it is r~ecessary to remove the floppy drive ico~ 102 from the PC emulator's co:llfiguration via Opti3Il sheet 136 and invoke the "Reconfigure" command.

10 When moving data files back and ~orth between the ViewPoint world and the M~DOS world, it is useful to preserve as much information as possible in the interpretatio3l of the contents of a file. Irl ViewPoint files, the file system stores this information along with the file as a "file type" which manifests itself to user 18 as an icon picture. MS-DOS keeps track of this 16 informat ion using a file name e~ctension. For example, an application may, by convention, give all loadable biIlary programs the e~ctensio~ "COM", all ASClI files the e2~tension '~T" and all Interpress masters the ea:tension D?n. The rules to follow for file rlame eollversion and keepi~g within the conventions of the the target filing system are as follows:
1. Never create a file name which i8 illegal in the targetfile system.

2. ~Iake the name as similar as possible to source name.

25 3. For a specified list of situations, force the extension to match the file type and vice versa.

..

, "

..
. .

A ViewPoint system data file, for example on desktop 54 in the MS-DOS
system, will c~Ty the following e~tensions. If the ViewPoi:nt file type is ASC~l, it~ MS-DOS e2tension i8 "TXT". If it is a word processor file originally created on the 860 word processor, its MS-Dt:)S e~tension is 6 860. I~the ViewPoint file is an Interpress master, its e~tension is ~n.

When transferring a file from MS-DOS file system to the ViewPoint file system, the file name is passed verbatim, and the file type is set as e~emplified in Table Iv below. If the MS-DOS e2tension matches a table 10 entry file type shown i~ Table Iv, it gets that file type, otherwise the file type is set to a specific value that means "unspecified".

When transfemng a file from the ViewPoint file system to the MS-DOS file system, a long file name must be compressed. The compression, for 15 esample, may be an eight-character ~ame a~d a three-character e`xtension as allowed in the PC filing systems. Ez~amples of f~le type compressed name conversions are illu~t~ated in Table Iv. The procedure for compression is as follows. Take the leading characters u~til either (1) eight legal characters have been accumulated or (2) a period (.) i~ encountered for the MS-DOS
20 file name and MS-DOS extension is taken as per Table Iv.

The system also recognizes one file type not found in Table I~, i.e. the special or~e meaning "unspecified". I~ this situation, the name and e~tension are formed as follows. St~ing at the far end of the ViewPoint 2~ file name, a scan is made backwards until a period (.) is encountered. At - this encounter, the three characters to the right of the period are taken as the file extension. For the MS-DOS file name, the leading characters of the . .. ... . .. ... . . . . .. _ . _. . : .. ... .. . ... .. . . . . . .
- . . .,, :. ~ . - ,, : .
.
: .
1~,, ' ' .

, :

Table IV

NS Name NS Flle Type N3l-~e Exte-lslon HowToGoPupless.ip Interpress HowToGoP ip HowToGoPupless Interpress HowToGoP ip H~wToGoPu pless I nterpress }IowToGoP ip (interpress) Gary's.Template Unspecified Gary ' s Tem XW5 ASCII XWS t~et PRMODEL1 .DIF Unspecified PRMODELl DIF
PRMODEL1 DIF Unspecified PRMODELl DIF
PRMODEL1xDlF Unspecified PRMODEI.l xl: I
name.with .twoperiods U nspecified namewi th two name.with .tNoperiods 860 name 86 0 Document Has ~ ]Illegalchars.*X 860 ~asIlleg X
Document FS/ESCN Template ViewPoint (ill~ al file Document P~

file name are taken until either (1) eight legal characters haYe accumulated or ~2) the same period (.) that delineated the e~tensioll is encountered. I~
the situations where a ViewPoint filename contains no period, the first 20 eleven characters are taken, the first eight beiIIg taken as the filename andthe last three as the ea:tensio~. See Table Iv and file name collversions for PRMODEL1 DIF and PRMODEL1 xDlF as an e2amples of this selectio~.

Table V below summarizes error conditio~s and handling. 'q?S" means 25 "propertv sheet" 2nd "OS" means "option sheet". The host system will report disk erTors with the most accurate message possible based on the status retur~ed from the operating system. Categories of erro~s are (1) the ..
- ~ . ~ .:

... , .. ~
. ~ ,~ ,,, i , , ~, .

disk is physically unreadable, (2) the required implementation has not been loaded alld (3) a specified file system implementation cannot recog~ize the format of a disk.
.
Tabl~ V
~ ~ _ . _ Oper:tion PROP'S OPEN MOVE/COPY to __ ~
SpecifiQd file system PS appearswish bottom Window opens & displays Selected ViewPoint object implementatlon section properly filled in. contents. transferred if legal to recogni~es format of disk do so.
(i.e. no error) .
SprJcified implementation PS appearswith bottom Mess3ge ~Specified file Operation cancelled, not loaded section blank. available system application not message "Specified file choices plusthe highlighted laaded~ in System Attention system application not unavailable one are Window. loaded'' in System displayad; message Attention Window.
~Specified file system application not loaded~ in System Attention Window.
. . . _ _ .
Specified fil~ syst~m PS appears with boetom OS appears; message ~File Operation cancelled, implementation cannot section blank; messag~ ''File system on disk doesn't match message ~ File sy*em on recognize format of disk system on disk doesn't match icon~ in System Attention disk doesn't match iconN
icon' in System Attention Window; user can change filo in System Attention Window. User can chang~ file systarn or disk and press Window.
. sy*em or disk and presi IR~ ~Startl or eise ICance Read]. User can aiso saiect ALEOW FORMAT CHANGESl, .
in which case bottom section of PS appears. fiiled in with defauitvaiues. . _ VIII. Flowchart Exemplication of PC Emulator Configu~ation a~d Reconfiguration.

Reference is now made to the flowchart in Figure 19 for explanation of configuration of the P~ emulator via prope~ty sheet 122 and the flowchart .. ... _ _ . . . .. _ .. ~ _ ... _ , . .... .. ...... . . . .. . . .

: ., ~ , . -. .

,,, ;
:, ., ~ ,. .. ...
., , . : . :
.~ . .
. ~ , , :

lZ~38873 in Figure 20 for explanation of reconfiguration of the PC emulator via option sheet 136. Ag previously indicated relative to these flowcharts, the ~' boa~ notation de~otes a host system (ViewPoint~ action, the ~P" box notation denotes a PC emulator actio~ a~d the "O" bo2c notation denotes an 5 operator or user ac1;ion.

To configure the PC emulator via property ~heet 122, user 18, indicated at box 170, selects PC emulator icon 94 and invokes the <PROP'S>
comma~d.
IJpon in~oking of the ~PROP'S> command, property sheet 122 will appear, as indicated by box 172. At this point, user 18 may edit property sheet 122 to reflect the desired device configuration, as indicated in box 174.
After the selection of the desired configuration has been accomplished, user 15 18 carl either select the Cancel command in the heater of property sheet 122 or the Done" command. If cancel is invoked at 176, line 178 is followed: the proper1;y sheet 122 is clo~ed and the PC emulator icon is left in its highlightet state as shown in Figure 6 at 94'. If "Donen i5 invoked at !l76, the new co~figuration selected by the user will be invoked as per line 20 180 to box 182. As indicated by bo~: 182, the new configuration information i~ permaIlently stored for icon g4 and the parameters as set represent the default condi~ons ~or the coIlfigured PC emulator of this particnlar PC
emulator icon.
-25 At the game time that the new configuration is permanently stored,property sheet 122 closes as indicated by box 184. As indicated by box 186, the next function is a user action which calls for selection of PC emulator . .. . . .... .. . . . . ; . .. , . . ~ . ...... . . . . ..... ... ..

.. :; .

.

38'73 icon 9d~ and invoking the < OPEN ~ function. As indicated at decision 188, options-while!-opening sheet 135 (Figure 12A) is displayed if "Display Options" had been chosen in property sheet 122. If this choice has not been elected in property sheet 122, a decision pa'ch via line 192 is to box 210 with 5 the ViewPoint applicalion for the PC emulation window 124 being opened as previously configured~ ~Iowever, if this display option for sheet 135 has bee~ invoked, the decision path via line 190 is taken, and the option sheet 135 will be displayed as indicated in box 194. At this point, user 18 may edit option sheet 135 to ref~ect a desired change in configuration as 10 inticated in bo2~ 196. After accomplishing any desired changes in the previously set configuration, the user must select either the Cancel"
command or the "Start" command in the header of option sheet 136. If in making decision 198, the user invokes the "Cancel" command per line 200, option she~t 135 will close per box 202 and the PC emulation window 124 15 will rlot ope~. The return path is Yia line 204 which is back to the point of bos 186 permitting the user again to select the PC emulator icon 94 and invoke the <OPEN> filnction if ~o desired. On the other hand, if user 18 has iD.voked the 5tart'9 command, the path of operation is via line 206 to bo~c 208 wherein the chaIlges in parameters made via option sheet 136 are 20 applied directly to the current session and the PC emulation window 124 will open confgured as specified via option sheet 136. It is of interest to note at this point that when the current session of the PC emulator is terminated via the "Close" command, the changes made to a~y parameters via option sheet 13G will be discarded and the default set of parameters 25 originally configured at box 1~2 and permanently stored with the configured icon 941 will be restored. Upon invoking the < OP:EN > function .

.- . ~ .
. , ~ -, - .
~. . ... .

.

.

again via bo~ 186, the PC emulator will be configured as indicated at bo~
18~.

The flowchart in P'igure 20 represents the choices for reconfig~ration when PC emulation window 124 has opened. In this connection, bo~c 212, in essence, r2presents all the actions carried out via the entire flowchart shown ill Figure lg up to and including box 210 wherein the PC emulator window opens, configured as specified Yia either property sheet 122 or option sheet 136. In order for PC emulation to take place, it is necessary to boot the system. This booting can take place via a PC utility file for booting present as a virtual floppy ill ~n emulated floppy disk drive or via the emulated ff2zed disk, or from a physical floppy disk in drive 26.

Boa~ 214 in Figure 2 illustrates booting of the system via a PC operating system present on a physical di~k placet in the physical floppy disk drive 2~
which ha~ been bount to the PC emulator configuration. At this point the user next click~ mouse point butto~ 31 to select the Boot" command in header bar 130 of the PC emulatio~ window 124. At this point, the PC
emulator will di~play the initial message on screen 125 indicating to the user the booting of the system as well as revealing a proprietary notice for that particular operating system. This is indicated by box 218 in Figure 20.

It should be noted that if the "After Openi~g Window [Boot PC]" option has bee~ selected, the box 214 action would actually precede the box 212 action in Figure 20. ~Booting from a virtual floppy in this case is not possible .. .. , . .... ~ .. . , .. . . ,. _, ... . ... . ..... . ......
- ~ , - , . .

~ ' ~ ' ' ' ;` ' - ' ' :' ., ` . . .
.:
.

because the virtual floppy disk can be moved into an emulated drive, which can~ot be done until after PC emulatio~ window 124 has bee~ opened.

At this point in operation, user 18 may ru~l any desired PC program on the 5 booted system, although thi3 is not necessary or may be considered optional as indicated at bo2~ 220. User 18 alsn at t~is time may click in header bar 130 the Show Options" command a~ indicated by box 222. The invoking of this comma~d will display the PC option sheet 136 as indicated at box 224.
As previously explained in connection with Figure 19, and as indicated in 10 connecl~on with bo2c 226, user 18 may edit optioIl sheet 136 to make changes to the PC emulatnr configuration. In other words, the function of the user at bo~ 226 is the same as the functioIl of the user at box 196 in Figure 19, the difference bei~g that at bo~ 226, the PC emulator has already been booted a~d at bos 196 the PC emulator has ~ot been booted. The same is l~ue in 15 connec~o~ with decision 227 which is essentially the same as decision 198 in Figure 13 e~:cept t~s time the choices are "C~ncel" or ~econfigure"
instead of"Callcel" a~d Start. This reminds user 18 that the PC emulator has already bee~ configured and started. ~I;er changes have been made to the PC emulator confi~ ration, user 18 is left to select, via the command 20 header in option sheet 136, either the "Cancel" command or the ~econfigure" command. If the user selects the "Reconfigure" commarld via line 228, the system will request a confirmation from the user in message subwindow 128, as indicated in box 232. If user 18 at this point confirms at decision 234 the changes to the configllration, operation of the PC emulator 25 is halted via line 236, as indicated by box 238, i~ order that the configuration changes can be made via host system 14. After the configuration changes have been accomplished as per changes in option ' . .
, .. .

,: ~ ' ' ,' '; . ` , , , , . , , .
: ' ~. ~ . ' . .
. . .
, .. ,, , . "

~L~8~3873 sheet 1~6, the she~t will close and the PC emulation window device bar 126 will show the new con~lguration. At this point, the flowpath ~ria line 2~2 is such that the user may continue a session by again ;~voking the "Boot"
command in the commant header 130 of window 124 ant run a desired PC
program as previously indicated in connection with box 220.

Ig should be noted that prior to booting, user 18 may select "Show Options"
via line 215, reconfigure the PC emulator via line 228, which then would not require a co~lrmation, since the PC emulator has not been booted and 10 the Halts action at bo~ 238 is inappropriate. This is noted relative to dotted bypass line 237 which returns user 18 to a state for booting the PC emulator at bo~c 216.

Reverting again back to the operation co~lrmation via decision 234, if user 15 18 ha~ confirmed a "No" decision at this point, user 18 has the option of either "Cancel" command or the "Reconfigure" command. As indicated via the Cancel" command at line 230 in Figure 20, option sheet 136 will disappear and the previously set configuration as per box 2i2 will remain unchanged, as indicated by box 244. As a result, any program that had been 20 running as optionally selected by user 18 via boa: 220 will continue to run unmolested as indicated at box 246 and user 18 can continue the current selection and make use of a running PC program as previously indicated at box 220.

. .. , ..... ., . ,.. , . ... , . ... ~ .. 79. :~ .. ... .. .. .

, '.
,' ''.~ '~

~L2~38~73 I~. Data Trans~er Between PC World ancl ~iewPoi~t World.

Reference i9 now made to the several techniques in which information may be t~sferred betwee~ the PC emulation window 124 and a ViewPoint application such as a BWS window of a ViewPoint document. While it is po~ible to tr~sfer te~ from a BWS window to another BWS window on desktop 64, the transfer of text relative to PC emulation window 124 represents somethi~g dif~erent in tha~ the te~t transferred is being handed from thew control of one system over to ths control of another system via a 10 user interface shared by both systems.

Figures 21A and 21B relate to a first data transfer techni~ue for the transfer of data betl,veerl PC emulation window 124 a~d ViewPoint applications on desktop 54. Input of data, such as te2~t, to PC applications is 15 limited to ~hatever call be ~rped" either directly by user 18 or by copying strings of text and converting the test strings into simulated PC keystrokes.
The characteristics of the particular characters transfelTed from one system to another, such as the character font, 8ize, etc., are ignored during such a copy or move transfer. The user selects the te:ct to be copied from a BWS
20 window, invokes the <COPY> function, moves the copg~ cursor to a point anywhere in the PC emulation wintow 124 and ~en clicks the mouse point button 31. Text characters will be copied into the emulation window lZ4 fIom the BWS window in a manner as if the user had actually input the same text string via the corresponding key~ on keyboard 29. The particular 25 location clicl~ed within the PC emulation window 124 to transfer text to thiswindow is immaterial since the PC program that is in operation during such a transfer will have control over the contents of the PC d~play screen. The .. ... ..... . .... . . . ... . . ..... . . .... . .

.
.
.
;

.
. . ~ , .

12~38~3~3 character conver~.ion will be as per Table I previously set forth. Character~.
not valid Oll the IBM PC will be translated to the sequence AltDown 177 AltUp, which the PC interprets. as ASCII B116, which i~ a half-grey rectangle meaning that the character i~ not interpretable. The ~MOVE >
5 command is handled in the same manner as a <COPY~ command ea~cept that the source selectio~ will be deleted. ~Iowever, a <MO~IE > comrnand cannot be invoked relative to the transfer of te~ from the PC emulation 124 to desl~top BWS window.

10 Referring now to Figure 21A, the operations relative to bo~es 252-254 are synonymous with the operation~ relative to the sequence of boxes 212 throngh 220 in Figure 20. As indicated by box 250, the PC emulator window 124 has been opened and the system booted so that tne display now reveals the initial display message a~d proprietary notice, as indicated in 15 box 252. II1 this colmection, s~e Figure 22A wherein PC display s~reen 125 c.hows an e~ample of such initial mes~agea At th;s point, user 18 may have entered th appropriate MS-DOS commands to run the chosen PC
application program per bo~c 254, although this i~ not necessary for the transfer of data to screen 125. Tran~ferring te~ct to a 'ViewPoint te~t 20 location is illustrated beginning a~ bo~ 258, where user 18 ha~ opened a data icon, such as document icon 64B, and prepared it for editing by i~voking the command "Edit". At thi point, as illustrated at bog 260 in Figure 21A, user 18 may enter keyst~okes to the running PC program in PC
emulator screen 125, or select te2t in a ViewPoint window and transfer it 25 via <MOVE~ or <COPY> to the PC emulator screen 125, or use the 'q?ause" command to halt the PC program and select te~t from PC emulator , , ', :

' ~L2~ 373 screen 12~ for transfer via CCOPY > to a ViewPoint text destination, such as window 104 in Figure 22A.

In order to invoke the function of typing to the PC display screen 125, user 18 clicks the mouse point button 31 in the area of PC emulator window 124.
Thi~ action is indicated at li~e 262 in Figure 21A. The ensuing keystrokes from keyboard 29 inputted by user 18 will be routed to the PC emulator processor 12, as indicated at box 268, with keystrokes interpreted as per Table I. Appropriate ~eying in of commands and data can be continued by 10 the operator as per box 270. As a result, the text inputted by user 18 will, typically, be displayed i~ the screen area 125 of the PC emulation window 124. The inputt;ing of te:~t will conti~ue a~ noted in connection with decision 276 ~ia affirmation o~ e 278, ~ince the input focus for text has been iI~itiated previously by the action of user 18 in initially clicking the 15 mouse poiDt button 31 within the PC emulatio~ wintow 124. If at this point (deci~io~ 276), there is no more text intended for the PC emulator screen 125, as indicat d at li~e 280, user 18 may take an alternative course of actior~ of either (1) selecting with mouse point butto~ 31 some other point Oll desktop 54 or (2) selecting the "Pause command in command bar 130 of 20 PC emulation window 124, freezi~g further operation of the PC emulator and turning the input focus of PC display screen 125 over to the control of host system 14. These two alternatives just expressed are, respectively, user actions via lines 264 and 266.

25 For the transfer of te2ct from a ~iewpoint application to PC scree~ 125, user18 selects with mouse point button 31 some other ViewPoint application and a text stri~g a c that selected application per line 264 for the purposes of .. . .... . .. . . . .... , . .. . , . _ ~ . . . , .. ~ .. . ... . .... . .. . .. .. . . .
: . ,; ~ .
. : ~ , ' '' ' ,' ' ' ' ~ , , : - . : . . : , .
: . , , ;
: . ..
:

copying this text from the application into screen 125. This selection of text to be coped to screen 125 is indicated at 183 in Figure 22A, shown highlighted with the use of mouse buttons 31 and 33 in a manner as previously e2cplained. 'l'he ne~t fimction performed by user 18 i~ to invoke 5 the <COPY~ function on the te~t selected in a ViewPoint application, ~uch a~ an open ViewPoint documellt. After selecting the te~t a~d invoking the copy function, user 18 then moves the mouse cursor 52 within the boundary of screen 125 and clicks mouse point button 31, as indicated at box 282. ~3ee PC cursor at la1. T~is ac~on will cause the transfer of the 10 selected text from the ViewPoint application into the screen area 125. As indicated by box 284, the selected te~t from ~indow 104 is converted to I~M
scan codes as per Table I, as previously described, and these keystroke conversion~ are passed to PC option board 30 via its keyboard input. The a~ual ma~ner in which this coIl~Ter~ion to mM scaIl codes and operation via 1~ PC board 30 and the handling of the display of these characters as per line 286 for te2ctual output display in the PC emula~on window screen area 125 are accomplished via ViewPoint ~application so~tware. During the transfer opera~ion, message subwindow 128 i~dicates to user 18 that the transfer is taking place with the message, Copying text to PC window". The tl ansfer 20 of selected text at 183 in window 104 to screen 125 is completed a~ shown in Figure 22B at 185 and its completion is acknowledged to user 18 via message subwindow 128 and the message "Done".

For the transfer of te~t from the PC emulation window screen area 125 to a 25 ViewPoint application, the path via line 266 is followed in Figure 21A. In this connection, reference is made to Figure 23A wherein there is shown PC
emulation window 124 having text in display screen 125 relating to "A

8 ~----.

, . . . ..

Story of ViewPoint". Also, present on desktop 54 is an opened and empty document window 187 with a title, 'A Story of ViewPoint".

The appropriate user actioIl, indicated at box 260, i3 the selection of the "Pause" command in command bar 130 of PC emulation window 124. This action institutes a routine called "Halt" discontinuing the operation of emulating processor 12 as indicated at bo~ 287. At this point, the functional operation of PC emulating processor 12 is halted and its state of operation is frozen. Also, as show~ in Figure 23A, the ~'Pause" command changes to the "Resume~' commaIld in command bar 130. If the display adapter type at decision 28~ is Color/graphics via line 290, then the PC window will invert its video to redisplay the window content as black-on-white (box 294), instead of r~ormal simulation of colors via grey shades ~d also disallow user input. If the display adapter type at decision 288 is Monochrome via 16 liIle 292, then any special cases of displayed te~ in screen 125 not presently ormal black-on-white, such a~ inverted (e.g. selected) characters, ullderlined characters, blillkillg characters or bold text, w~ll be displayed asnormal black-o~-white. Also, host system 14 will disallow user 18 from any further input via ke~rboard 29 or mouse 27 to PC emulation ~nndow 124, as indicated at box 296. The purpose of this invert functio~ is to permit the selection of data within screen 125; other~vise the black bac~ground used in the Color/graphics mode or in Monochrome mode with reverse video (highligh'ed) text may obscure the positio~ of screen cursar 62.

With the operation of the PC emulating processor 12 frozen, user 18 then clicks the mouse point button 31 in PC emulation willdow screen 125 to select the text that is to be t~ans~erred to a ViewPoint application as -- .
'', -: . - - .

.

~L2~38~3~3 indicated at bo~c 298 in Figure 21B. This selection and the boundaries of the te~t selected are indicated to the user by reverse video or highlighting of the beginning character of text to be selected. This is indica$ed at box 300. In Figure 23A, this may, for e~ample, be the character "A'7 at 191. The 5 selection of te3t i~ accomplished by the clicking of the right or ad~iust button 33 of mouse 27 in a manner previously egplained in PC window screerL 125.
In Figure 23A, continuing with the same e~ample, this would be selection ~rith mouse right adjust button 33 at position 193. I~is user action is indicated at bo2c 302. This user action results in the highlight extension of 10 the original point 191 of selection made relative to bo~ 300 to the last character selected at 193 in the extension as indicated in bo~ 304 and shown highlighted at 189 in Figure 23A. At this point, user 18 may invoke the ~COPY> function and thereafter click mouse point button 31 in the previously prepared ViewPoint destination, i.e., in window 187, these 1~ function~ being indicated at bolc 306. Host system 14 will then initiate the transfer of the highlighted text 189 in screen 125 into the ViewPoint destination at window 187, a~ indicated at bo~c 308. It should be noted that only the ~COPY> function, and not the <MOVE> function, can be invoked for transferring text from PC window screen 125. Ihis is because 20 under normal PC operation, there may result confusion relative to a previously running PC program as to the present status of displayed information, which would not be present if moved during the "Pause" state, upon return to the "Running" state.

25 If user 18 ha~ not copied all display text in screen 125 or wishes to make more copies of the same tel~t, a decision at 310 can be invoked to repeat the func~ional operations outlined in boxe~ 298 through 308 to move additional . . . .. . . . . . . . . . . , ~ . .. . . .
` ' ~. .......................................... .
.

~L288~

text to the de~ignated ViewPoint te2t de~tination. ~owever, if further text i9 not to be copied to the designated ViewPoint destination, user 18 may then invoke the ~esume" command at 195 in command bar 130 of PC
emulation window 124 to retu~ the PC emulator to no~nal operational activity, i.e. ~umling7' state 152 (Figure 15), as indicated at bo2~ 316.
Dependi~g upon the di3play adapter chosen at decision 318, whether it be Color/graphics via line 320 or Monochrome via line 322, the operation of PC
emulating processor 112 will restart in "Running" state 152 state e~ecuting code from the point where previous operation had been halted, as indicated 10 . at box 326. If the PC emulator had been in the Monochrome mode, any monochrome te~t characters that have had special attributes, such as inverted or underlined or blinking or bold characters or text, will be redisplayed as indicated at box 322. If ~e PC emulator had beeh in the Color/graphics mode, the text andlor graphics will be redisplayed in 15 simulated colorg previously incorporated a~ indicated atbox 324.

With operation of the PC emulator returned to "Run~i~g" state 152, user 18 is agai~ allowed to input i~to PC window 124 via a~y of the three possible user action~ previously discussed in connectio~ with box 260 in Figure 21A.
Reference i~ rlo~v mate to Figure 2~ which relates to a second transfer tech!lique for the transfer of a block of data corTesponding to a virtual floppydisk by transferring control of the virtual floppy disk icon to either emulating proce~sor 12 or host system 14. In Figure 25, virtual floppy icon 25 96 entitld, "Xerox DOS 3.10" i~ shown selected as a ViewPoint object at 96~ and opened via the <OPEN~ function to show the list of' contained files contained i~ this container in window 97. Any one of the file~ listed ...... , . _ ... ....... ... . ....... . ...... .
~ ~ -~ -`' ' : ; .

. .
.
. . , ' . . , ~ , ~L2~ 73 may be selected and copied onto desktop ~4 and opened via the < OPEN ~
function to reveal the data content of the file. The illustration of this accessis show~ in Figure 251~y the selection of the file, "Sample.ta~t~ at 99 in virtual f~oppy ~vindow 97, invoking the ~COPY> fu~ction to create the 5 data icon 1gl on desktop 54 and subsequently invoking the cOPEN~
fu~ction on thi~ icon as indicated at 191A to reveal it content in window 192. ~he virtual floppy disk icon 96 has also been copied and, as copied, moved into emulating de~ice at location 126B. This provide~ access via the PC emulator wherein the device B at location 126B may be accessed and the 10 file, ~3ample.txt" typed on command and displayed via emulating processor 12 iII PC display screen 125 as shown at 199. Thus, there is access of the same data from a single data container which sele~ively may be displayed either via the PC emulator or via a ViewPoint application or both.

15 Reference i~ now made to Figures 26 and 26A which relate to a third data transfer technique for the transfer of a block of data, via a real floppy disk loaded in physical floppy drive 25 and accessed by either host system 14 or emulating processor 12, and for the transfer of a block of data, via the emulated fixed disk which may be opened on dexktop ~4 as a ViewPoint 20 application or may be co~lgured into the PC emulator at location 126E and the data displayed on PC display screen 1~5. Reference has already been made to the former ~ansfer situation in connection with Figures 18B and 18(~. Aj to the latter transfer situation, referen~e is made to Figure 26 wherein einulated fi~:ed disk icon 100 has not been configured into the PC
25 emulator. Thi~ i9 readily apparent since there i9 no emulated fixed disk syrnbol appearing at location 126E of PC emulation window 124. Since icon 100 is not bound to the PC configuration, the <OPEN> function may be 87^--, ;

, '' , ; , ~, ~ ' . ' ' ~

~888713 invoked on icon 100, a3 indicated at 101A in Figure 26, revealing its file content in BWS ~nndow 101. Two f~lles are shown present in this icon container and the file "Simple.t~t" i~ shown selected (highlighted) at 103.
This file ha~ bee;l copied to desktop 54 at 107 (Figure 25) via the ~ COPY ~
6 fu~ction and thereafter opened via the <OPEN> function, as indicated at 107A, displayi ng its co~tent in window 197.

In Figure 26A, emulated fis:ed disk icon 100 has now been bound to the PC
emulator configuration as can be seen by the emulated fi~ed disk symbol at 10 location 126E. With emulated fi~ced disk icon 100 bound to the PC
con~1guration, its content3 are not now accessible directly from desktop ~4.
Instead, its contents are accessible to PC programs running under the control of emulating processor 12. Thi8 location is device D (location 126E) for th~ particular configuration shown since positions A, B, and C in device 15 bar 126 ~omprise the physical floppy drive (location 126A) and two emulated floppy drives (locations 126B and 126C). As shown in Fi,aure 26A, device D has, been invoked and the command to type ~lle "Simple.txt" has been invoked resulting in the display on screen 125 via emulating processor 12 the te2t of this file at 201.
Reference i9 now made to Figure 27-27D which relate to a fourth data transfer technique for the transfer of data in the form of an actual bitmap of a selected part of ti e PS:~ emulation window to a ViewPoint destination, e.g.
a BWS window using a ViewPoint application called "Freehand Drawing"
2~ available with the 6085 workstation. Freehand Drawing provides a canvas for drawing lines and shapes freehand in a variety of line thicknesses, rulings, shadings and teactures vla canvas icon 78 and a virtual softkey - , - : . .

. . , . - . .
. ' : . , : ~ ', '': ' , . ~ -, . ~ . . .

, ~ .

keyboard available with this icon by invoking the command <KEYBOARD> function from keyboard 29. Usingmouse 27, user 18 can draw straight, curved a~d free form lines. Any area of the canvas containing data, whether graphics or te~t, ca~ be selected aS a brush" for 5 dr~wing. The selected brush can also be modified by using various editin~
functions. Any area of display ~0, including PC display screen 125 or any part of PC emulation window 124, can be copied into canvas window 203 of canvas icon 78.

10 The transfer of data by this method of copying is handled at the level of display bitmap memory. Selection of all or any portion of the display present on screen 50 is captured as a bitmap representation directly from the display bitmap memory and copied, as selected, into main memory and held for re-entry into bitmap memory and display upon user i~voked 15 command~.

In Figure 27, a graphic~ program has been loaded for run~ing in the PC
emulator via the physical floppy drive 25 bound to the PC configuration at location 126A. Display ~creen 125 illustrates a single view from this 20 graphics program which comprises a spoke wheel representation. The PC
emulator is operating i~ the Color/graphic~ mode so that the spoke wheel is shown white on a dark background. As noted in Figure 27, the PC emulator has been placed in "Pause" state 153, the "Resume" command appearing in command bar 130 of this Figure.
In Figure 27A, the < OPEN> function has been invoked on icon 7~ with the title "PC Emulation Graphics"-, as indicated at 78A, revealing canvas .. . .
-.

.' window 203. Icon 78 has been moved to another location on desktop 64 to be visible for purposes of illustration in Figure 27A. Also shown in this Figure is the so~key keyboard-or menu 205, detailed explanation which is not necessary since the use of thi~ menu is not ne- essary for the transfer of data under this technique. It is of interest to note, however, that the menu "Markern columD 207 provides cursor draw selection~ ~or the shape of the cursor to be USillg freehand drawing and the selection of "Brush" in this menu column would pe~nit selection of any re~ tangular portion of data withn callvas window 203 to be used as a paint brush and cursor movement 10 by u~er 18 would function to paint in canvas window 203 with this image clLrsor. In this connection, it will be noted that the paint" command has been selected in the "Stroke" column 209 so that the area selected in screen ~0 fimction~ as the u~er paintbrush per se.

15 In orter to copy the spoke wheel in screen 125 into canvas window 203, the following procedure i~ used. First, po~up menu command at 211 of window 203 is in~oked revealing pop-up menu 213 as show~ in Figure 27B. Next, user 18 selects the "Copy Screen command in menu 213, which is shown selected (highlighted) at 215. At this time, the cursor 62 changes to a 20 upper left corrler angle bracket similar to the symbol~ ~r~. Next, user 18 positions thi~ bracket cursor at the upper left corner of the spoke wheel in screen 12~ and clicks left poiIlt button 31 of mouse 27. This point having been s~lected, the cursor will take the appearance of a lower right corner angle bracket similar to the ~ymbol, "~". Next, user 18 positions this 2~ ~ bracket cursor at the lower right corner of the spoke wheel and clicks the mouse right adjust button 33. Thus, these two bracket cursor selections encompass the area of the spoke wheel representation indicating to system . . . 90 : ~ - : . : ., ;

14 the selection of this area as bitmapped in the display memory of system 14. User 18 then moves the cursor 52A over into canvas window 203 and clicks monse left point button 31 within the frame of window 203 thereby placing the image of the spoke wheel area copied on the canvas in window 5 203. The result of this function is, illustrated in Figure 27C wherein the copied image of the spoke wheel appears at 217 in window 203. The previous upper left corner brack:et selection would be at position 219 while the previous lower right corner bracket selection would be at position 221.
Thus, an image of data graphics produced via operation of emulating 10 processor 12 has been captured and copied to a ViewPoint destination under the control of ho,t system 14 by placing the PC emulator in its "Pause" state and copying the selected content of frozen screen 125 into canvas icon 203.
As illustrated in Figllre 27D, data in the form of text may also be tran~ferred from a document icon to canvas icon 78. In Figure 27D, a ~5 document icon 223 entitled, "Sample Te2ct" has been opened, as indicated at 223A, and its content9 the message, "Sample Text I~side of a Canvas Icon"
appearing in its window 225 at 227 has been ~ansferred via the "Copy Screen commaIld at pop-up menu 211 into location 229 of window 203 in the m~ner as previousIy explained for the spoke wheel representation. Of 20 course, any te2t present in PC display screen 125 may be copied to canvas window in the same manner using the "Copy Screen" command.

.. . .. .. . ,,, ,, . ,, , " , , 9 1 ., ' - ~ ,.
- ~

~2~

. Monochrom~ a~d Color/graphics Display Modes for P(:
Emulator.

Reference i~ ~ow made to display screen 125 of PC emulatio~ Mndow 124 5 a~d the Monochrome ~nd Colorlgraphic~ display mode~. Data in the form of both text a~d graphic~ is supported in the~e mode8.

A~ morloc~rome di3play, ~cree~ 125 ~uppor~ 25 row~ of 80 characters each.
Th~ characte~ are roughly twice a~ high as they are wide, and are ~ot 10 cha~geable by a PC applica'do~ program. Thege characters are emulated by a PC fo~t of 8X 16 pi~els per Table I. Display ~creen 125 will appear with dar~ characten o~ a white background, u~lle~ u~er 1a has i~verted the d~play to be white-on-blacl~ via a me3~u cvmmand at pop-up me~u at 5~.

15 Attribute value~ for mo~ochrome test are the sa~e as for colo~/graphic text:
foreground color, background color, foreground blinking, aIId foreground inten~ity. Bli~ g alld inten~ity are illterpreted in a nolmal way. Color attributes for mo~ochrome character~ are int~rpreted as ~how~ in Table VI.
"Normal in Table VI mea~ a black charac~er on a white backgro~d.
Th~ NS character set of ho~ system 14 i~ estended to provide for IBM
character semanti~ not previously represented, such that character codes exist for the full 25~char cter ~M ASCIl ~et. The PC fonts are 8 X 16 bi~naps for the full default 256-character ~BM ASC~' et. The advantage 25 of usi~g ~ x 16 bitmaps is that the scr~en remains the same size for both the Mo~ochrome mote and for Color/graphics mode.

~ 92--. .

~ ~ .
.. .. .
: ' ':. ~. : . .
.
:
., : . -, . :

Table Vl __ Foreground (tex~) color Background _ _ __ black blue white all others ~ __ _._ black hidden underlined normal normal .
blue normal underlined normal normal hite inverted underlined normal normal . ~ . . r_-. _ 11 others normal underlined normal normal ~ __ ~

An important aspect of the PC display is the size of the PC pixels in relation to the size of ViewPoint NS character pixels. Color/graphic display pixels are appro~imately t~lvice the height of NS character pi2els. Therefore, there are two NS character pi2cel~t one above the other, fior every PC pi~el in order to achieve the ~ame size. In other word~, each PC display scall line will reguire two rows of pi:cels O:~l display screeIl 125. The overall aspect ratio ~nll be subtly different from that of the target PC display.

PC applicatiolls can choose to operate the color/graphics display in either text mode or graphic3 mode. There are two modes of te~ct available for the color/graphic display: 40 column a~.d 80 column as illust~ated in Table VIL
On the PC, characters for both these modes are formed from an 8 X 8 bil;map with hardware determining the size and shape of the resulti~g displayed character. On the host system display, a 40^column-mode character will be simulated by a 16 X 16 pixel box, and an 80-column-mode character will be simulated by an 8X16 pixel box. Since the 80 column mode has twice as many characters as the 40 colum:n mode with each at half the width, the - .. ..... 93 --- .

; .
, . . ; ' ' ~'' ': ' ' ' , ~ ' - :; . : .

- ~IL28~

display resolution o~ the host system display is the same, i.e. 640X400 pi~cels, in either case.

Tabl~ Vll _. . _ .
HostSystem 14 Display PC Emulator Display [plxels are half as high as PC
achieve the same heightl ~ =
Character size Wid~h Height Width Height (inpixels) 40col.: 16 x 8 40col.: 16 x 16 80col.: 8 x 8 80col.: 8 x 16 _ . _ __ ._ _ Displaysize(in 40col.: 640 x 200 40col.: 640 x 400 pixels) 80 col.: 640 x 200 80 col.: 640 x 400 Associated with each character is a set of athibutes. The attributes on the PC emulator specify (1) whether or rlot the character is blinking, (2) any of eight colors for 'che background, that is the area surrounding the character, (3) any of eight colors for the foreground, that is the character itself, and (3) the i~tensity of the foreground color, which is medium or bright. All of these attributes may be provided in various combinations. For example, one may have a blinking red character o~ a blue background. When colorlgraphics mode is disabled, the only attributes available are reverse video comprising black characters on a white backgrou~d, blinking, and intensity. It should be noted that a value at particular location can be set to indicate that the foreground-blinkillg attribute for each character should b used to instead determine the background intensity, thereby making it possible to provide sixteen background colors.

Any scheme of repr~sentiLg colors OL the host system black-and-white display should have the following characteristics: (1) legibility when .

.

.. , _ ... . ...... . . . .. .. _ . . . . _ .. __. ... . .. .. . .. . .

- - . , .: , .

:. . . .. . , ... ~

. ~
,, ~

~L~8~3873 foreground and background are different colors, ~2) invisibility when foreground and backgrou~d are the same color, (3) background color invariance, i.e., the same color code produces the sarne gray pattern everywhere, and (4) foreground colorinvariance.

UIlfortunately, these criteria are impossible to achieve when several colors must be mapped onto a much more limited range of grays. ~ince legibility is obviously paramount for what is, after all, text, and since the background pattern provides more fle~ibility in choice of grays, color/graphics text is - 10 ~imulated as follows: (1) a unique gray patteFn represents each of the eight non-i~te~se background colors. (2) Other, possibly non-unique, gray patterns represe~lt each of the possible eight intense bac~ground colors. (3) Foreground color invaria~ce is sacrificed; instead, the two most legible of white, 50% gray, a~d blac3~ are chosen depending on background. Of the two 15 legible choices, one i~ used for ~he lighter foreground colors and the other for the d~rker foreground colors. (4) If the fioreground and background colors are the same, the character is invisible.

Changes in the shape" of PC emulator cursor are supported. The term 20 shape'~ refers to the ra~ge of scan lines that the cursor will occupy. On the host system display 50 the cursor representations are two pixels high. The cursor is always as wide as a character, which is eight pixels wide in the 80-column mode a~d 16 pixels in the 40-column mode.

25 For~graphics in the colortgraphics mode, there are two resolution modes:
medium resolutio~ graphics and high resolution graphics. In the medium mode, the PC screen 12~ is divided into 320 X 200 pi~cela On the host system . ~ .. .... .. . . .... .. ... .. .. . ... . . . ..
, . ~ . . .

.
.
,~

.

.

, 88~3 display 50, each of these pixels is represe~ted as four pixels, as indicated in Illustratio~ I below. The resulting comparable host system dsplay sereen will, therefore, be 640x400 pixel~. The extra height is due to the smaller pl2els on the host sys1;em di3play. The extra width i~ a result of being i~
5 medium resolution.

t~Nohost Tm system 1 L Ll pixels high ~ ~
Illus1:ration 1 Sia~teen cQlors are available to choose from, but only four colors can be displayed at any time.

Since there are four host system pi:~els for each PC medium resolution pixel, combinations of the four differe~t quadrants of each PC medium resolution pisel can be employed to illustrate dif~erent levels of shading representing different colors. Table VIII below illustrates how shadings may be 20 represented by seven different pattern representation or by sixteen di~erent pattern representatio~

Though the most practical choice ~vould be the group of sixteen pixel patterns since more colors can be represented, many of these patterns, for 25 instance, 1, 2, 4, and 8, would be indistinguishable at the size user 18 will ... . ,, .. ~ ... .. . .... .. . ~. ~

-. ; .
.

.
. .

-~:81~73 --_ 0 1 2 3 a, 5 6 Seven patterns: O 1~1 1~1 1~1 1~1 11~1 Illi ~3 0 1 2 3 4 5 6 7 I Pixel I O ~ O ~
numbers:~ 8 9 10 11 12 13 1~ 15 [~ - h ~

Table Vlll view them. Thu9, the set of seveIl pi~01 patterns is the preferred lower level that is ac~eptable with shading levels remaining distinguishable.

Table IX below illus~ates an e:~ample of one possible mapping of colors to 15 the seven pi~el pattern representation di~ferent from that shown in Table vm. However, the pattern representation in Table IX provides a better visual distinguishing level betwee~ color representations Color mappings in terms of darkness are li~ted from 0 (the darkest) to 6 (the lightest), although color mappings to 2, 3, 4 and 5 are ar~itrary in terms of darl~ness 20 since these patterns are at the ~ame level of gray, but preferred for patternrepresentation and shading distinction since, in these patterns, one of four possible corner pixels of the quadrant pattern is the only pixel highlighted.
Other patSeFns, of course, are possible.

25 High resolutioll graphics mode divides PC display screen 125 into 640 X 200 pixels, which translates into 640 X400 host system piacels .

. ........ : ~

.
., ~

- , ~

.

~ _~
Intense White (whitej~ Whi~e (light grey) ~ 6 13 LightGreen a LightCyanl ~ 5 LightMagenta ~ 4 Light Red ~Light Blue~ ~ 3 10 Brown Magenta b~ 2 ~ ~ Dark Grey ~ 1 13 ~lo Tabl~ IX

TeYt may be sele-~ted in PC wi~dow 1~4 in either Monochrome or Color/graphics. teact mode and transferred to a V;ewPoint desti~ation as 20 previously esplained.

XI. Input Mechallism and Methodology.

During the course of the previous discussion, attention has been directed 2~ mainly to ~he user interface for both host system 14 and the PS~ emulator via emulation window 124, the interaction between these separately operated vidFo processors each capable of handling user input when the - .: .

~: .
. .
, ,; . ' ''~ ~ :

: : .
; ~

~L2~38'73 user input focus is directed to either system. Also, discussion has centered o~ user interaction with ViewPoint objects useful in the user interface e~vironment of either or both systems. An example of the latter type of system "shared" objects are, for e~ample, the emulated fi~ed disk icon and 5 virtual floppy disk icon which can be opened to reveal their contents in a BW~3 window ~nd caused to show their properties in a property sheet through user input, the input focu~ of which may be directed at either system. Discussio~ will now turn to a description of the processes implemented in software underlying these ViewPoint applications in order 10 to understand the methodology and input mechanism in handling user invoked inputs, such as < OPEN >, < PROP'S >, mouse point selection and moving data between windows or containers, and what happens procedurally to respo~d to these user inputs.

15 I~ conventional user interfaces, there i9 a defimed set of acceptable user inputs and there are defined poi~ in a sequence of operations at which the system will look for user input and will respond appropriately if an acceptable input is received. Thus, the system responds to user i~put only at defiIled points in operational seque~ces of the system. By contrast, the 20 user interface of host system 14 utilizes an input mechanism which accepts user i~lpUt at any time 90 that each input command is independent of ally predefined sequence and is an action responded to by system 14 basically in the sequence received. System 14 performs the appropriate response and then waits further user input. This type of user input mechanism functions 25 somewhat like an interrupt system wherein the system is maintaining run-time operations and when a user input is received, the system is interrupted to perform the appropriate response, after which it returns to the . ~

. . : ~ , . . :
- , ~: ' . . , . ' ' :
. .
~ . . . . . . . . .
.: . . ~ .

- . . . .: -:. :.

~L~88~3~73 inte~Tupted operations. Such an approach is much more ver~atile in handling user invoked cornmands providing a more friendly user interface.

The input mechanism u~ed in the Xero~ 6085 ~orkstation accept~ and 5 handle~ user i~puts in any received sequence and completes its response to each input before handling the ne~t user input. This input mech~ism is implemented in part with Mesa software, but could be implemented in substantially the same manner with another suitable programmin language. As previously indicated, the hardware architecture of this 10 workstation i~ discu~ed in more detail in pat0nt application Serial No.
5 3 5, 6 4 8 . As discus~ed there, input/output proces~or (IOP) 22 handle~ the inputloutput (VO) devices and shares ItS bus with emulating processor 12. YVhen IOP 22 recei~res user input, it provides information concerning that input to host system proce~or 20.
Figure 2~ ~how~ e manner in which ho~t ~ystem processor 20 receives infor m stion about u~er inputs. R:eyboard processor 360 in the keyb~ard/mouse V(:) device scan~ ~a~ou9 s~itche3 and sen~or latches i~ the key~oard a~d mouse ~o de~er~ne ~Yhe~her any have changed state si~ce ao thelastscan. Ifa s~itch orlatch has cha~ged s~ate,keyboard processor 360 generates a sca~ code i~dicating ~ hich s~ntch or latch has changed state and whe~her ~he cha~ge was a do wn or up stroke for a particular key or mou~e button or if a m ouse moveme~t ~as been ~ensed a~d latched.
Keyboard processor 360 provides an interruptto IO P 22, and Yvhen IO P 22 services that i~terrupt a~d addresses keyboard processor 360 for that purpose, keyboard processor 360 provides ~he scan cide it generated. A
device handler, at 46 i~ Figure 2, servicing the i~terrupt unthin IOP 360 . _ _ . . .. . .. .. ..... .. .

.: . , .. , -~
-~: ', ., : , , 38~373 receives each scan code from keyboard processor 360 and keeps track of cursor position in the X and Y dimensions based on scan codes indicating mouse movement. ~1Yhen a scan code is received indicating a down or up 3troke, tbe handler sets a bit in a keyboard array 362 in main memory correspondin~ to that 9C~Il code. When a scan code is received indicating movement of the mouse, the handler loads new values into the mouse X
posi'don word 364 and the mou8e Y position word 366 in memory.

The input mechanism involves how user actions are translated into 10 program actions. When user 18 presses a keyboard key or moves or clicks the mouse, that action must be recog~ized, directed to the correct window, and then acted upon. This multiple~ng of user input is the job of two processe~ called the Stimulus" or "stimulus level" and the "Notifier'~ and the TIP ~ermi~al Inter~ace Package) table. The ~3timulus is a high priority 1~ proces~ that watches for user actions a~d enqueues them. The Notifier the~
dequeues each event aDd directs it to a window. All user actions are directed either to a window with the illpUt focus or to a window with cursor click action. In the case of te PC emulation window 124, other ways of placing input focus to its window ~rhe~ open is invoking the "~oot"
20 command and/or moving a virtual floppy into an emulated drive configured into the PC emulator. A T~ table provides a flexible method of translating user actions into prog~am actions. A given window always has at least one associated TIP t~ble and may have a chain of tables. The Notifier checks a given u~er action against the TIP table or each table in the chain until it 25 finds a mealling match. If it finds none, the ac~ion is disregarded.

: .

: . .

. .;

~L2~38~'73 Once the ~otifier has determined the correct window for a user action, it checks for that action in the w~ndow's llP tables. A IIP table is essentially a giaI~t select statement. The left side of ;he table contains var~ous user actions and the right side of the table has a list of results. When an action is5 located in the lef~ side of a table, the corresponding result on the right side is passed to a special procedure called NotifyProc. The NotifyProc is then resporlsible for e~ecu~ing whatever program action are to be associated with the user action.

10 As illustrated in Figure 29, the routine executed by host processor 20, referred to as the stimulus level, cletects changes in the contents of keyboard arTay 362 and the mouse position words 364 and 366. Tn box 3~0, the stimulu5 level waits for an interrupt, which it receives in bo~ 372. This inte~rupt may be received at a freque~cy based on ~he frequency of display 15 refresh, such as appro~cimately 60 times per second. The stimulus level then retrieves the mouse X position word 364 arld the Y position word 366, in boa: 374, and, in box 376, compares them with the previously retrieved values t~ determirle whether the mouse has moved. If so, a mouse motion event entry is loaded into a ring buf~er in memory in bo~c 378, providing 20 iIlforma~ion about the mouse motion. This ring buf~er may be managed in the manner described for other ring buf~ers i~ patent application Serial ~o.
535,648. Then a~other routine, referred to as the notifier level or Notifier, is called in box 380 if it is waiting for a call to begin execution. Then the sbmulus level proceeds to retrieve the contents of the 25 keyboard array 362, m box 382. I~ box 384, the stimulus level compares the retrieved contents and compares them with the previously retrieved contents to detemune whether any changes have occurred. If any keyboard , ':: ', ' ' . ~ -' - . , ~ . ~ . .. .

3'73 or mouse button changes are ~ound~ a keyboard event entry for each such change is loaded into the ring buffer, as previously described, which is indicated at box 386. The stimulus level again calls Notifier if Notifier is waiting for a call, in box 388, and then returns to wait for an interrupt in 5 box 370.

Fig. 30 shows the sequence of events followed by Notifier as it empties the ring buffer after receiving a call from the stimulus level. Notifier retrieves the negt event entry from the ring buffer in box 390. If the entry is a mouse 10 rnotion event, Notifier calls procedures which update the position of cursor 52 and store its current location. But if the entry is a keyboard event, Notifier tests in bo~c 392 whether it is operating in a special mode, meaning that a special window receives all keyboard events. If so, the special window is selected as the window to which the keyboard event is provided in 15 box 394. If rlot in the special mode, Notifier next tests in box 396 whether the event is an event for the window which is the current input focus, or is one of a limited number of other events such as a mouse click which may not go to the current input focus window. If the event is for the current input focus, the cu LTent input focus window is selected in bo~c 393, but if not, the 20 window in which cursor 52 was located when the event occurred is selected in boa~ 4O.

As is known from previous description, the user interface provides display screen 50 which can display a number of BWS windows. Each window may 25 be thought of as a distinct screen object on desktop 54, and other screen objects include cursor 52 which follows the mouse movements, icons which appear on desktop 54, and other displayed components included in windows :' -:, . , ' " ', : . - ' . .
...' :
,, -~81~38~

such as headers, command bars, properties, menus and so forth. ~ost icons can be opened, and the opening procedure, as discussed in more detail below, results in a window on screen 50 and a corresponding data structure in memory into which data may be entered via key operation OIl keyboard 6 29. Notifier stores values indicating whether it is in a special mode with one of the windows a special window a~d indicating which window on desktop 64 is the current input focus, in each case meaning that data which is entered will be received by the data structure corresponding to that particular window. The current input focus may be changed, for example, 10 by clicking left point button 31 on mouse 27 when cuxsor 52 is in a window other than the one which is the current focus.

If the scan code represents a mouse click with mouse button 31 at a particular screen X,Y point which indicates a change of input focus, Notifier 15 will call a procedure which deteImines the window to which the input focus has been changed and that procedure will provide a new value to Notifier for the new input focus window. This procedure will use the identified location of cursor 62 from the ring buffer entry which was previously retrieved, and will, for example, determine from that X,Y location in which 20 window cursor 52 was located when the mouse click occurred. The cursor location can be compared with a tree data structure which includes a list of each deflned window that is capable of display on screen 50, its location and any procedures applicable within the conte~t of that window. This window data structure is contained within a larger ~lesa data structure called the 25 window package, which also holds a number of general procedures relating to windows, including a window manager which loads the display bitmap based on the contents of the tree data structure. The window package, in - :
-~ . , ~ Z~ 73 turn, is cont~ined in a larger Mesa data structure at BWS 38 (Figure 2), which also includes the Notif1er and other items discussed below, including a selection controller, property sheet base code, and Containee.

5 The procedure called by Notif;er, to determine the window selected for focus of input, thus provides the location within BWS 38 at which the data structure for that window is found. If the event is an event for the current input focus, the location of the current input focus window's data structure will remain as the value stored by Notifier as the value of the current input 10 focus.

When the appropriate window's data structure has been determined in bo~es 392-400, the meaning corresponding to the keyboard event retrieved from the buffer is then retrieved from a TIP table in that window's data 15 structure, as indicated at box 402. This TIP table is accessed based on the event retrieved from the buffer, and unless a special l~ table including the keyboard event has been set up for the current window, a de~ault TIP table for the system will be used, providing a meaning which is ordinarily appropriate. The meaning provided by the TIP table is particularly 20 relevant to emulation of an IBM PC, because the l~' table for emulator window 124 provides appropriate 1~3M scan codes for the retrieved keyboard events per Table I above. These scan codes then serve as keyboard input to PC emulating processor 12.

25 NotifyProc, another procedure within the current window's data structure, is called by the Notifier to service each meaning retrieved in box 402. The NotifyProc receives the meaning in box 404, and NotifyProc either updates ... . . .

.
.
.' ' . ' . , , the current window's data structure directly or calls other service procedures to do so. These other service procedures are stored within th~
window package in BWS 38, a~d may be called by the NotifyProc of any of the BWS windows when selected. NotifyProc calls the se~Tice procedure to 5 handle the meaning in box 406.

This input mechanism, as noted above, allows each input to be separately handled, regardless of where it occurs in a sequence of inputs desired to be invoked by user 18. The actual effect of a specific input, however, may vary 10 substantially, depending on which window receives it. Reference is now made to consideratians relative to the effects of user inputs to the PC
emulator.

The term "application" may be defined as a set of interrelated features of a 15 system which provide a characteristic, recognizable function or interactive screen object. This characteristic interactive screen object may have a number of pieces, some of which are screen objects with independent forms and some of which are screen objects dependent on other screen objects. But at least one of these screen objects must be present on desktop 54 in order to 20 make av~ulable the particular application to which they belong.

The PC emulator icon, as discussed previously, may appear on the screen as an independent screen object. Its presence cn desktop 54 will depend, however, on a number of previous events. Typically, when a system using 25 the input mechanism described above is booted and user 18 logs on, a primary window appears which includes the entire screen 50 and this particular application is called the Desktop. The data structure for the : . - .
-, . .

. ~ ' .
:, `
.

8~

Desktop window receives all user inputs from Notif~ler until anotherwindow has been opened and appears on the screent at which time that subsequently selected window may become the current input focus for user input and receive inputs directly from Notifier in the manner described 5 above.

The first time desktop a4 is opened at logon by user 18, it will typically have only a small number of default screen objects. One object may be header 56 or other similar screen object which provides access to various basic 10 functions such as log off, such as through pop-up menu 58. Another default screen object may be a directory icon 60 through which user 18 may access other objects that bring about other applications available to the user.
When the directory window appears, it provides access to a number of applications, each of which may be copied out of the directory window, 1~ providing other icons which remain visible as independent and established screen objects on desktop 54.

A. Invoking Icon Functio~

20 The visible effects of opening and otherwise manipulating PC emulator icon 94 have already been discussed above. Some of the features previously discussed involve applications other than the PC emulator application, i.e.
applications which may be accessed through other icons, including virtual floppy applications, emulated fixed disk applications, document 25 applications, Interpress master applications, freehand drawing applications and so forth. Reference is now made to a more detailed e~planation of the .. . . . . . . .. .
.
.
..
.
' ' ' . ..

.. ..
~ . . . . .
,. .

, .

manner in which user inputs affect these types of applications during PC
emulation.

PC emulation implemented according to the invention is interactive in that 5 user inputs may be applied to configure, boot, reconfigure and reboot the emulated system, in the manner previously described. The user inputs which control these interactions include independently invoked commands for selecting the PC emulator icon, requesting display of its property sheet, requesting the opening of the icon, requesting display of its option sheet, 10 and requesting boot or reboot.

1. Selecting the PC Emulator Icon. Before PC emulation can proceed, the PC emulator icon must be selected. User 18 selects it with the same input means used to select any icon on desktop 54, and the resulting 15 processes within the system are similar to those which occur when any other icon is selected.

User 18 moves mouse 27 so that cursor 52 is located on PC emulator icon 94.
The Notifier updates the cursor position in response to these mouse 20 movements. With cursor 52 on PC emulator icon 94, User 18 selects the icon by clicl~:ing left mouse button 31, resulting in a point scan code. The selection to be complete must be a full mouse click. Pressing and holding down lefg mouse button 31 over the icon will provide a highli~'lted condition of icon 94 but if the mouse cursor 52, with button 31 still held down, is 25 removed fi om its position over icon 94, icon selection will not be completed.

~L288~373 When Notifer receives a keyboard event resulting from this point scan code, as discussed in relation to Figure 30, it obtains the window data structure corresponding to the location of cursor 52~ All of the icons are displayed in the Des~top window, so that the location of the Desktop 5 window data structure and the meaning of the point scan code are ascertainable. The meaning of the point scan code goes to the Desktop NotifyProc, which calls the appropriate service procedure for icon selection.
The Desktop window data structure contains several additional types of information, including the inforrnation needed to paint the window as it 10 appears on screen 50; a directory of icons displayed, their file types and their X,Y locations relative to an invisible bloc~ grid on desktop 54; and a procedure for identifying which icon is at the location of the cursor point based on the ~ursor X,Y location. Therefore, having received the point scan code, the Desktop NotifyProc calls this procedure to identify the particular 15 icon selected.

The Containee data structure in BWS 38, mentioned above, contains two procedures for each of the file types which an icon may have. One of those procedures is PictureProc, which is a procedure to display an icon picture 20 and can be used to modify the manner in which the icon is displayed. The other procedure in Containee, GenericProc is a procedure called to perform < OPEN>, <PROP'S3, < COPY> and <MOVER> . GenericProc will be discussed in more detail later Ln relation to opening an icon. Upon identifying an icon to which cursor 52 is pointing, NotifyProc caIls 25 Containee to obtain PictureProc for the file type of that icon in order to : ~

- ..' ~' .

~LX~ 373 highlight the icon as displayed on the screen, which is typ~cally accomplished by a partial video reverse.

Upon identifying a selected icon, NotifyProc also calls the selection 5 controller in BWS 38 to make the Desktop the current selection manager, a role which will be discussed in more detail later. When the selection co~troller has done this, the previous selection manager receives a notification that it is no longer the selection manager, and it in turn takes appropriate steps so that its icon is no longer highlighted. Then, NotifyProc 10 calls Notifier with a re~uest to make the Desktop window the current input focus.

At this point, the handling of the user input which selected PC emulator icon 94 is complete, so that the Notifier proceeds to retrieve the next event 15 entry from the ring buffer. The next event could be any possible user input, but user inputs requesting the property sheet for that icon or requesting that the icon be opened are of particular interest.

2. ~equest Property 5heet. User 18 may request display of the PC
20 emulator application's property sheet 1~ by in~voking the <PROP'S>
function on keyboard 29 when PC emulator icon 94 has been selected in the manner described above. The <PROP'S> event's meaning is provided to Desktop's NotifyProc, as is the case with other keyboard events received when the Desktop window i the current input focus.
Based on the <PROP'S~ meaning, the Desktop's NotifyProc calls a procedure which identifies the current selection manager, in this case the ~ ~ .
. ' ~lL2~ 7;3 Desktop itself, and identifies from the data structure within the NotifyProc the file type of the selected icon. Then it calls the GenericProc from BWS 38 for that file type, requesting that GenericProc set up the property sheet window.

GenericProc has available to it a number of facilities or procedures in BWS
38 which it may use to set up a BWS window. One facility, for example, can be used to obtain the basic form of the window to be displayed on the screen, while another facility can be used to create a data structure for the window.
10 Ill the case of the property sheet window, GenericProc calls the property sheet base code and other procedures to create a data structure for the property sheet window, inciuding a NotifyProc and a IIP table, and to provide a form for the window which is then loaded into the data structure.
The window includes components, including a header and a body bounded 15 by a suitable frame. In the case of PC emulator property sheet 122, the body contains a number of items of text and a number of fields with items of text a~ default value with some of these items provided in different forrns of the sheet as set forth in Figures 7, 8 and 9.

20 The property sheet window data structure is then added to the tree of visiblewindows in the BWS window package, resulting in its display. In addition, NotifyProc calls the selection controller to make the item of text in one of the fields in the property sheet window the current selection1 and the selection controller will cause that ;tem of text to be highlighted, 25 permitting user 18 to make changes relative to the item. NotifyProc also calls Notifier to make the PC emulator property sheet window the current input focus, and Notifier provides a bli~kin~ caret after the current .
' ' `

, :
.
- :

selection, inviting the user to add te:ct to it. The selection controller also calls PictureProc from Containee to change the PC emulator icon back to its non-highlighted form, completing the response to the invoked <PROP'S~
function.

User 18 may provide various inputs while property sheet window 122 is the current input focus, as illustrated in relation to Figure 7, 8 and 9 showing the property sheet window 122, 122A or 122B. Each of these inputs will be handled by the property sheet window's NotifyProc to obtain the ef~ects 10 described above. The data stored in the PC emulator property sheet window's data structure is stored in a file in fixed disk memory, accessible based on the identity of the PC emulator icon through a directory. In this manner, more than one PC emulator icon may be displayed, each configured differently to provide a separate and unique PC emulator application. The 15 configuration of the icon will determine the manner in which the PC
emulator operates when the icon is opened, as will be touched on below.

3. Opening the PC Emulator Icon. When the PC emulator icon is selected, user 18 may press the ~ OPEN > key on keyboard 29 to provide a 20 scan code whose keyboard event meaning is a request to open the selected object. Another user input may perform this same function, for example, a rapid series of two mouse click scan codes, which may have the same keyboard event meaning. This transfo~nation from user input seque.lces into event meanings is specified by the IIP table for the particular window 25 with the input focus.

., , . . ,;
- :
.~ ' .
: , - ~ '; : , ~ ,~

~LZ~1~3837~

The Desktop's NotifyProc, upon receiving a request to open a selected icon, calls GenericProc for that icon's file type with a reques,t to open.
GenericProc then retrieves the information stored in relation to the property sheet for that icon. If the property sheet window has been 5 displayed, user 18 may have modified that information, but if not, default values will be stored. In the case of PC emulator icon 9D~, the info;mation will include not only the details of the configuration of the PC emulator, but also the i~itial selection of whether the option sheet should be displayed before the PC emulator window is displayed, and the further selection of 10 whether the PC emulator should be booted automatically upon opening PC
emulator window 124.

If the user selection is to display option sheet 136, GenericProc calls appropriate procedures to create the option sheet window, which is 15 substantially similar to the property sheet window. The data structure of option sheet window 136 includes a procedure which is called when this window is closed which also calls GenericProc to create PC emulator window 124. Tn general, however, option sheet 136 merely enables the user to select the configuration of the PC emulator for the current session of PC
20 emulation without changing the confguration which is stored in relation to PC emulator icon 94. Instead, the contents of the PC emulator option sheet window data structure are used directly in configuring the PC emulator when option sheet window 136 is closed.

2~ If the uger selection is not to display option sheet 136, or if option sheet 136 is being closed, GenelicProc calls appropriate procedures to create PC
emulation window 124. This window will include additional components : ,., ' ' ' ~,' ~ ' . ' ,;, - -:

'73 not found in property sheet window 122 or option sheet window 136, including message subwindow 128, device bar 126, and display screen 125, previously discussed in relation to the Figures 10 and 11. Desktop Notif`yProc also calls PictureProc to convert PC emulator ico~ 94 to a ghost appearance at 94A, indicating to user 18 that the icon is in an opened state.

In addition, if the user selection i5 to boot the PC emulator automatically on opening, the GenericProc will call a procedure which boots the PC emulator with the configuration selected. If not, the configuration selection will be 10 stored in the PC emulator w~ndow data structure so that when the user provides an input selecting the boot operation, the boot may be performed.
Similarly, if user 18 selects the "Show Options" command, option sheet window 136 will be created and displayed, and user 18 will be able to change the de~ault configuratio~ for the current PC session. Then option 16 sheet 136 may again be closed and the PC emulator rebooted.

Once PC emulator window 124 is displayed, user inputs to window 124 are ha~dled by its NotifyProc as long as ~he culTent i~put focus remains in this window. For eacample, ~he 1~ table for this window converts keyboard 20 events to rBM scan codes to be provided to PC emulating processor 12 in the manner described in patent application Serial No. 5 3 5, 6 4 8 .

.

~L2~ 373 B. Data Transfer Between System Processors.

Data may be transferred from the control of one of the emulating processor and the host system main processor to the other by a number of techniques, ~- and reference is now made to how those transfers are implemented.

Reference is again made to the transfer of data between hoist system 14 and emulating processor 12. In a sense, all the data in the system is under the control of host system main processor 20, in that the miain processor could 10 theoretically access it. In a more important sense, however, some of the data in the system is under the control of emulating processor 12 and can be manipulated by it during PC emulation, while other data is under the control of main processor 20 and can be manipulated by it, according to one of its applications.
The data under read/write control of the emulating processor includes data in its allocated memory on the host system hard disk, and may also include data oll a physical floppy disk in the physical floppy dnve; data in host system hard disk memory allocated to a virtual floppy disk; and data in host 20 system hard disk memory allocated to an emulated fixed disk. In addition, since the data displayed in the display area of the PC emulator window is provided directly from the PC emulator's display buffer, that data is under write-only control of the PC emulator. Although the host system main processor may have access to much of this data, it must not be freely 25 permitted to change this data, because that would interfere with the operation of the PC emulator. Conversely, the PC emulator does not have .
, , - . ~ . - : ~ .

. ` ' , '~ ~ ' ' '.

' ~ ' . . ' :

.

~2~98~73 access to the remainder of memory, so that the host system is protected from a crash of the PC emulator resulting from defective or malicious software.

As discussed above, the user may provide inputs which cause selected data 6 under the control of one of the processors to be transferred to the control ofthe other processor. This means that data under the control of the PC
emulating processor may be moved or copied so that one of the host system main processor applications may manipulate it, and that data under the control of the main processor may be moved or copied so that the PC
10 emulating processor may manipulate it. Various techniques for transferring data could be implemented, including the use of a move or copy user input, the use of an e~it and boot procedure, the use of a bitmap capture user input and so forth.

15 1. Move/Copy Input. User 18 may transfer data by invoking a <MOVE >
or <COPY~ via keyboard 29 or other equivalent and suitable user input.
l'he basic sequence the user follows is to indicate somehow a selection of an object to be transferred, to provide the move/copy input, and to provide an input indicating the destination to which the object is to be transferred.
20 Within this basic sequence, a wide variety of specific techniques can be developed, suitable for the type of data transfer being made. The following techniques relate to the data transfers previously described in relation to Figures 21-23 and 25-27.

25 If the selected object is text in the PC emulation window 124, the selection is made by selecting the "pause" command, and then a sequence of point and adjust mouse button con~nands are utilized to select the text. It should be ,, .~ , .
-.:. . : .~ . .
.

~L2~8~3 noted that user 18, whether input focus is in window 124 or in any otherViewPoint window or on desktop 54, can move mouse 27 while holding down a mouse button 31 or 33 thereby pinpointing the desired selection by watching the highlighting change across the display as this mouse motion 6 is calTied on. Holding down point button 31 will select a single character while its release followed by holding down adjust button 33 will dynamically e~pand or reduce the amount of selected text, as seen by the highlighted te~t, from the point of original release of point button 31.
Complete selection by release of the mouse button, which is a mouse click, 10 makes the PC emulation window the current selection manager. The NotifyProc of PC emulation window 124 examines the mouse motion events to determine the characters to be selected, then calls PamtProc to highlight the selected text. Although text cannot be moved out of the PC emulation window, it can be copied. Therefore, if user 18 invokes < COPY ~ while the 1~ te~t is selected, NotifyProc calls a procedure which modifies the system TIP
table so that a point down scan code anywhere on desktop 54 has a special meaning called copy mode down.

When user 18 then provides the point down input, the Notifier determines ~0 which window cur~,or 52 is pointing to and retrieves the meaning copy mode down for that BWS w~ndow's NotifyProc. This NotifyProc will then call the selection controller to determine whether the current selection can be copied into that window; if it is an open docume~t window, text could be transferred, for example. If the window can accept the selectiont the 25 selection contrcller also relays a request to that effect to the current selection manager, which provides the current selection. The selection controller also calls a procedure to convert the selected text object into data -, . .
.

, ' : ' , '` ' ' :
.
- i , ~28~8~3 suitable for the document window's data structure. Then the selection controller passes the selected text object to the document window's data strllcture, and the document window's NotifyProc makes its window the cll~Te~t selection maIlager.

If the selected object is te~t in a document window, the selection is made by an appropriate sequence of point and adjust keystrokes. The document window is the current sele.tion manager. Its NotifyProc calls PaintProc to highlight the selected text. If the user then selects the<MOVE> or ~0 < COPY > function while the text is selected, NotifyProc calls a procedure which changes the system'l'~ table so that the point down scan code's meaning is move mode down or copy mode dowIl. When the user then provides the point down input in PC emulator window 124, the Notifier provides this meaning to the emulator window's NotifyProc, which calls the 15 selection controller to determi~e whether it can accept the selected object a~d to tra~sfer the selectio~ if acceptable. The selectio~ controller relays this request to the curre~t selection manager, the document window, with a request to convert the selected object into text. Then the selection controller passes the selected text ob3e~t in its collverted form to the emulator 20 wi~dow's data structure, which converts the te~t into keyboard scan codes appropriate to the IBM PC and then makes itself the current selection manager. Rather than displa~ing the selected text in emulation window 124, however, the em~llator wi~dow's ~otifyProc calls a procedure which passes the IB~I scan codes to emulating processor 12 as emulated 25 keystrokes in the manner described in patent application Serial ~o. 5 3 5, 6 4 8 .

- :' , , .
. .

l2s~a~3 The transfer of virtual floppies and Interpress masters is similar to the sequences outli~ed above, but with some important variations. In moving a virtual floppy or Interpress master out of PC emulator window 124, a mouse clicl~ at a cursor location on an emulated floppy drive or Interpress printer 5 in device bar 126 suffilces both to select the virtual floppy or the Interpress master, respectively~ ar~d to change the system TIP table so that the meaning of point down is move mode down. PC emulation window 124 is the current selection manager, aIld its NotifyProc calls the PictureProc to get a tiny cursor, e.g. tiny cursor 98" in Figure 10, representing the virtual 10 floppy or Interpress master being transferred. If user 18 then provides a click on desktop 54, the ~esktop window NotifyProc determines whether there is an icon at the X,Y location of cursor 52. If so, that icon's GenericProc is called and requested to take the select~d obJect, and it will call the selection controller to deterrnine whether it can do so. If the X,Y
15 location is not on a}l icon, the Desktop itself calls the selection controller, which in turn calls the current selection manager, emulator window 124, to convert the selected object into a file which is effectively a new application and ~ hich results in an icon o~ desktop 54 at that location.

20 In moving or copying a virtual floppy onto an emulated floppy drive in device bar 126 of PC emulatiorl window 124, t~ie icon for the virtual floppy is selected in the same manner as the selection of PC emulator icon 94 as previollsly described. Then, either the <MOVE> or <COPY> function will result in the assignment of the move mode down or cop~- mode down 25 meaning to a point down input. If the point down occurs in PC emulation window 124, the selection controller will call the PC emulation window data structure to determine whether the X,Y location of cursor ~2 is on an ~ --1 19--~ : ~

. .. .. .
.

emulated floppy drive. If so, the selection controller will pass the location ofthe virtual floppy to the PC emulation window data structure, which will treat it as if it were a part of the configuration of the PC emulator.

5 The move/copy procedures thus permit the transfer of data between the control of the two processors with relatively little interruption of PC
emulation. We turn now to a transfer of data which requires boot and exit procedures to effect a transfer.

10 2. Exit/Boot Transfer. The emulated fxed disk is an example an application which permits the transfer of data between the control of the two processors, but not without boot and exit procedures for the PC
emulator. Like the virtual floppy discussed above, the emulated fixed disk is on the host system's hard disk but can only be under 'che control of one of 1~ the processors at a time. In the case of the virtual floppy, one of the procedures which is called when the virtual floppy is transferred ensures that only one of the processors has control of it at a given time.

Emulated fixed disk icon 100 represents data on the hard disk which is 20 under the control of host system main processor 20. In order to place this data under the co~trol of PC emulating processor I2, user 18 selects "Show Options" comrnand in command bar 130 of the PC emulation window 124.
Default winclow NotifyProc handles the mouse action for this command and calls a procedure to create option sheet 136. User 18 then reconfigures 25 sheet 136 to include emulated fixed disk icon 100 and selects the "Reconfig~ure" command in command bar 130, in response to which the default window NotifyProc calls an exit procedure resulting in the halt .

.. , , ~ ... .

.

~LZ8~3873 operation of PC emulating processor 12. Then, the user selects boot or reboot, and the PC emulator window NotifyRroc calls a boot procedur which uses the data from tke optio~ sheet window data structure to place the emulated fi2ced disk under the control of the PC emulator removing it 5 from the control of host system main processor 20.

On the other hand, if the PC emulator is operating in a configuration including the emulated fixed disk icon 100, the data it contains will be under the control of PC emulating processor 12. In order to transfer control, 10 user 18 similarly selects the "Show Options" command, and the reverse procedure outlined above occurs. Option sheet 136 is set up and user 18 removes ernulated fixed disk 100 from the PC emulator configuration. At this point, control is transferred to host system main processor 20, but the PC emulator is not operating until user 18 again selects boot or reboot.
The E.Yit/Boot technique could be applied to other data structures on the host system hard disk, and is especially useful for transfer of large volumes of data. In contrast, the next technique is more appropriate for relatively small volumes of data not in the form of text, such as graphical data in PC
20 emulation window 124.

3. Freehand Drawing. As described above$ tke freehand drawing application provides a technique for transferring the conten~,s of the bitmap for a selected part of the screen into a special freehand drawing window 25 data structure which can receive bitmap data. This techniq-ue does not re~uire the interruption of PC emulation, because it obtains the data .
. , , . ; . : - , .
.: ' ' .' ', ', .
. .: - ~ . . . . . .
..

~Lf~a~3~73 directly from the bitmap and therefore does not interfere with continuing operation of PC emulating processor 12.

The fireehand drawing window NotifyProc, upon receiving a mouse click on 5 its pop-up menu 211, calls NotifyProc to set up the pop-up menu. Then, if a point up event on pop-up menu 211 is received, NotifyProc calls a procedure corresponding to the location of the cursor 52 on the pop-up menu 211. If the command selected is "Copy Screen". The procedure is CaptureScreenBits, and the Notifier is placed in a special mode in which all 10 keyboard events will go to the freehand drawing window, wherever they occur on desktop 54. As a r~sult, the contents of the display bitmap in the rectangle defined by the point up and the adjust up scan codes at the moment the adjust up scan code is received will be copied to the freehand drawing window data structure by procedure~ called by that window's 15 Noti~yProc.

The result of copying a part of the bitmap memory which covers any portion of PC emulation window 124 will be to trans~er the data displayed there under control of PC emulating processor 12 to the control of the host system 20 main processor 20. so that this too is a t~chnique for transferring control.

Reference is again made to virtual floppy 96 and Figure 17 relative to access of the virtual floppy from eiti.er the PC emulator or from desktop 54. The virtual floppy may be formatted to a filing system such as ~aS-DOS. The 25 virtual floppy may be moved in its iconic form ~or insertion into an emulated fixed drive configured in the PC emulator and its contents accessed by running an l~S-DOS utility or program. When the same virtual ' ;

: . .

~L888'73 floppy is placed on desktop ~4 in the ViewPoint world, its contents may also be accessed, as previously described in connectioz~ with Figure 17B, by employing the < OPEN ~ functio~ on the virtual floppy icon on desktop 54.
A filing system interpreter written in Mesa code interprets the file contents 5 of the virtual floppy for display on desktop 54 when the < OPEN ~ function is invoked.

While the invention has been described in conjunction with a few specific embodiments, it is evident to those skilled in the art that many 10 alte~natives, modifications and variations will be apparent in light of the - foregoing description. Accordingly, the invention is intended to embrace all such alternatives, modifications and variations as fall within the spirit and scope of the appended claims.

:

,: .: ~, . .
,

Classifications
International ClassificationG06F3/06, G06F3/048, G06F3/033, G09G5/14, G06F9/44, G06F13/10
Cooperative ClassificationG06F13/105, G06F3/0601, G06F2003/0694, G06F3/0481, G09G5/14
European ClassificationG06F3/06A, G06F3/0481, G06F13/10E, G09G5/14
Legal Events
DateCodeEventDescription
12 Sep 2005MKLALapsed