WO1999061980A1 - Architecture for executing program code - Google Patents

Architecture for executing program code Download PDF

Info

Publication number
WO1999061980A1
WO1999061980A1 PCT/AU1999/000379 AU9900379W WO9961980A1 WO 1999061980 A1 WO1999061980 A1 WO 1999061980A1 AU 9900379 W AU9900379 W AU 9900379W WO 9961980 A1 WO9961980 A1 WO 9961980A1
Authority
WO
WIPO (PCT)
Prior art keywords
receptor
link
architecture
call message
jump table
Prior art date
Application number
PCT/AU1999/000379
Other languages
French (fr)
Other versions
WO1999061980A8 (en
Inventor
James Christian Ladd
Original Assignee
James Christian Ladd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by James Christian Ladd filed Critical James Christian Ladd
Priority to AU39218/99A priority Critical patent/AU3921899A/en
Publication of WO1999061980A1 publication Critical patent/WO1999061980A1/en
Publication of WO1999061980A8 publication Critical patent/WO1999061980A8/en

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44Arrangements for executing specific programs
    • G06F9/448Execution paradigms, e.g. implementations of programming paradigms
    • G06F9/4488Object-oriented
    • G06F9/449Object-oriented method invocation or resolution
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00Arrangements for software engineering
    • G06F8/60Software deployment
    • G06F8/65Updates
    • G06F8/656Updates while running

Definitions

  • This invention relates to architectures for executing program code.
  • system libraries for example, dynamic link libraries in Microsoft operating systems and shared libraries in Unix-style operating systems
  • Developers are provided information concerning available libraries and, with the aid of an supporting documentation, write new applications for use with the operating system.
  • This approach provides some flexibility in constructing applications as it allows programmers to define functions having the same name but which perform different (though typically similar) processing.
  • the system determines which function to call based on the current parameters provided and the return value expected. This determination is performed either during compilation or at runtime.
  • an object of the invention is to provide a computing architecture for the execution of computer program code which can be more readily modified than the architectures presently available.
  • the invention provides an architectecture for executing program code including:
  • program code objects each having a receptor, and an effector for performing an operation associated with the object, at least one of the objects also having a jump table referencing other objects;
  • the forwarded call message sent to the link object is received by the link object's receptor which instructs the link object's effector to perform an operation associated with that object, upon completion of which the link object's effector returns a response to the link object's receptor, which is then forwarded back to the receiving object.
  • the invention also provides a method of executing program code including:
  • the invention also provides a computer program product including information representing an architecture in accordance with the invention, or able to be installed on a computing system so that a user can cause a method in accordance with the invention.
  • the invention also provides a computing system containing an architecture in accordance with the invention, or when programmed to peform a method in accordance with the invention.
  • a computer program product can include, for example, a CD-ROM or a magnetic or optical storage device.
  • the invention also provides a computing operating system or computing application stored in a memory means of a computing system, or recorded in a computer program product, or transmitted over a network, the operating system or application including an architecture in accordance with the invention, or using a method in accordance with the invention.
  • the jump table of objects can be modified by adding, removing or altering listed objects, thus correspondingly modifying the operations available from the respective object containing the jump table.
  • this modification can be done while the respective object is being used in a functioning application or operating system, that is, there is no requirement for stopping operation of the application or operating system.
  • Embodiments of the invention thus provides an architecture which is dynamically modifiable in a real and effective sense.
  • object jump table contents can be installed after the object is created or while it is running, this modification can be referred to as "training" the object.
  • each object can be considered as having one or more other objects within it, linked through its object jump table.
  • Fig. 1 is a schematic diagram representing the structure of each object of a computer program architecture according to an embodiment of the invention.
  • Figs. 2A to 2E are schematic diagrams representing the principal steps involved in calling up and performing of an operation utilising the preferred architecture of the invention.
  • Figs. 3A to 3G are schematic diagrams representing an exemplary operation as described below.
  • Fig. 1 shows a building unit of a computing architecture according to the invention. This building unit is analogous with an "object" in existing architectures, but is referred to below as an Atom.
  • Atom 10 consists of a Receptor 12, a Jump Table 14, and an Effector 16. All external communication with the Atom is through Receptor 12. An incoming message is called a Receptor Message, and an outgoing response is called a Receptor Response.
  • the Effector 16 is the component of Atom 10 that specifies a method or function to be peformed when instructed by the Receptor 12. Each Atom 10 typically has a single dedicated Effector for performing an operation characteristic of that Atom 10. An Effector can perform no operations if appropriate.
  • a Receptor Message is typically received from another Atom.
  • the calling Atom is termed the Caller
  • the receiving Atom is termed the Receiver.
  • Each Atom maintains a Jump Table which allows the Atom to contact other Atoms as required.
  • Receivers receive information from Callers through the Receiver's Receptor, in the form of a Receptor Message. Information is returned via a Receptor Response.
  • each Atom's Jump Table can be installed after an Atom is created and can be installed or modified while the Atom is running. This is referred to as “learning” or “training” the Atom.
  • the Jump Table 14 is a dynamically modifiable list of other Atoms with which Atom 10 can be linked.
  • Each entry in the Jump Table includes a characteristic segment of program code which is effectively a Message ID (MSG ID) for an Atom with which a link can be made.
  • MSG ID Message ID
  • an Atom's Receptor 12 can receive a Receptor Message called a Call Message, which prompts the Receptor 12 to identify the Atom corresponding with the Call Message in the Atom's Jump Table and to communicate with that Atom.
  • the Effector 16 is enabled by receipt of an Effector Message from the Atom's Receptor when the Receptor receives the Call Message. Once the Effector completes its operations, it returns an Effector Response to the Receptor.
  • a Receiver's Receptor 12 receives a Receptor Message from a Caller.
  • the Receptor Message is a Call Message and includes a Message ID for another Atom (that is, not the Receiver called by the Caller) to perform an operation.
  • the Call Message may include parameter values or arguments related to that operation.
  • Receptor 12 checks the Message ID included in the Call Message against entries in the Jump Table 14.
  • the Receptor communicates with the Atom 10 * identified by the Message ID by forwarding the Call Message to the Receptor 12 * of that Atom identified by the Message ID, together with an effect instruction.
  • the message sent is "Apply to" Message ID.
  • An identifer for the Atom 10 is added at the front of Call Message, which is then forwarded to the link Atom 10 * .
  • the Receptor Response generated by the linked Atom 10 * is in turn returned to Atom 10. (The way in which the Receptor Response is generated by the linked Atom is described below at step 4).
  • a "no such message" receptor response is returned to the calling Atom 10 * .
  • a Receptor Response is always returned, even if there is technically no response, for which case an empty value is returned. If an error occurs during processing, an error response is provided.
  • the Receptor 10 * calls the Effector 16 * with an Effector Message and its Effector Response is returned to the calling Atom 10 via the successive respective Receptors 12* and 12 of the linked Atom and the calling Atom which first received the Call Message.
  • An Effector Response is returned by the Effector 16 * to the Receptor 12 * after it completes operations and is always returned, even if there is, technically no response, in which case an empty value is returned. If an error occurs during processing, an error response is returned.
  • Entries in the Jump Table are modified once the Atom is created, by using the Add Service, Remove Service and Change Service messages listed in the table above. This allows the Atom to respond to other messages after the Atom is created. As described above, these services or messages are set up in the Jump Table which provides links to other Atoms characterised by particular functions or operations. Modification of the Jump Table by way of the modification of available services is performed during the Atom's existence, and can be performed while the Atom is operationally available to users and to a network to which the operating system is attached. Accordingly, this process is referred to as “learning”, or "training" the Atom.
  • Fig. 3A Start sends the Call Message (Main, "Display", 512) to the Main.
  • Fig. 3B Main's Receptor looks for "Display" in Main's Jump Table.
  • Fig. 3C Main's Receptor finds "Display” and forwards the Call Message (Display, "Apply to", Main, 512) to Display.
  • Fig. 3D Display's Receptor sends the Effector Message (Main, Display, 512) to its Effector.
  • Fig. 3E Display's Effector performs its manipulations and returns "512" to Display's Receptor.
  • Fig. 3F Display's Receptor returns "512" to Main.
  • Fig. 3G Main's Receptor returns "512" to Start.
  • Receptor receiverObject, messageId, messageName, argCount, argArray
  • the "main.h” header file preferably defines types and structures appropriate for use by the system.
  • the Receptor is defined as follows:
  • Step 3 An Object is now created. If it is only necessary to integrate an existing application or library with an Object, the function implemented in Step 3 is all that is required. Of course, it is necessary to include details in the stub function to call the functions of your existing application or library.
  • the "message processing" logic determines if the Receiver of the message has a Jump Table. If there is no Jump Table, it is created.
  • the logic determines if the message is the special case "effect”, if it is then the Receiver's Effector is retrieved (via a call to the Receiver's Receptor) and then the Effector service is called. The result is returned to the Caller.
  • Any other message is processed by looking up the "OJT" for an object in the slot indicated by the message identifier "mid”. If an object is found, then the objects Receptor is sent the message "effect” asking the object to call its effector service on the passed parameters. The result of the effect message is returned to the Caller.

Abstract

The invention provides a software architecture which can be dynamically updated witout rebuilding the components of the system. The architecture includes objects, each having receptor for receiving instructions and associated parameters, and returning results, and an effector for performing an operation. At least one of objects (a receiving object) provides the advantages of the invention by including an object jump table listing link objects. When the receiving object receives a call message, the call message is forwarded to the link object if there is a corresponding entry in the receiving object's jump table. The forwarded call message, which is received by the link object's receptor, includes an effect instruction for the link object to operate its effector. Once the link object's effector completes its operation, it returns a response to the link object's receptor, which forwards the response to the receiving object's receptor. The receiving object's jump table can be modified by adding, removing or changing entries once the receiving object is created, and while the receiving object is running, allowing increased flexibility in the use of the described software architecture.

Description

ARCHITECTURE FOR EXECUTING PROGRAM CODE
Field of the Invention
This invention relates to architectures for executing program code.
Background of the Invention
New applications created for existing computer operating systems use system libraries (for example, dynamic link libraries in Microsoft operating systems and shared libraries in Unix-style operating systems) provided as a component of the operating system. Developers are provided information concerning available libraries and, with the aid of an supporting documentation, write new applications for use with the operating system.
This approach provides some flexibility in constructing applications as it allows programmers to define functions having the same name but which perform different (though typically similar) processing. The system determines which function to call based on the current parameters provided and the return value expected. This determination is performed either during compilation or at runtime.
This a program to dynamically determine its operation as it is running, but the available options are fixed, and cannot be changed as the program runs. Modification is only possible by recompilation, thus involving a programmer manually changing the specifications, and rebuilding the system. To implement the changes, the current version of the system must be shut down and then replaced with the updated version. Rigourous testing is required to ensure that the system is functioning correctly. This inflexibility is a significant disadvantage.
Accordingly an object of the invention is to provide a computing architecture for the execution of computer program code which can be more readily modified than the architectures presently available. Summary of the Aspects of the Invention
The invention provides an architectecture for executing program code including:
program code objects, each having a receptor, and an effector for performing an operation associated with the object, at least one of the objects also having a jump table referencing other objects;
wherein if a call message identifying a link object is sent to a receiving object, the receiving object's receptor towards the call message to the link object if the link object is identified in the receiving object's jump table, the forwarded call message including an effect instruction for the link object to operate its effector,
wherein the forwarded call message sent to the link object is received by the link object's receptor which instructs the link object's effector to perform an operation associated with that object, upon completion of which the link object's effector returns a response to the link object's receptor, which is then forwarded back to the receiving object.
The invention also provides a method of executing program code including:
sending a call message to a receiving object's receptor, the call message identifying a link object;
forwarding the call message from the receiving object's receptor to the link object's receptor if the receiving object has an entry which authorises forwarding the call message to the link object, the forwarded call message including an effect instruction for the link object to execute an operation associated with the link object; and
responding to the forwarded call message by executing an operation associated with the link object and returning a response from the link object's receptor to the receiving object's receptor once the link object completes its operation. The invention also provides a computer program product including information representing an architecture in accordance with the invention, or able to be installed on a computing system so that a user can cause a method in accordance with the invention. The invention also provides a computing system containing an architecture in accordance with the invention, or when programmed to peform a method in accordance with the invention. A computer program product can include, for example, a CD-ROM or a magnetic or optical storage device.
The invention also provides a computing operating system or computing application stored in a memory means of a computing system, or recorded in a computer program product, or transmitted over a network, the operating system or application including an architecture in accordance with the invention, or using a method in accordance with the invention.
Preferably, the jump table of objects can be modified by adding, removing or altering listed objects, thus correspondingly modifying the operations available from the respective object containing the jump table. Preferably, this modification can be done while the respective object is being used in a functioning application or operating system, that is, there is no requirement for stopping operation of the application or operating system.
Embodiments of the invention thus provides an architecture which is dynamically modifiable in a real and effective sense. As object jump table contents can be installed after the object is created or while it is running, this modification can be referred to as "training" the object.
Preferably, there are a large number of objects forming the computer program architecture and these are substantially identical in the structure of their program code, differing only in relation to the contents of their respective jump tables and in the operations performed by their effectors. Of course, to implement the invention requires only one object having a jump table, but additional flexibility is achieved by providing further objects with jump tables which can be dynamically modified as noted above. It will be understood that, by virtue of the structure of the architecture, each object can be considered as having one or more other objects within it, linked through its object jump table.
Description of Drawings
Fig. 1 is a schematic diagram representing the structure of each object of a computer program architecture according to an embodiment of the invention.
Figs. 2A to 2E are schematic diagrams representing the principal steps involved in calling up and performing of an operation utilising the preferred architecture of the invention.
Figs. 3A to 3G are schematic diagrams representing an exemplary operation as described below.
Description of Preferred Embodiments
Fig. 1 shows a building unit of a computing architecture according to the invention. This building unit is analogous with an "object" in existing architectures, but is referred to below as an Atom.
Atom 10 consists of a Receptor 12, a Jump Table 14, and an Effector 16. All external communication with the Atom is through Receptor 12. An incoming message is called a Receptor Message, and an outgoing response is called a Receptor Response. The Effector 16 is the component of Atom 10 that specifies a method or function to be peformed when instructed by the Receptor 12. Each Atom 10 typically has a single dedicated Effector for performing an operation characteristic of that Atom 10. An Effector can perform no operations if appropriate.
A Receptor Message is typically received from another Atom. In this case, the calling Atom is termed the Caller, and the receiving Atom is termed the Receiver.
When a Caller sends a Receptor Message to a Receiver, the Caller always receives a Receptor Response. (The Receptor Message does not necessarily come from another Atom, but can emanate from other sources.)
Each Atom maintains a Jump Table which allows the Atom to contact other Atoms as required. As outlined above, Receivers receive information from Callers through the Receiver's Receptor, in the form of a Receptor Message. Information is returned via a Receptor Response.
The contents of each Atom's Jump Table can be installed after an Atom is created and can be installed or modified while the Atom is running. This is referred to as "learning" or "training" the Atom. Thus the Jump Table 14 is a dynamically modifiable list of other Atoms with which Atom 10 can be linked. Each entry in the Jump Table includes a characteristic segment of program code which is effectively a Message ID (MSG ID) for an Atom with which a link can be made.
As described below, an Atom's Receptor 12 can receive a Receptor Message called a Call Message, which prompts the Receptor 12 to identify the Atom corresponding with the Call Message in the Atom's Jump Table and to communicate with that Atom.
The Effector 16 is enabled by receipt of an Effector Message from the Atom's Receptor when the Receptor receives the Call Message. Once the Effector completes its operations, it returns an Effector Response to the Receptor.
These steps are now outlined, with reference to Figs. 2A to 2E.
Step 1 (Fig. 2A)
A Receiver's Receptor 12 receives a Receptor Message from a Caller. The Receptor Message is a Call Message and includes a Message ID for another Atom (that is, not the Receiver called by the Caller) to perform an operation. The Call Message may include parameter values or arguments related to that operation. Step 2 (Fig. 2B)
Receptor 12 checks the Message ID included in the Call Message against entries in the Jump Table 14.
Step 3 (Figs. 2C & 2D)
If the corresponding entry is found, the Receptor communicates with the Atom 10* identified by the Message ID by forwarding the Call Message to the Receptor 12* of that Atom identified by the Message ID, together with an effect instruction. In this case, the message sent is "Apply to" Message ID. An identifer for the Atom 10 is added at the front of Call Message, which is then forwarded to the link Atom 10*.
The Receptor Response generated by the linked Atom 10* is in turn returned to Atom 10. (The way in which the Receptor Response is generated by the linked Atom is described below at step 4).
If the Message ID is not found in the Jump Table (see Fig. 2D), a "no such message" receptor response is returned to the calling Atom 10*. A Receptor Response is always returned, even if there is technically no response, for which case an empty value is returned. If an error occurs during processing, an error response is provided.
Step 4 (Fig. 2E)
If the Message ID is an "Apply To" Message ID, then the Receptor 10* calls the Effector 16* with an Effector Message and its Effector Response is returned to the calling Atom 10 via the successive respective Receptors 12* and 12 of the linked Atom and the calling Atom which first received the Call Message.
An Effector Response is returned by the Effector 16* to the Receptor 12* after it completes operations and is always returned, even if there is, technically no response, in which case an empty value is returned. If an error occurs during processing, an error response is returned.
Turning to more general matters, the Call Messages that an Atom responds to are unique to each Atom, except for a set of Common Messages listed below:
Figure imgf000009_0001
Entries in the Jump Table are modified once the Atom is created, by using the Add Service, Remove Service and Change Service messages listed in the table above. This allows the Atom to respond to other messages after the Atom is created. As described above, these services or messages are set up in the Jump Table which provides links to other Atoms characterised by particular functions or operations. Modification of the Jump Table by way of the modification of available services is performed during the Atom's existence, and can be performed while the Atom is operationally available to users and to a network to which the operating system is attached. Accordingly, this process is referred to as "learning", or "training" the Atom.
Use of a uniform integrated architecture as described above allows a computer system written using the principles of the invention to dynamically add, delete, and change its operations without having to stop, rebuild, test and restart the system.
Example
The following example is briefly set out with reference to Figs. 3A to 3G. It outlines the example of an Atom asked to return a numeric value formatted as a string. The objects involved include the following pre-existing Atoms with the minimum settings indicated in the table below:
Figure imgf000010_0001
The principal steps are as follows:
Fig. 3A Start sends the Call Message (Main, "Display", 512) to the Main.
Fig. 3B Main's Receptor looks for "Display" in Main's Jump Table.
Fig. 3C Main's Receptor finds "Display" and forwards the Call Message (Display, "Apply to", Main, 512) to Display.
Fig. 3D Display's Receptor sends the Effector Message (Main, Display, 512) to its Effector.
Fig. 3E Display's Effector performs its manipulations and returns "512" to Display's Receptor.
Fig. 3F Display's Receptor returns "512" to Main. Fig. 3G Main's Receptor returns "512" to Start.
An example implementation is now described.
A pseudo-code implementation for a Receptor is set out below. The code shows both the interface and the implementation:
Receptor: receiverObject, messageId, messageName, argCount, argArray
The steps involved are:
1. Find class object for "receiverObject" 2. Get service object for message (Id, Name) from class object
3. Apply the service object to "receiverObject"
4. Return result to caller
Similarly, a pseudo-code implementation for an Effector is set out below. The details of course depend on the function to be performed by the Effector.
Effector: receiverObject, serviceObject, argCount, argArray.
The actual implementation for an Object is now described, in relation to the C programming language in the Microsoft Windows™ 95 operating system.
Step 1
Create a Win32 Dynamic Load Library for Microsoft Windows. Microsoft Visual Studio can be used for this purpose.
Step 2
Create a "main.c" source and a "main.h" header file, including suitable definitions for the Receptor. The "main.h" header file preferably defines types and structures appropriate for use by the system. The Receptor is defined as follows:
PUBSVC ObjectGRK PTR rcvr, DTA id, PTR msg, DTA argc, PTR args, PTR xtra )
Step 3
Create a stub function in the "main.c" file for the Receptor, and compile the library. An example stub follows:
PUBSVC ObjectGRI( PTR rcvr, DTA mid, PTR msg, DTA argc, PTR args, PTR xtra ) { return( 0 ) ; } Step 4
An Object is now created. If it is only necessary to integrate an existing application or library with an Object, the function implemented in Step 3 is all that is required. Of course, it is necessary to include details in the stub function to call the functions of your existing application or library.
Step 5
The next thing to implement is the "message processing".
This is done by adding the global variable "Class" to your code "main.c" and other logic as follows:
PTR Class = 0;
PUBSVC ObjectGRI( PTR rcvr, DTA mid, PTR msg, DTA argc,
PTR args, PTR xtra )
{
PTR svc = 0; if ( Class == 0 )
{
/* create class (OJT) */ Class = CreateClassOJT() ; } /* mid is special service "effect" */ if ( mid == effect id )
{
/* get effector and effect. */ svc = (*(GRIP) (*(PTR)rcvr)) (rcvr, effectorMid, 0,0); return( ( (GEIP) svc) (xtra, rcvr, argc, args) ); } else { /* find service for "mid" */ svc = Class [ mid ] ; return( (* (GRIP) (* (PTR)rcvr) ) (rcvr, effectMid, argc, args, rcvr) ); } }
The "message processing" logic determines if the Receiver of the message has a Jump Table. If there is no Jump Table, it is created.
When the "OJT" is created the logic determines if the message is the special case "effect", if it is then the Receiver's Effector is retrieved (via a call to the Receiver's Receptor) and then the Effector service is called. The result is returned to the Caller.
Any other message is processed by looking up the "OJT" for an object in the slot indicated by the message identifier "mid". If an object is found, then the objects Receptor is sent the message "effect" asking the object to call its effector service on the passed parameters. The result of the effect message is returned to the Caller.
Step 6
The function "CreateClassOJT" must now be implemented. It is a matter of design implementation at to how the function is implemented for existing objects, but following is the implementation for the Object":
Note: The implementation above does not encompass the use of "LOAD MAPS", which are externalised definitions used by Objects to describe their interactions with other components, as well as other characteristics. This is not shown as it is not mandatory to be an "Object".
Step 7
Below is example code showing the using the Object" component from a Microsoft Windows 95 application:
/* load library containing object */ HINSTANCE hLib = Load ibrary("Object .dll") ; FARPROC rcptr = GetProcAddress(hLib, "Ob ectGRI") ;
• /* call receptor for object to create a new object instance. */ PTR ans = ( (GRIP) rcptr) ( 0, newMid, 0, 0, 0 );
/* use object instance. */ FreeLibrary(hLib) ;
It will be understood that the invention disclosed and defined in this specification extends to all alternative combinations of two or more of the individual features mentioned or evident from the text or drawings. All of these different combinations constitute various alternative aspects of the invention.

