Inter-Program Communication and Scheduling Method for Personal Computers

I. Field of the Invention

This invention relates generally to inter-program communication, and more particularly to apparatus in the form of a control program which provides application programs with the ability to communicate with each other, control each other and to share the communications hardware through a common driver while providing a uniform interface to the user.

II. Discussion of the Prior Art

Personal computers based upon the Intel 8.times.86 family of micro-processors, also known as IBM PCs or IBM compatible PCs, are the dominant standard for personal computing. The continuing popularity of this standard is due principally to the relatively low hardware cost plus the availability of a large body of applications software written to operate with a specific Disk Operating System (DOS) known as MSDOS which is sold by Microsoft Corporation. MSDOS, as with any operating system software, provides a prescribed environment for the operation of application programs. While the term MSDOS literally refers the software sold by Microsoft Corporation, it is frequently construed to include the Basic Input-Output System (BIOS) program contained in the Read-Only-Memory contained in any IBM compatible PC. Hereafter the term MSDOS will be used to mean the standard operating system, including the BIOS, of an IBM compatible personal computer generally conforming to the MSDOS (version 3.0 or later) protocol. Persons skilled in the art will be knowledgeable of the structure and mode of operation of MSDOS, but those desiring further background are referred to the detailed description of MSDOS found in a publication entitled "Advanced MSDOS" by Raymond Duncan, Microsoft Press, Copyright 1988.

MSDOS is comprised of a collection of programs which together provide an operating interface by which a user may interrogate and control the operation of the PC. When MSDOS is started it first completes an initialization process and then calls the command interpreter (COMMAND.COM). This program accepts, and acts upon, commands entered by the user via the keyboard. At this level, the commands are actually the names of files which contain a corresponding executable program. For example, if the user enters the command, "DIR", the command interpreter program will find the file "DIR.COM", load the program DIR into memory, if not already resident, and transfers control to the DIRectory program. The program DIR is executed, causing the contents of the current directory to be printed on the user's display. The DIR program terminates by returning control to the MSDOS command interpreter which then awaits the next user command. The user may thus invoke the execution of any MSDOS command or application program by entering the program name. The program thus called may, in turn, call low level DOS service routines to communicate with the various Input/Output resources.

The foregoing description fairly encompasses the relatively primitive scope of MSDOS when it was first introduced with the IBM PC, the model XT. The limited memory and computing resources of the model XT precluded many of the capabilities of known main frame and minicomputer operating systems such as UNIX. Whereas UNIX provided a very capable multi-user, multi-tasking environment, MSDOS was constrained to a single user, executing a single task with, at most, 640 kilobytes of random access memory. More significantly, MSDOS allows the application programs unrestricted access to input-output facilities, such as the asynchronous communication ports. The aforementioned limitations are inherent to MSDOS and cannot be directly overcome within MSDOS without compromising compatibility. Although examples of efficient inter-program communication and dynamic task scheduling are well known in other operating systems, this desirable capability has heretofore not been available on a personal computer running MSDOS.

Although MSDOS is readily extendible, such that new control programs may be incorporated to add new, or altered, features to the operating system, known prior art schemes do not yield an operating environment wherein a number of distinct application programs may be called by a single user command to efficiently and cooperatively accomplish a complex task. Whereas examples of this capability abound in more capable operating systems, the typical practice under MSDOS is to write a single monolithic program corresponding to the complexity of the task. It is believed that this is because prior art solutions to inter-program communication and dynamic scheduling under MSDOS have either been incomplete or too cumbersome. The underlying problem is that for a control program to efficiently accomplish the communication and scheduling tasks, it must remain resident in RAM memory where it competes with application programs for scarce memory resources. This conflict continues even as the speed and RAM memory capacity of PCs continues to increase.

To understand the impact of the control program environment of the present invention on the DOS environment, it is deemed helpful to discuss some of the limitations imposed by DOS on any software under its control. Through this description, the value of the control program environment of the present invention will become more clear.

The operating system called DOS was originally written to operate in the hardware environment provided by the Intel 8088 microprocessor. In this environment, a maximum of 1 MB of addressable RAM is available. It is divided into two regions by DOS. The lower memory space comprises 640 KB of program memory. It is in this area that programs are loaded and run. The limitation here is that if a program requires more than this amount of memory, it has no other memory to expand into. Also, it should be noted that the 640 KB space must also be occupied by the DOS program, leaving the remaining space for applications, device drivers, and other system software. This can result in not having enough memory space for the application to run.

The upper memory space consists of the remaining 384 KB, which is used for firmware residing on any of the PC boards installed in any of the PC's expansion slots. The video RAM is also addressed here. This space was never intended to be used for application programs.

A later development provided for more memory through the use of what is known as expansion memory. This scheme places a 64 KB buffer in the upper 384 KB space. Any memory in the computer beyond the original 1 MB space is swapped into this buffer through the use of hardware registers. The memory is useful for program data, but still does not alleviate memory limitations for the application executable code.

