Data processor that customizes program behavior by using a resource retrieval capability

Description Submit all comments and votes

CROSS REFERENCE TO RELATED APPLICATIONS

The present patent application is related to a U.S. patent application to Dana Khoyi, et al., titled DATA INTEGRATION BY OBJECT MANAGEMENT, Ser. No. 088,622 filed Aug. 21, 1987, now U.S. Pat. No. 5,206,951.

FIELD OF THE INVENTION

The present invention relates to customizable computer systems, in particular, to systems with mechanisms for sharing data resources among different programs.

BACKGROUND OF THE INVENTION

There are a number of major, general problem areas which recur in data processing systems and these problem areas are growing increasingly demanding in contemporary systems as the range of types of data and information processing applications and numbers and types of users grow. These areas include, in particular, the integration of applications and data in a uniform system and environment, the ability to add new applications and data types to an existing system in a manner to integrate the new applications and data types with existing applications and data types; the ability to update applications and, in particular, the ability to translate programs and data from one language to another as business interests and data applications become international in scope; the ability of different users to share data, and in particular data in a timely form so that each user has the most recent version of a particular body of data; and the ability to transfer or exchange data from one form or data structure to another.

A user may want to include a graph in a document. One existing way to provide the ability for the user to edit the graph from within the context of the document is to augment a document editor with graph editing capabilities. This approach has the disadvantage that in order to integrate a further new type of data (e.g., a voice annotation) into documents, it is necessary to again modify the document editor. In fact, each editor must be separately extended to handle each new type of data.

While certain systems of the prior art have attempted to solve these problems, for example, by constructing object based systems wherein all data types reside in standardized data structures referred to as "objects", the systems of the prior art have generally failed to adequately solve these problems. In particular, the systems of the prior art have generally fallen into one of two classes. In the first and older class of system, there has been little constraint upon data types and applications programs with the result that, while it is easy to add new applications and data types, it is difficult to provide an integrated system and user environment and very difficult to communicate data between users and data types. In the second and more recent class of system, such as the object based systems, there has been an attempt to provide a defined system environment. This approach provides an integrated system and user environment which facilitates the ability to communicate between users and data types. A recurring problem with this class of system, however, is that the system definition itself, and the operating system type programs necessary to manage defined and object based systems inhibits the ability to add new applications and data types if they do not fit within the applications and data types initially envisioned and defined.

SUMMARY OF THE INVENTION

The system of the present invention includes a structure and mechanism for storing and executing programs which allows the programs to be customized, updated and modified, for example, translated into other languages, with minimum disruption to the program and reduced effort. In this regard, a program of any type may be regarded as being comprised of the executable code and of data which is used by the executable code but which is not itself executed. Examples of such data may include icons, language dependent text, messages, text fonts, forms, date and time and presentation formats. In the present system, a program's executable code and the program's data are separated, with the program's executable code residing in a program object or file and the program's data residing in a resource. A resource is a block of data which is used by the executable code of a program but which is not stored as a part of the program's executable code. A resource object is therefore a means for storing such program data separately and independently from the program with which it is associated. While the concept of resources is not limited to object based systems, in the present system all resources are stored in objects, as are all forms of data, and corresponding object managers are provided to operate upon the resource objects, so that the resources may be easily created and resource data easily modified.

The present invention includes a mechanism by which customized versions of resources are automatically substituted for standard resources when an appropriate customized resource exists. Programs of all types are designed to rely on the content of resources to control many different aspects of the behavior of the programs. When a customized resource is automatically substituted for a standard resource, a program using the resource behaves in a customized way. Thus, customization is made possible by using a single resource retrieval capability.

Other features, objects and advantages of the present invention will be understood by those of ordinary skill in the art after reading the following descriptions of a present implementation of the present invention, and after examining the drawing, wherein:

BRIEF DESCRIPTION OF THE DRAWING