Claims

1. An architectecture for executing program code including:
program code objects, each having a receptor, and an effector for performing an operation associated with the object, at least one of the objects also having a jump table referencing other objects;
wherein if a call message identifying a link object is sent to a receiving object, the receiving object's receptor towards the call message to the link object if the link object is identified in the receiving object's jump table, the forwarded call message including an effect instruction for the link object to operate its effector,
wherein the forwarded call message sent to the link object is received by the link object's receptor which instructs the link object's effector to perform an operation associated with that object, upon completion of which the link object's effector returns a response to the link object's receptor, which is then forwarded back to the receiving object.
2. An architecture as claimed in claim 1 wherein the jump table can be modified by addition, removal or alteration of entries for various link objects.
3. An architecture as claimed in any one of claims 1 or 2 wherein the jump table can be modified while the object is being used by the computing architecture.
4. An architecture as claimed in any one of claims 1 to 3 wherein entries in the jump table are installed after the object is created.
5. An architecture as claimed in any one fo claims 1 to 4 wherein the modification of the jump table can be achieved by using appropriate call messages to the object.
6. An architecture as claimed in any one of claims 1 to 5 wherein the call message originates from a calling object, being one of the program code objects.
7. An architecture as claimed in claim 7 wherein the receiving object's receptor forwards to the calling object the response received from the link object's receptor.
8. An architecture as claimed in any one of claims 1 to 7 wherein each of the program code objects has a receptor, an effector for performing an operation associated with the object, and a jump table referencing other objects, each object differing in relation to the contents of their jump tables and the operations peformed by their effectors.
9. A method of executing program code including:
sending a call message to a receiving object's receptor, the call message identifying a link object;
forwarding the call message from the receiving object's receptor to the link object's receptor if the receiving object has an entry which authorises forwarding the call message to the link object, the forwarded call message including an effect instruction for the link object to execute an operation associated with the link object; and
responding to the forwarded call message by. executing an operation associated with the link object and returning a response from the link object's receptor to the receiving object's receptor once the link object completes its operation.
10. A method as claimed in claim 9 further including modifying the jump table by adding, removing or altering entries for link objects.
11. A method as claimed in any one of claims 9 or 10 wherein the modification can occur while the object is being used.
12. A method as claimed in any one of claims 9 to 11 wherein entries in the jump table can be installed after the object is created.
13. A method as claimed in any one of claims 9 to 12 wherein the modification of the jump table is achieved by using appropriate call messages to the object.
14. A method as claimed in any one of claims 9 to 13 wherein the call message is sent from a calling object, being one of the program code objects.
15. A method as claimed in claim 14 wherein the receiving object's receptor forwards to the calling object the response received from the link object's receptor.
16. A computer program product including information representing an architecture as claimed in any one of claims 1 to 8.
17. A computer program product able to be installed on a computing system so that a user can cause the method as claimed in any one of claims 9 to 15.
18. A computing system containing an architecture as claimed in any one of claims 1 to 8, or when programmed to perform a method as claimed in claims 9 to 15.
19. A computing operating system or computing application stored in a memory means of a computing system, or recorded in a computer program product, or transmitted over a network, the operating system or application including an architecture as claimed in any of claims 1 to 8, or using a method as claimed in any one of claims 9 to 15.
PCT/AU1999/000379 1998-05-22 1999-05-21 Architecture for executing program code WO1999061980A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU39218/99A AU3921899A (en) 1998-05-22 1999-05-21 Architecture for executing program code

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
AUPP3657 1998-05-22
AUPP3657A AUPP365798A0 (en) 1998-05-22 1998-05-22 Architecture for the execution of program code