With the introduction of the 80286 and newer processors, another memory mapping scheme was evolved. It uses the extra addressable memory capabilities of these newer processors (up to 16 MB) as extended memory. Again, this memory is useful for storing program data, but not the programs themselves.

With these newer memory mapping schemes, one is still limited by the 640 KB program space. Therefore, any additions to the system-level software must take as little memory space as possible. Also, with the newer processors (80286 and above), it is possible to move certain device drivers and other system programs into the upper 384 KB region. One must appreciate, however, that such software must be relocatable so as to run properly without regard to where it is located in memory.

A powerful feature of the DOS environment is the concept of the Terminate and Stay Resident (TSR) program. It is a program which, when run, initializes itself (usually attaching to an interrupt) and returns control back to DOS. From that point on, when its interrupt is generated, the TSR will "wake up" and perform the required function. A common example of this is the popular Sidekick software available from Borland Corporation. This software attaches itself to the PC keyboard interrupt. Every time a key is pressed, the program "wakes up" and provides a multitude of functions to the user in the form of calendar, note pad, etc. If the keystroke was not Sidekicks "hot key", Sidekick simply passes the keystroke to DOS for further processing.

DOS provides a batch file mechanism whereby a user may create an ASCII file containing any DOS command line entries. Application programs, DOS commands, and any other action which can be initiated from the DOS command line may also be initiated from a batch file. For example, the task of clearing files from a DOS directly can be automated by creating a batch file which contains the necessary sequence of commands as they would be entered at the DOS command line. Whenever this batch file is executed, the series of commands it contains will be carried out as if they were entered manually from the DOS command line. In reality, the DOS batch file processing software is parsing the batch file and temporarily spawning a COMMAND.COM to execute these commands. One problem inherent in batch file processing is that the parent program's (in this case, the batch file processor) environment is not passed along to the child process (the action generated by the entry in the batch file). Because of this, batch files cannot adequately perform in the same integrated manner as is permitted by the control program environment of the present invention. In addition, since the lines are hard-coded into the batch file, they cannot be dynamically altered in response to changes in external stimuli. Batch files can make use of rudimentary error codes produced by the applications on exit, but unless the line to deal with this is already in the batch file, it cannot be handled.

Another part of the operating system for MSDOS is the so-called "device driver". It provides device independence to the application software. The hardware, through the device driver, is accessed simply as a file. The device is opened read and written to, and closed when the application finished with the device.

It is an object of the invention to provide a control program apparatus which operates cooperatively with MSDOS to provide guaranteed response time inter-program communication which allows complex user directives to be efficiently accomplished by a multiplicity of interacting application programs and, further, that this capability is extendable to more time-critical, event-driven, or real-time, processing for which the personal computer running MSDOS has been heretofore generally unsuitable.

It is a further object of the invention to provide a control program which allows dynamic scheduling where the application programs which it controls are able to modify the thread of execution.

It is another object of the invention to provide an improved degree of control and specificity of the operating environment under which subordinate application programs are run.

Another object of the invention is to provide a control program that is easily extensible in a modular fashion. In other words, the control program environment is an "open" architecture in which other software programs (system and/or application level) have full access to the critical elements or "hooks". The result is that software enhancements may be added to the future with little or no modification to the existing system.

It is yet a further object of the invention to permit computers to operate without conflicting with MSDOS or any MSDOS compatible application program.

It is a still further object of the invention to accomplish the forgoing objectives without introducing new impediments to the efficient operation of subordinate application programs while still maximizing the RAM memory space available to these programs by employing a very compact and efficient control protocol.

Yet another object of the present invention is to provide a new software environment in which the resident software, including all buffers, is written entirely in 8086 assembly language and requires only a minimal amount of memory space (e.g., about 24 KB of the 640 KB space). Moreover, the software of the present invention can be loaded into the upper 384 KB memory space, thereby further reducing the overall memory requirement in the 640 KB space.

The invention is comprised of a novel control program which effectively extends the MSDOS operating system capability to include inter-program communication and dynamic scheduling. It is comprised of two subprograms, HOLDER and KERNEL, which are installed as resident programs during system initialization and thus become extensions to the MSDOS operating system conforming to the MSDOS rules for such extensions. FIG. 1 is a diagrammatic representation showing the relationship of the control program to the MSDOS operating system and the application programs which run under the extended operating system.

The HOLDER program is analogous to a post office. It controls the process of receiving, storing and delivering the "mail", i.e., inter-program communication. Application programs may call the HOLDER program to send mail, determine if there is any mail addressed to them or receive mail. The HOLDER program contains two buffer memories (mail rooms) which have identical structure and employ the same control protocol. However, they achieve a different result. The public buffer is the mail room which supports inter-program communication. Application program A may call the HOLDER program to send a message to application program B. When application program A terminates, and if application program B is executed at some future time, application program B may call the HOLDER program to receive the message sent by application program A. The intended addressee is denoted by the data type variables, a 16-bit unsigned integer which forms the heading of each message stored in the public buffer and thus provides for 65,536 distinct addresses. Thus far, there is no means for application program A to assure that application program B ever gains, the opportunity to receive its message. This is not a problem if both programs are part of a pre-defined script which assures that both programs are called in sequence. However, it is very desirable to allow application program A to cause the execution of application program B, thereby enabling a complex task to be accomplished by a set of interactive application programs without the encumbrance of a script. This capability, known as dynamic scheduling, is supported by the other HOLDER mail room, the private buffer which is reserved for a special kind of mail.