FIGS. 1A, 1B, and 1C are diagrammatic representations of information processing systems which may incorporate the present invention;

FIG. 2 is a diagrammatic representation of a system database of the present invention;

FIG. 3 is a diagrammatic representation of an object manager table of the present invention;

FIG. 4 is a diagrammatic representation of an object prototype table of the present invention;

FIG. 5 is a diagrammatic representation of an object catalog of the present invention;

FIG. 6 is a diagrammatic representation of an object table of the present invention;

FIG. 7 is a diagrammatic representation of a link table of the present invention;

FIG. 8 is a diagrammatic representation of various data structures involved in links of the present invention;

FIG. 9 is a diagrammatic representation of a data exchange of the present invention, including a matchmaker of the present invention;

FIGS. 10A and 10B are diagrammatic representations of a resource and a resource editor of the present invention;

FIG. 10C illustrates the relationship between a utility program and the data with which it operates; the utility program creates program header files based on information in resource files.

DETAILED DESCRIPTION

The following description presents the structure and operation of a computer system incorporating a presently preferred embodiment of the present invention.

OUTLINE OF DETAILED DESCRIPTION

1 Concepts

1.1 Objects and Object Managers

1.1.1 An Object Type: Folder

1.2 Links

1.3 Profiles

1.4 Resources

1.5 Operating System and Routine Packs

2 Architectural Overview

3 Objects and Files

4 Data Integration

4.1 Appearance to User in Destination Object

4.2 An Example Illustrating Certain Data Integration Concepts

5 Links

5.1 Link Updating

5.1.1 When Do Updates Occur?

5.1.2 A Link Update Operation May Require Recursion

5.2 Copying Data Having Embedded Links

5.3 Link Markers

5.4 Link Specifications

5.5 Freezing Objects and Links

6 Physical Organization (FIGS. 1A, 1B, and 1C)

7 Some Elements of an Illustrative System

8 System Data Structures

8.1 System Database

8.1.1 Object Type Table

8.1.2 Object Manager Table

8.1.3 Object Prototype Table

8.1.4 Customization Table

8.1.5 Library Table

8.1.6 Volume Table

8.1.7 System Configuration Table

8.2 Object Catalog

8.2.1 Object Table

8.2.2 Link Table

8.2.3 File List Table

8.2.4 Folder Table

8.2.5 Field WIT File

8.2.6 Object WIT File

8.2.7 Deleted Objects Table

8.3 Link Parallel Files

9 Object Manager Invocation

9.1 Invocation by Direct use of the Kernel

9.2 Startup Requests

9.3 Invocation by APPACK

10 Object Manager Table (FIG. 3)

11 Object Prototype Table (FIG. 4)

12 Object Catalog (FIGS. 5, 6, and 7)

12.1 Catalog Server Process

13 Links and Link Parallel Files (FIG. 8)

14 Copy, Move and Share

15 The Matchmaker

15.1 Matchmaker Purpose and General Operation

15.2 Matchmaker Protocols

15.2.1 Source Protocol

15.2.2 Place Protocol

15.2.3 Processing UNDO after an Interobject MOVE Operation

16 Data Interchange (FIG. 9)

17 Resources

17.1 Resource Files

17.2 Resources (FIG. 10A)

17.3 Resource Editor (FIG. 10B)

18 Resource Customization

18.1 General Customization by Means of Customized Resources

18.2 Customization IDs

19 APPACK Function Calls

19.1 Invocation Services

19.1.1 APrqstart()--Issue A Start Request

19.1.2 APrqedit()--Issue An Edit Request

19.1.3 APrqread()--Issue A Read Request

19.1.4 APrqrun()--Issue A Run Request

19.1.5 APrqcreate()--Issue A Create Request

19.1.6 APrqchangelink()--Issue A Change Link Request

19.1.7 APrqprint()--Issue A Print Request

19.1.8 APrqupdate()--Issue A Link Update Request