Publications (2)

Publication Number Publication Date
WO1999061980A1 true WO1999061980A1 (en) 1999-12-02
WO1999061980A8 WO1999061980A8 (en) 2000-03-30

Family

ID=3807907

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/AU1999/000379 WO1999061980A1 (en) 1998-05-22 1999-05-21 Architecture for executing program code

Country Status (2)

Country Link
AU (1) AUPP365798A0 (en)
WO (1) WO1999061980A1 (en)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5406644A (en) * 1987-03-24 1995-04-11 Insignia Solutions, Inc. Apparatus and method for emulating a computer instruction set using a jump table in the host computer
US5615400A (en) * 1993-06-30 1997-03-25 Apple Computer, Inc. System for object oriented dynamic linking based upon a catalog of registered function set or class identifiers
US5623617A (en) * 1993-05-07 1997-04-22 Apple Computer, Inc. Method for decoding sequences of guest instructions for a host computer
US5696956A (en) * 1995-11-08 1997-12-09 Digital Equipment Corporation Dynamically programmable reduced instruction set computer with programmable processor loading on program number field and program number register contents
US5764991A (en) * 1995-06-30 1998-06-09 Canon Kabushiki Kaisha Processing object oriented code and virtual function code

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5406644A (en) * 1987-03-24 1995-04-11 Insignia Solutions, Inc. Apparatus and method for emulating a computer instruction set using a jump table in the host computer
US5623617A (en) * 1993-05-07 1997-04-22 Apple Computer, Inc. Method for decoding sequences of guest instructions for a host computer
US5615400A (en) * 1993-06-30 1997-03-25 Apple Computer, Inc. System for object oriented dynamic linking based upon a catalog of registered function set or class identifiers
US5764991A (en) * 1995-06-30 1998-06-09 Canon Kabushiki Kaisha Processing object oriented code and virtual function code
US5696956A (en) * 1995-11-08 1997-12-09 Digital Equipment Corporation Dynamically programmable reduced instruction set computer with programmable processor loading on program number field and program number register contents