The private buffer contains the execution thread required to accomplish a complex task. An application program may send one or more messages to the private buffer, each message identifying a program to be executed to, in effect, create a master plan. When an application program is called to fulfill its role in the master plan, it may communicate, via the HOLDER program, to become aware of the master plan of which it is a part and may also alter the plan. Such alterations include adding new application programs to the plan, deleting application programs from the plan and changing the order of execution. It can also cause its own future re-execution by adding its own program name to the plan.

Although the aforementioned application programs are not part of the instant invention it is understood that they must be written to conform to the inter-program communication protocol of the instant invention to make use of this capability. The foregoing does not, however, preclude the possibility of including in the execution thread of the master plan any MSDOS compatible program, even though it is not so written.

There must be at least one application program capable of invoking the control program of the instant invention. Typically this would be a menuing program responsive to user direction, since the ultimate control of a personal computer typically resides with a human operator. The commercial programs, Windows sold by Microsoft Corporation, and Deskview sold by Quarterdeck Corporation, are examples of menuing programs which provide a menu of tasks from which a user may choose. The user inputs are interpreted by the menuing program which causes the respective program or programs to be executed. The term "MENU program" will be used to mean any program which invokes the control program of the instant invention in response to any computer input including, but not limited to, operator input devices such as a keyboard or a mouse. The MENU program communicates with the control program in two steps. First, the MENU program calls the HOLDER program to store the requested execution thread in the private buffer. In the simplest case, this would be the name of a single application program to be executed, but could be a sequence of as many as 32 programs, limited only by the slot capacity of the private buffer. The MENU program may also employ the public buffer of the HOLDER program to send messages to certain application programs which comprise the execution thread to modify their behavior when they execute. Also, each application has the ability to modify the public and private holder buffers to alter dynamically the course of actions following the application's control. The MENU program is really just another application as child process spawned by the KERNEL. Any application that makes use of the environment can perform the same functions.

Recall that interaction with the HOLDER program merely establishes a master plan for execution. The actual execution is initiated when the MENU program passes control to the KERNEL program. Although the KERNEL program appears as another applications program to MSDOS, it appears as a part of the extended operating system to the application programs that it controls. The KERNEL program functions as a dispatcher. When it gains control, it reads the private buffer to determine the next program to call. Whenever the KERNEL program finds an entry in the private buffer, it removes that entry and spawns the respective program. The program thus spawned is subordinate to the KERNEL program in that the spawned program is the child of the parent KERNEL program which inherits the KERNEL's environment and returns control to the KERNEL program when it terminates. Upon regaining control, this action is repeated until the execution thread has completed, i. e., the private buffer is empty, at which time control is passed back to the MENU program. Whereas the application programs which are part of the execution thread may modify the execution thread, the KERNEL program is constrained to follow the execution thread without modification.

Preferably, the entire process should be started by first calling the KERNEL program which, finding the private buffer empty, calls the MENU program. Since the KERNEL program is now the "parent" of the MENU program, control is passed to the KERNEL program whenever the MENU program terminates normally. When the KERNEL program has completed the execution thread by responding to all of its messages contained in the private buffer, a default program (typically the MENU program) is spawned to await a new event which will again involve the control program.

In summary, the MENU application program may use the control program of the instant invention to cause a multiplicity of other application programs to operate in a prescribed, yet not fully scripted, manner. This capability may be better understood by considering the analogy of a football team. The quarterback, like the MENU application program, has the role of communicating to the rest of his team (other application programs), the detailed instructions to accomplish a given play. The huddle and the call at the line of scrimmage allow the quarterback to communicate a master plan for which each player has a specified role. Certain players are given special instruction, known as play options. When the ball is snapped each player executes his part of the plan making adaptations, as required, in response to the action of other players (The analogy could be further expanded to consider the opposing team to be analogous to the dynamic operating environment of the application programs which conditionally modifies the behavior of the programs.).

The football team is a parallel model wherein players communicate and interact concurrently. In the MSDOS environment only one program can be active at any instant and that program is not inherently aware of programs which precede or follow it. The dynamic scheduling and inter-program communication capability of the control program enables a set of application programs to gain this awareness and to behave as if they were operating concurrently without the relatively high overhead associated with multi-tasking. The result is a very compact program which can be totally resident in RAM memory to achieve fast response and which yet leaves ample RAM memory space for application programs.

The memory required for both the control program and the communications driver are as follows:

HOLDER code--4.6 KB

Private Buffer--1

Public Buffer--1

KERNEL code--7.4

COM Driver code--2

COM Buffer--16 4 KB.times.4 (2 ports each with 4 KB IN buffer & 4 KB OUT buffer)

Total memory--32 KB