19.1.9 APrqcopy()--Copy An Object

19.1.10 APrqdeletelink()--Delete A Link

19.1.11 APrqrelocate()--Relocate An Object

19.1.12 APrqimport()--Import A Foreign Object

19.1.13 APinvoke()--Invoke An Application

19.2 Operation Support

19.2.1 APinit()--Initialize Application Request Processing

19.2.2 APreply()--Reply To A Request

19.2.3 APevinit()--Initialize APPACK Event Specification

19.2.4 APevaction()--Set Action Code For APPACK Events

19.2.5 APevremove()--Remove APPACK Event Specification

19.2.6 APmsgtest()--Test An APPACK Message Event

19.2.7 APrioinit()--Get A RIOID For An Active Operation

19.2.8 APmsgwait()--Wait For An APPACK Message

19.2.9 APoprequest()--Send An Operation Request

19.2.10 APmsgrequest()--Interpret A Request Message

19.2.11 APopfinish()--Terminate An Operation

19.3 Matchmaker Operations

19.3.1 APmmreserve()--Reserve The Matchmaker For An Operation

19.3.2 APmmpost()--Post An Operation On The Matchmaker

19.3.3 APmmconnect()--Connect To Matched Application

19.4 Link Interchange

19.4.1 LNXpinit()--Start Building Link Stream

19.4.2 LNXprestart()--Reset Stream To Link

19.4.3 LNXplink()--Put A Link Into The Stream

19.4.4 LNXpnewlink()--Put A New Link Into The Stream

19.4.5 LNXpfinish()--Finish Building Link Stream

19.4.6 LNXginit()--Start Reading Link Stream

19.4.7 LNXgrestart()--Reset Stream To Link

19.4.8 LNXglink()--Get The Next Link In The Stream

19.4.9 LNXgpeek()--Look At The Next Link In The Stream

19.4.10 LNXgskip()--Skip The Next Link In The Stream

19.4.11 LNXgfinish()--Finish Reading Link Stream

19.5 Text Interchange

19.5.1 TXXpinit()--Start Building Text Stream

19.5.2 TXXprestart()--Reset Stream To Text

19.5.3 TXXpstring()--Put Text String Into The Stream

19.5.4 TXXpchar()--Put Single Character Into The Stream

19.5.5 TXXpfont()--Change Current Font

19.5.6 TXXpattrs()--Set Text Attributes

19.5.7 TXXpdiacritic()--Insert Diacritic Mark

19.5.8 TXXpstrikethru()--Set Strike-Thru Character

19.5.9 TXXpscript()--Set Script Offset

19.5.10 TXXpvertical()--Put Vertical Move Down Command

19.5.11 TXXphorizontal()--Put Horizontal Move Command

19.5.12 TXXpspacing()--Put Interline Spacing Command

19.5.13 TXXplanguage()--Put Change Language Command

19.5.14 TXXplink()--Put A Link Into The Stream

19.5.15 TXXpfinish()--Finish Building Text Stream

19.5.16 TXXginit()--Start Reading Text Stream

19.5.17 TXXgrestart()--Reset Stream To Vanilla Text

19.5.18 TXXgnext()--Get Next Type Of Data In Input Stream

19.5.19 TXXgstringsize()--Get Next String Length

19.5.20 TXXgstring()--Get Text String From The Stream

19.5.21 TXXgchar()--Get Character From The Stream

19.5.22 TXXgfont()--Get The Current Font

19.5.23 TXXgattrs()--Get Text Attributes

19.5.24 TXXgdiacritic()--Get Diacritic Mark

19.5.25 TXXgstrikethru()--Get Strike-Thru Character

19.5.26 TXXgscript()--Get The Script Offset

19.5.27 TXXgvertical()--Get Vertical Move Down

19.5.28 TXXghorizontal()--Get horizontal move

19.5.29 TXXgspacing()--Get Interline Spacing

