United States Patent [191
`
`Smith
`
`‘
`
`[54] AGENT-BASED MULTITHREADING
`APPLICATION PROGRAMMING
`INTERFACE
`[75] Inventor:
`Curtis‘ A. Smith, West Jordan, Utah
`[73] Assignee: Park City Group, Inc., Park City,
`Utah
`[21] Appl. No.: 88,825
`[22] Filed:
`Jul. 8, 1993
`
`[51] Int. Cl.6 ............................................ .. G06F 13/00
`[52] US. Cl. ........................... .. 395/650; 364/DIG. 1;
`364/2843; 364/281.3; 364/281.7
`[58] Field of Search .............................. .. 395/700, 650
`[56]
`References Cited
`U.S. PATENT DOCUMENTS
`
`5,095,522 3/1992 Fujita ct a1. ....................... .. 395/200
`5,265,206 11/1993 Shackclford et a1. ........ .. 395/155
`5,305,461 4/1994 Fcigeubaum et al. ........ .. 395/775
`5,327,529 7/1994 Fults et al. ................ .. 395/155
`5,347,633 9/ 1994 Ash?eld et a1. ................... .. 395/200
`
`OTHER PUBLICATIONS
`Zinc Interface Programmers Guide, Ver. 3.0 Published
`1990-92 by Zinc Software Inc., 405 South 100 East 2nd
`‘ Flr, Pleasant Grove, Utah 84062.
`Primary Examiner-Kevin A. Kriess
`Assistant Examiner--St. John Courtenay, III
`
`US005421013A
`Patent Number:
`[11]
`[45] Date of Patent:
`
`5,421,013
`May 30, 1995
`
`Attorney, Agent, or Firm-Fenwick & West
`[57]
`ABSTRACT
`An application programming interface facilitates devel
`opment of portable, multithreaded application pro
`grams. An application is a collection of instances of
`agent classes. Agent classes are organized in class hier
`archies because new subclass agents may be derived
`from existing base class agents. Each agent class has its
`own message dispatching function; this allows the appli
`cation programmer to alter the message passing frame?
`work provided by the application programming inter
`face. Each agent instance within the program is inde
`pendent because it is a sub-process aware only of its
`own data and context. Multithreading is provided by
`the application programming interface which contains a
`master dispatcher process non-preemptively allocating
`time to individual agents. Therefore, an application’s
`multithreading capability is independent of the plat
`form’s operating system. In addition, a thread of execu
`tion may be split when the currently activated agent
`activates the master dispatcher. The application pro
`gramming interface mediates between the system re
`sources and the application, and maps the user interface
`of the application to the platform’s chosen user inter
`face. Therefore, the application and its user interface
`are portable.
`
`19 Claims, 10 Drawing Sheets
`
`Page 1 of 17
`
`GOOGLE EXHIBIT 1023
`
`

`

`US. Patent
`
`May so, 1995
`
`Sheet 1 of 10
`
`5,421,013
`
`Computer
`Memory
`Operating System Process
`Agency Application
`
`100
`110
`109
`107
`
`115 '
`
`108
`Master Dispatcher
`
`AWAPM"
`Programming Interface
`
`A
`
`101
`CPU
`
`‘
`
`'
`
`‘
`
`103
`Network
`
`104
`Hard Disk
`
`FIGURE 1
`
`105
`Keyboard ‘
`
`11o
`Mouee
`
`114
`Agent n-1
`
`we
`Screen
`
`102
`Printer
`
`‘
`
`‘
`
`Page 2 of 17
`
`

`

`US. Patent
`
`May 30, 1995
`
`Sheet 2 of 10
`
`5,421,013
`
`_
`A8,“
`MessageQueue
`
`114
`111
`208
`
`l-_——H Massage Q_l
`
`20B
`Message
`
`208
`Message
`
`2°‘ .__I
`Message
`
`I 1
`
`201
`MaageQueuePomm- '
`
`113
`MesageProoesao:
`
`112
`
`'2“
`Mesagel’rwhm?m
`Puma:
`
`W
`
`511?...
`v
`'4 Manse
`PM
`(button)
`
`~ Message Dispatcher ‘_ MeaageDnspatcherI-‘mhm
`Pointer
`
`'
`
`L Sagas
`209 m» m
`
`210
`V
`Subclass Dntl (window)
`
`211
`Subclass Data (button)
`
`212
`User om (optional)
`
`(wmdow)
`+
`
`2“
`Subclass
`M
`Pmeaaor
`2
`“8'” )
`
`FIGURE 2
`
`Page 3 of 17
`
`

`

`US. Patent
`
`May so, 1995
`
`Sheet 3 of 10
`
`5,421,013
`
`an:
`Enter appliation's main
`functim
`
`09mm
`
`i
`1. $4
`
`Imtmtiate/crah agents
`to run in m
`
`Retum from
`application
`
`FIGURE 3
`
`Page 4 of 17
`
`

`

`US. Patent ‘
`
`May 30, 1995
`
`Sheet 4 of 10
`
`5,421,013
`
`402
`Save agency application
`context
`
`Select an agent to
`activate
`
`404
`Restore agency
`application context
`
`407
`Call selected agent's
`message dispatcher
`function
`
`i 408
`
`Distribute system evens
`*0 IPPmP?m Isms’
`message qumes
`
`FIGURE 4
`
`Page 5 of 17
`
`

`

`US. Patent
`
`May so, 1995
`
`Sheet 5 of 10
`
`5,421,013
`
`FIGURE 5
`
`Page 6 of 17
`
`

`

`US. Patent
`
`May 30, 1995
`
`‘Sheet 6 of 10
`
`5,421,013
`
`Does mange
`apply to this agent
`class?
`
`FIGURE 6
`
`Page 7 of 17
`
`

`

`US. Patent
`
`May so, 1995
`
`Sheet 7 of 10
`
`5,421,013
`
`FIGURE 7A I
`
`FIGURE 78
`
`Page 8 of 17
`
`

`

`US. Patent
`
`May so, 1995
`
`Sheet 8 of 10
`
`5,421,013
`
`FIGURE 8
`
`Page 9 of 17
`
`

`

`‘US. Patent
`
`May 30, 1995
`
`Sheet 9 of 10
`
`5,421,013
`
`FIGURE 9
`
`Page 10 of 17
`
`

`

`US. Patent
`
`May 30, 1995
`
`Sheet 10 of 10
`
`5,421,013
`
`FIGURE 10
`
`Page 11 of 17
`
`

`

`1
`
`5,421,013
`
`AGENT-BASED MULTITHREADING '
`APPLICATION PROGRAMMING INTERFACE
`
`5
`
`15
`
`25
`
`35
`
`BACKGROUND OF THE INVENTION
`1. Field of the Invention
`This invention relates to the ?eld of application pro
`gramming interfaces, and, more particularly to a system
`and method of writing portable multithreaded applica
`tion programs by creating and combining independent
`agents.
`2. Description of the Related Art
`An application programming interface provides a
`method for programmers to write application programs
`that run on a particular hardware system. Typically an
`application programming interface is customized to run
`on a particular hardware platform. An application pro
`gramming interface provides system calls to perform
`certain hardware dependent functions such as getting
`keyboard input or writing to disk. An application pro
`gramming interface also provides calls for an applica
`tion to interface to the platform’s user interface, for
`example, a call to open a window. Therefore, the appli
`cation programmer can use the calls provided by the
`application programming interface for performing
`hardware dependent and user interface functions. This
`saves the application programmer the time involved in
`writing hardware dependent and user interface func
`tions; the application programmer need only write the
`code speci?c to the application, and may rely on the
`calls provided by the application programming inter
`face to perform system related fimctions.
`An application program written for a speci?c appli
`cation programming interface cannot be ported to an
`other platform with a different application program
`ming interface without replacing all of the system calls
`for the original application programming interface. It
`takes a programmer additional time to rewrite these
`sections of the application program. After the system
`calls are replaced, the application program is recom
`40
`piled. It will then run on the platform with the different
`application programming interface. However, after the
`changes are made, the application program will then
`have the user interface look and feel of the program
`ming interface on the new system. The same application
`program looks different on two different systems be—
`cause the systems have different user interfaces.
`Furthermore, most application programming inter
`faces do not provide multithreading. Multithreading
`allows an application program to contain more than one
`stream of execution; each stream of execution is a
`' thrmd. Typically, each thread performs a di?'erent
`function within the application program; for example
`one thread ?lls a buffer, and another thread reads from
`the buffer. The application programmer must then rely
`on the multithreading provided by the operating system
`on the platform. Some operating systems may not pre
`vide any multithreading at all.
`In addition, application programming interfaces pro
`vide a scheme for sending messages among components
`60
`of an application program. For example, when a charac
`ter is entered at the keyboard, a message may be sent to
`a window telling the window to display the character.
`Typically an application programmer cannot modify
`the message passing framework provided by the appli~
`65
`cation programming interface. As a result, the code for
`message passing must be modi?ed when an application
`program is ported to a platform with a different applica
`
`45
`
`2
`tion programming interface. It takes the programmer
`additional time to replace the message passing code.
`An application programming interface may or may
`not be written in an object-oriented language. If the
`application programming interface is written in an ob
`ject-oriented language, then the application program
`mer may de?ne classes and class hierarchies as speci?ed
`in the object-oriented programming language. Each
`class may have some functions associated with the data
`in the class. In a class hierarchy, classes are organized in
`chains from the general to the more speci?c. A more
`speci?c subclass is derived from a more general base
`class. For example, if a dialog box were a type of win
`dow, then the dialog box subclass would be derived
`from the more general window base class.
`Application programming interfaces written in ob
`ject-oriented programming languages have the advan
`tage of allowing the more speci?c class to maintain its
`own data and context and relying on the base class to
`maintain the general data and context. Therefore, a
`programmer can reuse code which saves time and can
`write a more consistently organized program because
`there is less duplicate code. Each class is independent of
`other classes, even a subclass is independent of its base
`class(es), because the class does not need to know about
`the other classes’ data.
`Application programming interfaces that are written '
`in object-oriented languages have the disadvantage of
`generating larger programs that require more memory
`to run. In addition, the application programmer must
`have a compiler for the object-oriented language to
`compile the application program. Furthermore, the
`application programmer must know the object-oriented
`language and be familiar with object-oriented program
`ming.
`>
`
`SUMMARY OF THE INVENTION
`In accordance with the present invention, there is
`provided a system and method of creating application
`programs using an application programming interface.
`The application programs are multithreaded, portable
`to other existing application programming interfaces,
`and composed of independent agents. Although the
`application program is not written in an object-oriented
`programming language, the agents may be organized
`into class hierarchies, similar to objectoriented class
`
`structures.
`
`_
`
`The present invention includes an application pro—
`gramming interface wherein application programs in
`clude a collection of agents. An agent is an instance of
`a particular agent class. Agent classes are de?ned by the
`application programmer. Because new subclass agents
`may be derived from existing base class agents, the
`agency application programming interface provides
`class hierarchies.
`Each agent has three distinct components: a message ‘
`queue, message dispatcher, and message processor. An
`instance of an agent subclass can have a different mes
`sage dispatcher and message processor than an instance
`of its base class. Because each agent instance has its own
`message dispatcher and message processor, each agent
`is aware of its own data and context. The application
`programming interface is an “agency” which mediates
`between the collection of agents that form the applica
`tion and the platform’s shared system resources. The
`agency communicates with an individual agent through
`its message queue. The agent processes the messages on
`
`Page 12 of 17
`
`

`

`5
`
`20
`
`25
`
`30
`
`35
`
`5,421,013
`3
`4
`its queue using its message dispatcher and its message
`municate with an agency application program running
`processor.
`on a platform with OS/ZTM without a conversion of
`In addition, each agent is a separate sub-process
`the messages that are passed.
`'
`within an application program created by using the
`The present invention also provides classes and class
`agency application programming interface. The agency
`hierarchies in an application programming interface
`application programming interface contains a master
`written in a non-object-oriented language. Because a
`dispatcher which maintains a list of agents. The master
`subclass agent class can be derived from a base agent
`dispatcher selects an agent to activate and activates the
`class, the agency interface provides a method for creat
`selected agent by calling its message dispatcher. When
`ing ‘independent classes of agents which may be hierar
`the selected agent is through performing its agency
`chically related to each other. By using the agency
`application programming interface, application pro
`application function it designates itself as inactive. After
`the agent has designated itself inactive, the master dis
`grammers have the benefits of these features without
`patcher resumes running and then selects the next agent
`having to learn an object~oriented programming lan
`to activate.
`guage and without being familiar with object-oriented
`The current thread of execution may be split when
`programming. In addition, a compiler for the object-ori
`the currently active agent activates the master dis
`ented language is not required and smaller programs
`patcher by calling the master dispatcher. The current
`which require less memory to run are generated. There
`thread is then suspended until it is reactivated by the
`fore, this programming interface is ideal for application
`master dispatcher. The master dispatcher reactivates
`programmers who want to write application programs
`the suspended thread when it is noti?ed that it should
`with class hierarchies in a non-object-oriented program
`reactivate the thread that was suspended prior to its
`ming language, to run on a system with less memory
`being called.
`than is necessary to run object-oriented programs.
`The present invention provides an application pro
`gramming interface for creating multithreaded applica
`tion programs. Since the master dispatcher allocates
`time among the application program’s agents, the
`agency application programming interface provides
`non-preemptive multithreading. Furthermore, the
`agency application programming interface provides a
`means for splitting the currently activated thread and
`suspending it until it is reactivated. A multithreaded
`application program that uses the agency programming
`interface’s multithreading capability does not have to be
`written to conform to the multitasking provided by the
`platform’s operating system. Therefore, an agency ap
`plication program can be ported to a new platform
`without having to rewrite code so that the application
`program conforms to the new platform’s multitasking
`capabilities.
`Because the agency interface mediates between the
`platform’s shared system resources and an application
`program’s agents, programs created using the agency
`application programming interface can be ported to a
`platform with a different programming interface with
`out the need to replace system dependent code. This
`saves the programmer the time necessary to rewrite
`code. For example, an agency application program
`written to run on a platform with Windows TM could
`be recompiled to run a platform with OS/2 TM without
`the need to rewrite portions of the code. In addition, the
`look and feel of the agency application program’s user
`interface can be ported to the new platform. The user
`interface of the ported version of the agency application
`program does not have to be modi?ed to comport with
`the user interface on the new platform. For example,
`the version of an agency application program that runs
`on Windows'rM could have the same user interface
`look and feel and the version of the same agency appli
`cation program that runs on 08/2 TM.
`Furthermore, since each agent has its own message
`dispatcher, an application programmer may alter the
`message passing framework provided by the agency
`programming interface. This allows an agency applica
`tion program running on one platform to communicate
`with an agency application program running on a differ~
`65
`ent platform with a di?‘erent application programming
`interface. For example, an agency application program
`running on a platform with WindowsTM could com
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`FIG. 1 is a block diagram of apparatus for practicing
`the present invention.
`FIG. 2 is a block diagram of the preferred method of
`de?ning an agent according to the present invention.
`FIG. 3 is a ?ow chart showing operation of an
`agency application program according to the present
`invention.
`FIG. 4 is a ?ow chart showing operation of the mas
`ter dispatcher according to the present invention.
`FIG. 5 is a ?ow chart showing sample operation of an
`agent’s message dispatcher according to the present
`invention.
`FIG. 6 is a flow chart showing sample operation of an
`agent’s message processor according to the present
`invention.
`FIG. 7A is a ?ow chart showing the creation of an
`agent class resource according to the present invention.
`FIG. 7B shows agent class resource structure.
`FIG. 8 is a flow chart showing sample operation of an
`agent’s constructor function according to the present
`
`45
`
`50
`
`55
`
`60
`
`invention.
`
`I
`
`.
`
`FIG. 9 is a ?ow chart showing agent creation in an
`agency application program according to the present -
`invention.
`FIG. 10 is a flow chart showing agent destruction in
`an agency application program according to the present
`invention.
`
`DESCRIPTION OF THE PREFERRED
`EMBODIMENT
`Referring now to FIG. 1, there is shown a functional
`block diagram of apparatus 100 for practicing the cur
`rent invention. In the preferred embodiment, the central
`processing unit (CPU) 101 performs the steps of the
`method, although any type of processor or multiple
`processors may be used. The agency application 107
`resides in memory 110 while the agency application 107
`is running. The agency application 107 may reside on
`hard disk 104 or any other storage device when the
`agency application 107 is not running. In the preferred
`embodiment, an agency application 107 runs as an oper
`ating system process 109.
`Referring now to FIG. 1, the agency application 107
`is linked with the agency application programming
`
`Page 13 of 17
`
`

`

`5,421,013
`5
`interface (API) 115 and therefore, the agency API 115
`is part of the agency application 107. The master dis
`patcher 108 is part of the agency API 115.
`_
`An agency application 107 consists of one or more
`agents 114 Referring now to FIG. 2, each agent 114 in
`the agency application 107 contains three main parts: a
`message queue 111, a message dispatcher 112, and a
`message processor 113. In addition, the agent 114 con
`tains various pointers and data structures. The master
`dispatcher 108 is part of the agency API 115, and main
`tains a list of the agents in the agency application 107.
`The message processor 113 is used by the agent 114 to
`communicate with the agency API 115 and to commu
`nicate with other agents 114. An agent communicates
`by making calls to the agency API 115.
`The agency API 115 supports multithreading because
`the master dispatcher 108 allocates time among the
`agents 114 within the agency application 107. Each
`agent 114 is a sub-process within the agency application
`process. The master dispatcher 108 activates an agent
`20
`114 by calling the agent’s message dispatcher 112. The
`message processor 113 is the means by which the agent
`114 performs its application function. When the acti
`vated agent 114 has completed performing its agency
`application function, it designates itself as inactive.
`25
`When an agent 114 designates itself inactive, the master
`dispatcher 108 resumes and selects another agent 114 to
`activate. The agency API 115 provides non-preemptive
`multithreading by allocating its time slice among the
`agents 114 in the agency application 107. This is how
`30
`the agency API 115 provides multithreading that is
`independent of the hardware platform’s multithreading
`capabilities.
`An agent 114 also contains a message queue pointer
`201 that points to its message queue 111. The message
`queue 111 consists of a list of messages 208. An agent
`114 also contains a message processor function pointer
`203 that points to its message processor 113 and a mes
`sage dispatcher ?mction pointer 207 that points to its
`message dispatcher 112. The agent 114 contains agent
`data 209. Ifthe agent class is derived from another agent
`base class then the agent 114 may contain additional
`subclass data 210. For example, if a button agent class is
`derived from a window class agent, the button agent
`contains window data and button subclass data.
`By de?ning new agent classes, an application pro~
`grammer may create a custom user interface for the
`agency application 107. Because the agency application
`user interface is created from agents 114, the user inter
`facecanbeportedtoaplatformwithadi?'erenttypeof 50
`user interface. Consequently, an agency application 107
`running on Windows TM can have the same user inter
`face look as the version of that agency application ~107
`running on XWindows. The agency application’s user
`interface does not have to be modi?ed to comport with
`the platform’s user interface. So, the versions of the
`same agency application 107 for different platforms can
`have the same user interface.
`Referring now to the flow chart of FIG. 3, there is
`shown a preferred method of running an agency appli
`cation 107. In the preferred embodiment, the steps
`shown in FIG. 3 are performed by the CPU 101. First,
`the CPU 101 enters the agency application’s 107 main
`?mction 302. The CPU 101 then opens the agency 303.
`In this step 303, any platform speci?c operations that
`must be completed so that the agency application 107
`can run are performed. For example, system resources
`are allocated and structures necessary for the agency
`
`6
`The CPU
`API 115 to manage agents 114 are
`101 then creates agents 114 that are part of the agency
`application 304; starts the master dispatcher 305; and
`then closes the agency 306. In this step 306, system
`resources are deallocated and any platform speci?c
`operations that were performed in order for the agency
`application 107 to run are reversed. Finally the CPU
`101 returns from the application 307.
`Referring now to the flow chart of FIG. 4, there is
`shown a preferred method of API multithreading. In
`the preferred embodiment, the steps shown in FIG. 4
`are performed by the CPU 101. First the CPU 101 saves
`the agency application context 402. The agency appli~
`cation context includes which agent 114 is currently
`activated, which agent 114 currently receives keyboard
`105 input and which agent 114 currently receives mouse
`input. The CPU 101 then checks if the agency active
`?ag is true 403. If the agency active ?ag is not true, the
`CPU 101 restores the agency application context 404
`and returns 406.
`If the agency active ?ag is true, the master dispatcher
`108 selects an agent 114 to activate 405 and then calls
`the selected agent’s message dispatcher 407. The se
`lected agent 114 is activated and runs until it has com
`pleted its agency application function. When the se
`lected agent designates itself as inactive, the master
`dispatcher 108 resumes and distributes system events to
`the appropriate agents’ message queues 408. This is how
`the agency API 115 mediates between the agency appli
`cation 107 and system resources. The agency applica.
`tion 107 is portable because it does not make direct
`system calls. However, an agent’s 114 message dis
`patcher 112 may directly access system resources. This
`makes the agency API 115 ?exible.
`,
`A thread of execution can be split when the currently
`activated agent 114 activates the master dispatcher 108
`by calling the master dispatcher 108. The current
`agent’s thread is then suspended until the master dis
`patcher 108 reactivates the thread. The master dis
`patcher 108 resumes running and selects an agent to
`activate. The master dispatcher 108 may select the
`agent 114 whose thread was previously suspended. The
`master dispatcher 108 is noti?ed, by a call to the agency
`API 115 that sets the agency active ?ag to false, that it
`should stop the selection and activation of agents, and
`reactivate the thread that was suspended prior to the
`call to the master dispatcher 108. When the master
`dispatcher 108 determines that the agency active flag is
`false 403, it restores the agency application context 404
`and returns 406. The suspended agent thread is thereby
`reactivated.
`Referring now to FIG. 5, there is shown a ?ow chart
`of an example of the operation of an agent’s message
`dispatcher 112. In the preferred embodiment, the steps
`shown in FIG. 2 are performed by the CPU 101. The
`CPU 101 checks if the agent 114 is running 502. If the
`agent 114 is not running it returns 503 and the agent 114
`is designated as inactive. The CPU 101 then checks if
`the agent 114 is yielding its time 504; if the agent 114 is
`yielding its time, the CPU 101 returns 503. The CPU
`101 then checks if a message exists in the message queue '
`505. If there are no messages 208 in the message queue
`111, the CPU 101 returns 503.
`If there is a message 208 in the message queue 111, the
`message 208 is dispatched 506 to the agent’s message
`processor 113. The CPU 101 then releases the memory
`for the message 507 and may perform optional addi
`tional work 508 before checking if the agent 114 is
`
`55
`
`65
`
`35
`
`45
`
`Page 14 of 17
`
`

`

`15
`
`20
`
`25
`
`30
`
`35
`
`5,421,013
`7
`running 502 again. An agent’s message dispatcher 112
`may do what an application programmer chooses for it
`to do. Therefore, the agency API 115 is ?exible. The
`only requirement is that at some point the agent’s 114
`message dispatcher 112 designates itself inactive so that
`the master dispatcher 108 can resume.
`The agent’s message dispatcher may be written dif
`ferently than the example message dispatcher 112. For
`example an agent’s message dispatcher 112 could be
`written so that the agent 114 has three message queues
`or so that the agent 114 takes messages 208 from an
`other agent’s message queue 113. An agent may collect .
`information from other sources besides its own message
`queue 113. This allows the application programmer to
`alter the message passing framework provided by the
`agency API 115. Therefore, an agency application 115
`running on one platform can communicate with an
`agency application 115 running on a different platform
`with a different operating system without converting
`the message passing code.
`Referring now to FIG. 6, there is shown a flow chart
`of an example of the operation of an agent’s message
`processor 113. In the preferred embodiment, the steps
`shown in FIG. 6 are performed by the CPU 101. First
`the CPU 101 checks if the message 208 applies to the
`agent class 602. If the message 208 does not apply to the
`agent class, the CPU 101 relays the message to the base
`class 605 by calling the base class message processor 113
`and then returns 606.
`If the message 208 applies, the message processor 113
`processes the portion of the message 208 that applies to
`the agent’s speci?c class data 603. The CPU 101 then
`checks if the agent’s base class needs the message 604. If
`not, the message processor 113 returns 606. If the base
`class needs the message 208, the message 208 is relayed
`to the base class 605 by calling the base class message
`processor 113. This is how each agent 114 subclass
`remains independent of its base class(es). The agent’s
`114 message processor only has to update its speci?c
`subclass data 210; it then calls the base class message
`40
`processor 113 to update the general base class data. The
`CPU 101 then returns 606.
`Referring now to FIG. 7A, there is shown a ?ow
`chart for an agent’s resource constructor function. FIG.
`7B shows the agent class resource 706, which provides
`the programmer with the ability to modify the de?ni
`tion of an agent 114 without changing the agency appli
`cation code. The agency class resource 706 contains
`information 707, 708,709, 710 necessary to create an
`agent instance. In the preferred embodiment, the steps
`shown in FIG. 7 are performed by the CPU 101. Agents
`114 are created 304 after the agency is opened 303.
`Agents also can be created before the master dispatcher
`is started 305 and can be created by an agent’s message
`processor 113.
`Creating or loading an agent class resource 706 is part
`of the process of creating an agent instance. First the
`agent’s structure and data are de?ned through the cre
`ation or de?nition of an agent class resource 706. If an
`agent class resource 706 exists, it is loaded into memory
`60
`110. To create an agent class resource 706, the CPU 101
`calls the class resource constructor function. Each class
`resource constructor function follows these basic steps.
`First, the CPU 101 checks 702 if resource memory 110
`is provided. If memory 110 is not provided, the CPU
`65
`101 returns 705. If memory 110 is provided, the CPU
`101 calls the agent’s base class resource constructor
`function 703 and then assigns the agent’s speci?c class
`
`8
`.
`data to the resource 704. The CPU 101 then returns 705.
`Once the agent class resource 706 has been created or
`loaded, it is used to create one or more agent instances.
`Referring now to FIG. 8, there is shown a ?ow chart
`for an agent’s constructor function. In the preferred
`embodiment, the steps shown in FIG. 8 are performed
`by the CPU 101. First the CPU 101 calls the agent’s
`base class constructor 802. Every agent has at least one
`base class because the agent class is a base class of all
`agents. The CPU 101 then transfers speci?c class re
`source data to the agent structure 803. For example, if a
`button agent class is a subclass of a window agent class,
`the window agent’s constructor is called and then the
`button agent’s resource data is transferred into the but
`ton agent’s subclass data 211.
`Next, the CPU 101 assigns the agent its class’ message
`processor 804 and returns 805. Every agent class has a
`constructor function of this form. Each agent class
`remains independent because each agent 114 only trans
`fers speci?c class data and'relies on the base class con
`structor function to transfer the general'class data.
`Referring now to FIG. 9, there is shown a ?ow chart
`for the placement of an agent 114 in its context. This is
`the next step in the creation of an agent instance. The
`agent’s context is its position relative to other agents 114
`in the agency application 107. An agent has parents,
`siblings, and children, which are set to de?ne its posi
`tion within the agency application 107. For example, if
`there are currently four window agents 114 open and
`displayed in the agency application 107, then the win
`dows may overlap each other on the screen 106. Each
`level of overlap is a layer on the screen 106. The parent,
`children, and sibling pointers indicate which agents are
`in the layer behind, in the layer in front of, and in the
`same layer as the window agent 114.
`In the preferred embodiment, the steps shown in
`FIG. 9 are performed by the CPU 101. First the CPU
`101 calls the agent constructor function 902. The CPU
`101 then assigns a message dispatcher 112 to the agent
`903. Next the CPU 101 assigns the agent to its parent
`904, attaches the agent to its appropriate agency lists
`905, and sends a construct message for immediate re
`sponse 905 to the agent 114 In response to a construct
`message, an agent 114, if necessary, allocates and initial
`izes any class speci?c instance data or storage space.
`The CPU 101 then returns the agent 907. After each
`agent 114 is created and initialized 304 the agency mas
`ter dispatcher is started 305 and the agency application
`107 runs until the master dispatcher 108 returns.
`Referring now to FIG. 10, there is shown a ?ow
`chaff for the destruction of an agent instance. All agents
`114 are destroyed before the agency application 107 has
`completed execution; however agents 114 can be de
`stroyed at any time during the execution of the agency
`application 107. In the preferred embodiment, the steps
`shown in FIG. 10 are performed by the CPU 101.
`The CPU 101 ?rst sends a destruct message for imme
`diate response 1002 to the agent 114. The CPU 101 then
`destroys children agents 1003; releases allocated system
`resources 1004 including pending messages 208; re
`moves the agent from the agency lists 1005 including
`the multithreading list maintained by the master dis
`patcher 108; and ?nally releases memory 110 for the
`agent instance 1006 before returning 1007.
`What is claimed is:
`1. A system for implementing an agent-bas