In the control program environment of the present invention, the KERNEL opens both communication ports, via the device driver. The resultant file handles are then placed into the HOLDER TSR public buffer. Any application then accesses the RS-232 ports, via the file handles in the HOLDER TSR buffer. The application only reads and writes to the RS-232 ports. Since only the KERNEL program opens or closes the ports, various applications are able to share the RS-232 hardware. For example, one application can start a data transfer and spawn another application to continue. Since the buffers in the device driver are large enough to hold typically two seconds worth of data at a 19200 baud rate, there is ample time for one application to spawn another without losing any data.

The HOLDER program of the instant invention is a TSR program. It attaches itself to an unused interrupt so that it "wakes up" only when its interrupt is specifically generated by an application or by the control program KERNEL. In this manner, HOLDER's operation is completely transparent to the user. Moreover, all of the technical details of the control program are completely transparent to the user. As far as the user is concerned, the control program of the present invention is nothing more than another simple menuing program when, in fact, it is performing many behind-the-scenes types of operation.

The control program of the present invention is completely compatible with MSDOS. It works with MSDOS, passing any unrecognizable commands to MSDOS to handle, taking an unused interrupt for its TSR, and providing device drivers written in strict accordance with Microsoft's guidelines. Furthermore, the control program environment does not try to duplicate MSDOS's functionality. Instead, it tries to enhance MSDOS by providing those functions not already provided by MSDOS. Moreover, it is able to do this without taking up large amounts of memory from available program space.

The source Code, written in the language of Borland Turbo Assembler, is contained in Appendix A.

FIG. 1 is a block diagram illustrating the organization of the Operating System incorporating the control program of the present invention and its relationship to MSDOS and non-resident application programs;

FIG. 2 shows the relationship between FIGS. 2a and 2b.

FIGS. 2(a) and 2(b) when arranged as in FIG. 2 is a software flow diagram illustrating the KERNEL program in accordance with the present invention:

FIG. 3 shows the relationship between FIGS. 3a and 3b.

FIGS. 3(a) and 3(b) when arranged as in FIG. 3 is a software flow chart illustrating program flow within any application program, designed to utilize the inter-program communication afforded by the control program of the present invention;

FIG. 4 is a flow diagram illustrating the execution sequence control and interprogram communication afforded to application programs which utilize the control program of the present invention.

FIG. 5 is a software flow chart of the HOLDER program forming a part of the overall control program of the present invention;

FIG. 6 is a general software flow diagram showing the interpretation of functions contained in the Public Buffer and requested using a stored identifier;

FIGS. 7A-7E are more detailed software flow charts illustrative of the various options available depending upon the results of the function interpretation, via the Public Buffer, contemplated by the HOLDER program; and

FIG. 8 is a software flow chart illustrating the CHRON program.

The initialization of a PC computer includes the installation of the resident portion of MSDOS in RAM memory. When this is complete, the HOLDER program is also installed as a TSR program. The starting address of the HOLDER program is stored at address 63h (Hex.) in the interrupt vector table. This allows the HOLDER program to be called by executing programmable interrupt 63h. Finally the KERNEL program is installed. It does not require an interrupt vector since it will be called using the standard MSDOS procedure used to call application programs. The control program is now resident and ready to provide control and communication services to application programs.

The KERNEL is a supervisory program which operates in conjunction with the MENU and HOLDER programs to initiate a program, or sequence of programs in response to a user command while maintaining continuous control of the operating environment. Although it is possible for an application program to assume control of the operating environment, contrary to the intent of the invention, the KERNEL does not relinquish control. As an aid in understanding, the application program can be considered as a "child" of the "parent" KERNEL program which "inherits" the parent's MSDOS operating environment plus any extensions to the operating environment placed in the public buffer. FIGS. 2a and 2b when arranged as shown in FIG. 2 show a block diagram of the operation of the KERNEL program. The KERNEL is the only application run from the MSDOS command line. Any application run under the control program is launched by the KERNEL as a child process. This includes the MENU program. HOLDER, as the TSR, is usually executed at the system startup from the AUTO EXEC.BAT file, though it could be started from the DOS command line. HOLDER must be installed before running the control program of the present invention. The KERNEL program is entered at entry point 10, having been called by the MENU program or directly from the MSDOS command level. At step 12, status is tested to determine if this is the first time the program has been called. If it is, step 14 is executed. To open the communications device driver, my program simply does a standard "FILE OPEN" request to DOS which returns a file handle that the KERNEL then stores in the public HOLDER buffer. This is done for each COMport. This driver operates much like the MSDOS drivers COM1 and COM2 to establish the essential communication parameters. MSDOS returns the file handle for each port found to be present in the host PC. A file handle is a 16-bit integer which names the file or communication port. It is provided by MSDOS when a request is made to open a file or communication port and subsequent requests to MSDOS for file service must include the file handle. As indicated by block 14, the KERNEL program stores each file handle along with a uniquely specified identifier in the public buffer associated with the HOLDER program. Since the communication file handles remain constant and accessible to all application programs spawned by the KERNEL program, multiple applications are now able to use a common file handle to thus share access to a given communication port. This is illustrative of the general capability of the instant invention to enable the operating system to regain control in those instances where MSDOS has surrendered too much control thereby providing a more useful total operating environment for application programs.