19.5.30 TXXglanguage()--Get Change Language Command From The Stream

19.5.31 TXXgfinish()--Finish Reading Text Stream

19.6 Record Interchange

19.6.1 REXpinit()--Start Building Vanilla Record Stream

19.6.2 REXprestart()--Reset Stream to Vanilla Record

19.6.3 REXpheader()--Build a Header Record

19.6.4 REXprinit()--Start Record Descriptor

19.6.5 REXpfdesc()--Build Field Descriptor

19.6.6 REXprfini()--End Record Descriptor

19.6.7 REXpdinit()--Start Data Record

19.6.8 REXpdata()--Build Data Field

19.6.9 REXpdfini()--End Data Record

19.6.10 REXpfinish()--Finish Building Vanilla Record Stream

19.6.11 REXginit()--Start Reading Vanilla Record Stream

19.6.12 REXgrestart()--Reset Stream to Vanilla Record

19.6.13 REXgtype()--Get Next Record Type

19.6.14 REXgheader()--Get Header Record Information

19.6.15 REXgfdesc()--Get Next Field Descriptor

19.6.16 REXgdata()--Get Next Data Field

19.6.17 REXgnext()--Skip to Next Record Type

19.6.18 REXgfinish()--Finish Reading Vanilla Record Stream

20 RESPACK Function Calls

20.1 Resource File Access Functions

20.1.1 RESfopen()--Open a Resource File

20.1.2 RESfinit()--Open a List of Resource Files

20.1.3 RESfclose()--Close a Resource File

20.2 Resource Access Functions

20.2.1 RESget()--Get a Resource

20.2.2 RESmget()--Get Multiple Resources

20.2.3 RESpoint()--Get a Pointer to a Resource

20.2.4 RESrelease()--Release a Resource

20.2.5 RESread()--Read a Resource

20.2.6 RESlookup()--Find Resource with Given Name

20.2.7 RESgtinfo()--Get Information About Resource

20.3 Resource File Management Functions

20.3.1 RESfcreate()--Create a Resource File

20.3.2 RESfedit()--Modify a Resource File

20.3.3 RESfview()--Peruse a Resource File

20.3.4 RESfcommit()--Commit Modifications to File

20.3.5 RESgtfinfo()--Get Information About File

20.3.6 RESptfinfo()--Put Information About File

20.3.7 RESavail()--Get Unused Resource ID

20.3.8 RESgtnext()--Get Next Resource Information

20.3.9 RESgtprev()--Get Previous Resource Information

20.3.10 REScheckpt()--Checkpoint Resource File Updates

20.3.11 RESrevert()--Revert to Last Checkpoint

20.3.12 RESfreeze()--Freeze a Resource File Version

20.3.13 RESgtfver()--Get Resource File Version Number

20.3.14 RESptfver()--Put Resource File Version Number

20.4 Resource Editing Functions

20.4.1 RESrdcur()--Read Current Version of Resource

20.4.2 RESgtcur()--Get Current Resource Information

20.4.3 REScreate()--Create a Resource

20.4.4 RESwrite()--Write a Resource

20.4.5 RESrewrite()--Overwrite a Resource

20.4.6 RESptinfo()--Put Information About Resource

20.4.7 RESmove()--Move Resource to New Location

20.4.8 RESptnum()--Renumber a Resource

20.4.9 RESmerge()--Merge a Resource List into a File

20.4.10 RESdelete()--Delete a Resource

20.5 Resource Index Function

20.5.1 RESixinit()--Start Building a Resource Index

20.5.2 RESixprep()--Begin Modifying an Existing Index

20.5.3 RESixadd()--Add a Resource Index Entry

20.5.4 RESixdelete()--Delete a Resource Index Entry

20.5.5 RESixfini()--Finish Building a Resource Index

20.5.6 RESixlookup()--Look up a Resource Index Entry