Also Published As

Publication number Publication date
WO1999061980A8 (en) 2000-03-30
AUPP365798A0 (en) 1998-06-18

Similar Documents

Publication Publication Date Title
US7398433B2 (en) System and method of preventing a web browser plug-in module from generating a failure
US7437710B2 (en) Annotation based development platform for stateful web services
US6282580B1 (en) Bridge providing communication between different implementations of object request brokers
US7058955B2 (en) Method and system for passing messages between threads
US6083281A (en) Process and apparatus for tracing software entities in a distributed system
US6636900B2 (en) Method and apparatus for executing distributed objects over a network
US20080120628A1 (en) User interface collaboration framework
US20030005181A1 (en) Annotation based development platform for asynchronous web services
CN110365751B (en) Service processing method, device and equipment of gateway system
US6847987B2 (en) System and method for extending client-server software to additional client platforms for servicing thin clients requests
JP4724660B2 (en) How to manage software components that are integrated into an embedded system
JP3093138B2 (en) Method of operating a data processing system and an encapsulation system
US6591413B1 (en) Method and apparatus in a data processing system for faster notification of errors in a software build
US20060080676A1 (en) Support for multiple interface versions
CN115994004A (en) Application program interface calling method and device
JP2005108082A (en) Interface method for device driver
WO1999061980A1 (en) Architecture for executing program code
US6308226B1 (en) Communication method and system for objects movable in network
Siegel et al. The Cyc System: Notes on Architecture
KR20140049824A (en) System for remotely debugging an application programming and controlling method therefor
CN111949387A (en) Method and device for processing service task and electronic equipment
EP0860776A1 (en) Inter-object communication method
GB2342735A (en) Transferring information between computer programs
CN112783776A (en) Interface routing-based test method and device and electronic equipment
JP2002132502A (en) Automatic creating system and method of distributed object with interpretation of language function

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AL AM AT AU AZ BA BB BG BR BY CA CH CN CU CZ DE DK EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT UA UG US UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW SD SL SZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
AK Designated states

Kind code of ref document: C1

Designated state(s): AE AL AM AT AU AZ BA BB BG BR BY CA CH CN CU CZ DE DK EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT UA UG US UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: C1

Designated state(s): GH GM KE LS MW SD SL SZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

CFP Corrected version of a pamphlet front page
CR1 Correction of entry in section i
REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

NENP Non-entry into the national phase

Ref country code: KR

NENP Non-entry into the national phase

Ref country code: CA

122 Ep: pct application non-entry in european phase