If the KERNEL program has been previously called, branch 13 is taken and execution passes to the operation represented by block 20. If the KERNEL program has been called from the MSDOS command level and a new default application program name has been entered as a command line option this condition is sensed at decision block 16 and the operation of block 18 captures the new program name and overwrites the intrinsic default application program name of MENU. If the above condition had not occurred, branch 13 is taken and execution passes directly to the operation of block 20. Here, the HOLDER program is called, via interrupt 63h, with a request code to get data from the private buffer. The HOLDER program returns the identity of the next program or command, if any, to be executed along with the associated identifier. It should be recalled that identifiers are predefined such that they provide a classification of the type of action to be performed. If no action item is returned, control moves to block 24 causing the default application program to be spawned. The program MENU is spawned unless the default name has been changed due to execution of the operation of block 18.

If an action item is returned, at block 26 a test of whether the value of the identifier associated with the action item retrieved at the operation of block 20 is made. If it indicates that the action item is the name of an application program, then the operation of block 28 spawns that application program as a "child" process, via a MSDOS call. If the identifier has a value of 2 and the action item is recognized as one of the internal KERNEL commands of Table 1 then step 34 executes the internal command and branches back to operation of block 20. Otherwise the command is presumed to be an MSDOS command and the command is passed to MSDOS for execution.

The software flow chart of FIG. 3 is illustrative of the program flow within any application program designed to use the inter-program communication and interaction capabilities afforded by the instant invention. Entry point 50 is the beginning of any such program spawned from the operations of either of blocks 24 or 28 in FIG. 2. Steps 52 and 54 call the HOLDER program, via interrupt 63h, with a request code to get data from the public buffer placed there by another application program. As indicated by block 58, the application performs it's intended function and at block 60 a test is performed to determine whether the instant application program should request the execution of another related application program. If so, operation block step 64 indicates that the name of the application program to be executed, along with its identifier, is placed in the private buffer, via interrupt 63h, using a "put data" request code. In the same manner the execution of the operations and test represented by blocks 66, 68 and 72 in FIG. 3 provide the option to place data in the public buffer to thus be available to other application programs. Block 74 indicates that a normal program termination is executed by calling any of the MSDOS functions reserved for that action causing the KERNEL program to be re-entered at point A (block 10, FIG. 2). In summary, the execution of the operations represented by operations 52 and 54 provide input data from other application programs while operations 60 and 64 provide dynamic scheduling and steps 66, 68 and 72 provide output data to other application programs. Alternatively, the KERNEL program may spawn an application which is not aware of the KERNEL or HOLDER programs. In this case, only the operations of blocks 58 and 74 are executed.

The following example shown in FIG. 4 is illustrative of the versatility afforded by these programs. The heavy dashed lines indicate the program execution thread while the light solid lines indicate communication to and from the respective buffers. The KERNEL program is initially called from the MSDOS command level. Since all HOLDER buffers are initially empty, the default application program MENU is spawned. The user selects a menu option to be performed which requires program A to gather data from a user specified location, programs B, C or D to conditionally process the data and program E to disseminate the data when the intervening programs have run. The MENU program uses the program A identifier to dispatch a message to program A, via the public buffer, which tells program A where to find the source data. The MENU program also places an action item in the private buffer, directing program A to be spawned. The MENU program terminates, returning control to the KERNEL program, which, finding the action item from the MENU program, spawns application program A. Program A gets the message from the MENU program, gathers the data, and determines that the data received requires processing by programs B and D, but not by program C, causing it to place action items in the private buffer directing the KERNEL to spawn programs B, D and E in that order. Next program A dispatches messages to programs B and D, telling them where to find their respective data and then terminates, returning control to the KERNEL program. In the same manner programs B, D and E are spawned with each program passing messages, via the public buffer, as required. Additional application programs, not shown, may be dynamically added to the schedule to accommodate exception handling, such as error reporting or error recovery. When program E terminates, the KERNEL program, finding no action items in the private buffer, again spawns the MENU program, returning control to the user to perform another menu selection.

The communication between the application program and the HOLDER program, indicated by blocks 54 and 72 of FIG. 3 uses the standard MSDOS function calling procedure. Various CPU registers are loaded with data by the application according to the function to be performed. The application then executes the programmed interrupt 63h to call the HOLDER program. The HOLDER program performs the requested function, loading various CPU registers with the requested information and then returns control to the application program. A common set of functions, differing only in the specific value of the request code, provides services for both the public and private buffers. These are:

getblock:

Get a piece of data, according to the specified identifier.

getnext:

Get the next piece of data according to the last specified identifier.

putblock:

Put a piece of data with its identifier in a HOLDER slot.

clearblock:

Clear the block of data last retrieved. A request to get a piece of data is non-destructive so any number of processes can have access to it, as needed.