20.5.7 RESixulookup()--Look up a USHORT Entry

20.5.8 RESixllookup()--Look up a ULONG Entry

20.5.9 RESixslookup()--Look up a String Entry

20.5.10 RESixufind()--Find a USHORT Entry

20.5.11 RESixlfind()--Find a ULONG Entry

20.5.12 RESixsfind()--Find a String Entry

20.5.13 RESixget()--Get an Entry in a Resource Index

20.5.14 RESixindex()--Get an Entry in a Resource Index

20.5.15 RESixinfo()--Get Info on a Resource Index

20.6 Batch Style Resource Creation Functions

20.6.1 RESccreate()--Create a Batch Style Resource File

20.6.2 REScadd()--Add a Resource to a Resource File

20.6.3 REScclose()--Finish Resource File Building

20.7 User Profile Support Functions

20.7.1 RESptcustid()--Set Customization ID

20.7.2 RESsupedit()--Edit Resources in a Profile

1 CONCEPTS

1.1 Objects and Object Managers

The system of the present invention is a member of the general class of systems described as "object based". That is, information is stored in structures referred to as "objects". In the implementation of the present preferred embodiment most objects each correspond to one or more files of a conventional computer file system.

Further with regard to objects, the system of the present invention allows the use of an essentially unlimited variety of object "types", including the type previously described as a folder, wherein there may be a type of object for each form of data or information or operation to be performed by the system. That is, the system of the present invention defines only the minimal interface between an object and the system and does not define the internal structure or form of any object. As such, an object within the system of the present invention may be regarded as a general purpose container for data, programs or other information, with the internal structure or form of a particular object being defined by the requirements of the operation to be performed or the type of data or information to be stored therein.

Programs for operating upon objects are known as "object managers" or are sometimes referred to as "editors", "applications programs", or "applications". The term "application" is also used to refer to a collection of object managers that operate on a single object type. Each type of object has associated with it at least one object manager that is designed or intended as the primary means for operating upon the data or information stored in that type of object. For example, the system may support a "document type" object for word processing and there will be a word processing object manager associated with that object type. Similarly, a "data base type" object will have associated with it a data base object manager, which is the primary means for operating upon or with the data stored in the data base type object.

It should be noted, however, that the object managers for operating with a particular type of object are not limited to the primary object manager for that object type. Moreover, the particular object manager invoked to operate upon a particular object may depend upon the type of operation to be performed. The system of the present invention provides for a plurality of object managers to operate with any given object type and certain object managers, for example, certain utilities, may operate with more than one type of object. The primary object manager is simply the object manager which is invoked by default for operations upon a particular object type if the user does not select a different program.

Although typically an object manager will operate on the data of a single type of object, in certain cases it may be desirable to arrange a program to be an object manager for more than one object type. Further, there are various utility programs that perform operations that do not interpret object data (e.g. file copy) and that therefore can be used with various types of objects.

1.1.1 An Object Type: Folder

Folders are used as an organizational tool. Folder-type objects are used primarily for the links they contain. For example, a group of objects can be logically associated together by all being linked to a single folder object. Like any object, a folder can itself be linked into a folder. Associated with each folder is a file, which can contain information such as a user's comments about the purpose of the folder, instructions on what to do with the objects in the folder, etc. Often there will be no such data, as a typical folder's significance is only the list of objects linked to it; in this case, essentially all there is to the folder is its entries in the object catalog, primarily the entries in the Link Table.

Folders need no link markers because the links are not embedded in any data. Order among the links in a folder is determined not by the sequence in which link markers are embedded, but by the values of the Link IDs stored in the Link Table.

A Folder does not link any data from the objects to which it has links (i.e., a folder needs no link parallel file). Folders just use links to represent relationships among whole objects.

Each user of the system has a primary folder. This is the primary means by which a user gains access to resources of the system. There is a primary system folder, which is typically linked into each user's primary folder,