status:

Get the status of the last operation.

signature: (provided in a startup routine)

Get the signature of the HOLDER.EXE program. This call is used to establish both the existence of the HOLDER.EXE TSR and its revision level. This call is made by the central program KERNEL on startup.

A detailed description of these functions is as follows:

Function 1: get the stored data from HOLDER's buffer

Registers to set for call:

AH=1

CX=number of bytes to be retrieved

DL=identifier code (0=untyped)

ES:DI=destination address

Note that the destination must be large enough to hold all the requested data.

Registers as set on return:

CX=number of bytes actually transferred

Note that if CX=0, the buffer was empty and no data was transferred.

Before calling this function, it is prudent to get HOLDER's current status to make sure the stored data is for the current program.

Function 2: put data into HOLDER's buffer

Registers to set for call:

AH=2

CX=number of bytes to be stored

DL=identifier code (0=untyped)

DS:SI=source address

Note the value in CX must be <=buffer size. If CX=0, the buffer is erased.

Registers as set on return:

CX=number of bytes actually stored

Most often, the best way to store data in the buffer will be with a formal C structure. From HOLDER's viewpoint, any data sent is just a stream of bytes which HOLDER makes no attempt to understand. The identifier code should be used to identify to another program whether the stored data is of interest or not.

Function 3: clear HOLDER's internal buffer

Registers to set for call:

AH=3

Registers as set on return:

None set on return

This call should be done when either the caller is intending to store new data or doesn't want another program to have access to the stored data.

Function 4: get HOLDER's current status

Registers to set for call:

AH=4

Note that this routine is reentrant and can be called recursively.

Registers as set on return:

BX=size of internal buffer (in bytes)

CX=number of currently bytes stored in the internal buffer

DH=error code from the previous operation

DL=identifier code of data stored in buffer

This should be done after each operation to insure that the requested operation was successfully performed.

Function 5: get next block of data with the same identifier

Registers to set for call:

AH=5

CX=number of bytes to be retrieved

ES:DI=destination address

Note that the destination must be large enough to hold all the requested data.

Registers as set on return:

CX=number of bytes actually transferred

Note that if CX=0, the buffer was empty and no data was transferred.

Function 100: get HOLDER's version and signature

Registers to set for call:

AH=5

Note that this routine is reentrant and can be called recursively.

Registers as set on return:

CX=TSR signature (6996)

DH=TSR major version number

DL=TSR minor version number

Example: version 1.2--DH=1 and DL=2

This operation should be called to insure that the code at HOLDER's vector is actually Holder.

Function 101: get the stored data from HOLDER's buffer

Registers to set for call:

AH=101

CX=number of bytes to be retrieved

ES:DI=destination address

Note that the destination must be large enough to hold all the requested data.

Registers as set on return:

CX=number of bytes actually transferred

Note that if CX=0, the buffer was empty and no data was transferred.

Before calling this function, it is prudent to get HOLDER's current status to make sure the stored data is for the current program.

Function 102: put data into HOLDER's buffer

Registers to set for call:

AH=102

CX=number of bytes to be stored

DL=identifier code (0=untyped)

DS:SI=source address

Note the value in CX must be <=buffer size. If CX=0, the buffer is erased.

Registers as set on return:

CX=number of bytes actually stored

Most often, the best way to store data in the buffer will be with a formal C structure. From HOLDER's viewpoint, any data sent is just a stream of bytes which HOLDER makes no attempt to understand. The identifier code should be used to identify to another program whether the stored data is of interest or not.

Function 103: clear HOLDER's internal buffer

Registers to set for call:

AH=103

Registers as set on return:

None set on return

This call should be done when either the caller is intending to store new data or doesn't want another program to have access to the stored data.

Function 104: get HOLDER's current status

Registers to set for call:

AH=104

Note that this routine is reentrant and can be called recursively.

Registers as set on return:

BX=size of internal buffer (in bytes)

CX=number of currently bytes stored in the internal buffer

DH=error code from the previous operation

DL=identifier code of data stored in buffer

This should be done after each operation to insure that the requested operation was successfully performed.

Function 105: get next block of data with the same identifier

Registers to set for call:

AH=105

CX=number of bytes to be retrieved

ES:DI=destination address

Note that the destination must be large enough to hold all the requested data.

Registers as set on return:

CX=number of bytes actually transferred

Note that if CX=0, the buffer was empty and no data was transferred.

The following errors may be reported as status returns:

FIG. 5 shows a block diagram of the HOLDER program. Either the KERNEL program or an application program may call the HOLDER program by executing programmed interrupt, 63h. At block 102, a test is made of register AH to determine what action is being requested by the calling program. If the request code is for one of the public functions as determined by decision block 104, then the operations represented by blocks 106 and 108 are executed. If the request code is for one of the private functions as determined by decision block 110, then the operations called for by blocks 112 and 114 are executed. Recall that public functions, i. e., operations performed on the public buffer, support inter-program communication while private functions support dynamic scheduling. If the test of block 116 determines that the request code equals 100, the operation of block 118 is executed to retrieve the signature and version of the HOLDER program. If the request code is invalid, the operation of block 120 is executed to store an invalid request status. Each path through the program causes the information requested by the calling program to be loaded into the CPU registers specified by the HOLDER command function. The HOLDER program terminates by executing a return from interrupt instruction at block 122 thereby returning control to the calling program.

Several features have been incorporated into the HOLDER program to make it compact, efficient and versatile. For each buffer, i.e., the one kilobyte private buffer and the one kilobyte public buffer, a slot table is maintained which contains the identifier and block size for each slot. The slot table contains the buffer address corresponding to the end of the data plus one for a given slot. For each slot table, the HOLDER program maintains two indices; the current slot index and the next slot index. The slot table and its indices are initialized as follows: ##STR1## If, for example, the HOLDER program receives a command to store 20 bytes of data in the next slot, the data is entered into the buffer at addresses 0-19, the next slot index is incremented, and the slot table is updated as follows: ##STR2## If, for example, the HOLDER program next receives a command to store 30 bytes of data in the next slot, this data is stored in the buffer starting at address 20 per the contents of slot one of the slot table as specified by the value of the next slot index. Both the current slot index and the next slot index are incremented and the slot is updated as follows: ##STR3## If the HOLDER program receives a command to delete the data in the current slot, the contents of the next slot minus the current slot are placed in the current slot and the data in the buffer is moved to reflect this change. This process is reiterated for each successive slot until the first unused slot is encountered, i.e., contents of the slot table entry equals 1024. This method of buffer management, known in the art as "garbage collection", allows the slot boundaries to be continuously adjusted to conform to the size of the message data while nevertheless allowing the HOLDER program to readily identify the beginning and end of a message using the slot indices and the slot table entries.

This allows the relatively small buffers to be used to provide a large virtual mailbox capability. Any slot may use any fraction of the total one kilobyte buffer space and the contents of any slot may be either the actual data, a vector which identifies the location of the data elsewhere in random access memory, or a file handle which identifies the location of the data in disk memory. Preferably the identifier is used to interpret which of these conventions should be applied to the contents of a given slot. Storing the data directly in the slot provides the fastest response while storing the data on disk conserves more valuable random access memory space. Thus, since each user of the public mailbox facility, i.e., the application programs, is able to judiciously balance the need for performance with the demand placed upon the communal public buffer space, the total buffer space may be relatively small. The identifiers provide a form of mailbox addresses which simplify the HOLDER program, making it both fast and compact. The operation of the HOLDER program is analogous to a file clerk who is able to store and retrieve information using a very limited and simple set of rules. The HOLDER program is also made compact by using the same buffer organization and control strategy for both the public and the private buffers, thus allowing portions of the program code to be shared.

FIGS. 6 and 7A through 7E show a more detailed block diagram of operations represented by blocks 104 and 106 in FIG. 5. The software represented by the flow chart of FIG. 6 interprets the specific function requested by testing the value of the identifier passed in register DL and then branching to the respective entry points represented by blocks 142-150, as labeled as Pub A through Pub E. FIGS. 7A through 7E each correspond to one of these entry points. If a request to get data from the public buffer A has been received, the operation represented by block 160 (FIG. 7A) is executed which sequentially searches the public slot table to find the first occurrence, if any, of a matching identifier. If none is found, control passes to block 164 to store the error status. If the identifier is found, the operation of block 166 is executed which accesses the slot table to find the location of the slot data in the public buffer. Then the slot data is moved from its slot location in the public buffer to the destination location specified by the calling program via the registers ES and DI. When the operation of block 168 is executed it stores the status of a successful transfer of data. If a request to store data in the public buffer has been received operation 180 is executed (FIG. 7B) which compare the free space in the public buffer with the contents of register CX which contains the number of bytes requested to be stored. If there is sufficient free space to satisfy the request step 182 is executed which appends a new entry to the slot table which is comprised of the identifier and the slot size, i. e., the number of bytes to be stored. The operations called for by blocks 184 and 186 use the contents of the DS and SI registers to locate the source of the data to be stored and the contents of the slot table to locate the destination of the data in the public buffer and performs the transfer. The slot table and the public buffer now contain the requisite information to allow another application program to retrieve the stored data using the previously described get data function. The execution of the operation indicated by block 188 stores the status of a successful transfer of data.

FIG. 7C shows the "GARBAGE COLLECTION" functions of HOLDER. This provides for very efficient use by the small buffers. GARBAGE COLLECTION occurs, as needed, without external intervention to prevent for augmentation of the buffer space. If a request to clear the current slot from the public buffer has been received, operation 200 (FIG. 7C) is executed which copies the contents of the next slot over the current slot. Operation 202 updates the slot table to reflect the new location in the public buffer of the next slot data. Next, the operations called for by blocks 200 and 202 are re-iterated until the test made at decision block 204 determines that the next slot is empty. If it is, operation 206 clears the unused buffer space while operation 208 results in the new state of the public buffer being entered in the slot table. At this point the public buffer has been restored to the state which existed just before data was last stored in the current slot. Execution of the operation indicated in block 210 stores the status of a successful clear operation.

If a "request to get" status has been received, the operation of block 220 (FIG. 7D) is executed which recovers the status stored during the execution of operations 168, 188, 210 or 236 and returns it to the application program. Also returned are the size of the public buffer, the number of bytes currently stored in the public buffer and the identifier of the data stored in the current slot. If a "request to get data" of the same type, i. e., having the same identifier, from the next slot of the public buffer has been received, the operation of block 230 is executed (FIG. 7E) which causes the public slot table to be sequentially searched to find the next occurrence, if any, of a matching identifier. If none is found as determined by the test identified in block 232, the operation of block 233 is executed to store the error status. Otherwise, the slot table is accessed to find the location of the slot data in the public buffer (block 234). Then the slot data is moved from its slot location in the public buffer to the destination location specified by the calling program via the registers ES and DI. The operation of block 236 stores the status of a successful transfer of data.

The private buffer functions fully correspond with the public buffer functions, differing only in the operations that are performed on the private buffer. Although it would be possible to employ a less capable private buffer organization, which would minimally satisfy the requirements of the preferred KERNEL program, it is not preferable to do so. Regardless of how simple it might be, a different private buffer organization would reduce sharing of HOLDER program code and, thus, increase its size. Further, it is advantageous to maintain the versatility of the public buffer organization for the private buffer since it provides a more open-ended architecture which enables the software of the present invention to maintain backward compatibility, while assuming new functions not yet anticipated.

Appendix A to this specification is the source code for the HOLDER and KERNEL programs. It is submitted as further satisfaction of the disclosure requirements of 35 U.S.C. 112.

The following discussion is both an alternative embodiment of the invention and an illustration of the versatility of the invention to incorporate additional functionality without modification of the basic control program. The TSR program CHRON adds the capability of dynamic scheduling relative to the value of the computer real-time clock. The function on the CHRON program is to periodically scan the public buffer for time-stamped messages and, at the designated time, interpret these messages to compose an executable message to be added to the execution thread contained in the private buffer. Any application program, including the MENU program, may place a time-stamped message in the public buffer. Such a message may be a directive to execute an application program once at a specified future time. Alternatively, the message may direct the execution of an application program N times, or an indefinite number of times, at a specified interval starting at a specified future time. Time-stamped messages are distinguished by the value of their identifier. FIG. 8 shows a flow diagram of the CHRON program. Entry point 250 indicates that the interrupt vector table is modified such that the CHRON program intercepts the interrupt vector intended for the normal timer interrupt. This causes the CHRON program to be called, i.e., it gets a "wake-up" call, every 18.2 times per second, i.e., when the normal timer interrupt would otherwise be called. Although it would be possible to execute the CHRON routine at each 0.05 second interval, this adds processing overhead which may be unproductive. Rather, the operation represented by block 254 counts each wake-up call and passes control to block 256 only for the n.sup.th wake-up call. For example, if n=1000, control passes to the operation of block 256 every 50 seconds. For all intervening wake-up calls, control is passed directly to the next timer interrupt handler. At block 256, the HOLDER program is called to determine whether the next slot contains a time-stamped message. If not, then the operation of block 260 determines whether there are more messages in the public buffer by testing the value of the CX register. Recall that this register will have been returned with a value of zero if there had been no more data to be scanned. In this event, control passes to the next timer interrupt handler. Otherwise the program loops back to block 256. If a CHRON message is found, the time stamp is tested to determine whether it is now time to execute the message. If not, the program conditionally loops back to operation 256, via block 264, in the manner described for operation block 260. When it is determined that it is now time to execute a message, control passes to block 266 which creates an executable message for the KERNEL program. Specifically, the name of the application program found in the CHRON message is added to the private buffer to become part of the execution thread.

The execution message may optionally contain various forms of precedence data which may be extracted from the CHRON message. If precedence data is made available in the private buffer, then any application program, while it is executing, may periodically examine the private buffer to detect when the CHRON program has added a higher precedence program to the execution thread. This provides the opportunity for a lower precedence program to terminate to allow a higher precedence program to be executed.

The private buffer functions fully correspond with the public buffer functions, differing only in that the operations are perform on the private buffer. Although it would be possible to employ a less capable private buffer organization, which would minimally satisfy the requirements of the preferred KERNEL program, it is not preferable to do so. Regardless of how simple it might be, a different private buffer organization would reduce sharing of HOLDER program code and, thus, increase its size. Further it is advantageous to maintain the versatility of the public buffer organization for the private buffer since it provides a more open-ended architecture which enables the software of the present invention to maintain backward compatibility, while assuming new functions not yet anticipated.

This invention has been described herein in considerable detail in order to comply with the Patent Statutes and to provide those skilled in the art with the information needed to apply the novel principles and to construct and use such specialized components as are required. However, it is to be understood that the invention can be carried out by specifically different equipment and devices, and that various modifications, both as to the equipment details and operating procedures, can be accomplished without departing from the scope of the invention itself. ##SPC1##