Application Program Interface to Physical Devices

1. Field of Invention

The present invention generally relates to programming interfaces between application programs and physical devices in a computer system.

2. Description of Prior Art

A process, which exists in a current or suspended state of execution, consists of a sequence of microprocessor instructions that have been loaded into random access memory in order to perform a task together with some private memory. The private memory is utilized to record state information during periods of suspended activity and as a buffer to store input and output data. Multiple processes which are simultaneously present in a computer system are known in the prior are as concurrent processes. Concurrent processes compete for limited system resources such as cache memory, random access memory, microprocessor instruction cycles, and access to physical devices. A mutual exclusion constraint exists in that two or more processes are not able to access the same system resource at the same instant of time. Cost-effective, personal computer systems, for example, provide only a single microprocessor for the execution of concurrent processes, in which case only one process is in a current state of execution and all others are in a suspended state of execution.

An application program provides a mechanism by which the human operator instructs the computer to perform tasks. The application spawns either a single process or multiple processes that are linked by cooperative relationships. Furthermore, multiple applications may be present in a computer system. An operating system is a set of functions that provide, at a minimum, a means of invoking application programs for execution and a man-machine interface between the human operator and computer system when no application programs are present. Operating systems also provide services that are common to a variety of applications and which require utilization of physical devices. Scheduling services, for example, requires utilization of a timing device to manage concurrent process access to microprocessor instruction cycles. A graphical user interface provides access to the video graphics adapter and mouse. In another example, dynamic memory management provides access to random access memory. Other system services that may or may not be provided by a particular operating system include inter-process communication, network connectivity, web browsing, dynamic-link library support, virtual memory management, cache management, security from external tampering, and protection from computer viruses. Operating systems are distinguished by the number and functionality of system services that they provide, the resources that are consumed in order to provide these services, and the intellectual complexity of the application program interface.

Certain operating system services that are explicitly requested by application programs using an application program interface. Application program interfaces consist of data and a library of routines which are provided in a dynamic-linked library. The library of routines that are utilized by a specific application program are dynamically linked to that application program each time it is invoked by the operating system, and differ from routines in software libraries that are statically linked to the application program exactly one time prior to program execution. It is well known in the prior art that a maximum of one copy of the data and library of routines provided by a dynamic-link library is stored in random access memory at any given time, independently of the number of application programs which are present.

Referring to FIG. 1, a prior art programming interface between application programs and physical devices being utilized is shown. An operating system 10, two separate applications programs 41, 42 and three separate physical devices 1, 2, 3 are present. Next, the operating system consists of a kernel 20, three separate device drivers 11, 12, 13 and three separate application program interfaces 31, 32, 33.

The kernel 20 schedules the execution times of concurrent processes which are spawned by the application programs, application program interfaces, and device drivers. The kernel is itself a process and therefore must schedule its own activity. Microprocessor instruction cycles are viewed as a system resource, so that process execution time coincides with the scheduled allocation of microprocessor instruction cycles to that process. In some cases, concurrent processes operate independently of each other. In other cases, concurrent processes are linked by cooperative towards the goal of achieving some high level task. The cooperative relationships may be viewed as a sequence of cause-and-effect relationships. Furthermore, each cause-and-effect relationship involves a secondary process and one or more primary processes. The secondary process accepts as an input data and control information produced by the primary processes in order to perform an intermediate task towards the ultimate goal of completing some higher level task. A precedence constraint exists in that the availability of the data and control information produced by the primary processes must precede execution of the secondary process. The time elapsed time beginning when the secondary process is invoked to complete the task and ending with task completion equals the sum of the execution time and scheduling delay. The execution time equals the elapsed time beginning when the secondary process obtains the system resources and inputs which are necessary for task completion, and ending when the secondary process completes the task. The scheduling delay equals the elapsed time beginning when the secondary process is invoked to complete the task, and ending when the secondary process obtains the system resources and the inputs which are required for task completion.

Application programs 41, 42 utilize the application program interfaces 31, 32, 33 in order to request services that require utilization of the physical devices 1, 2, 3. In the prior art, application program interfaces 31, 32, 33 do not directly manipulate any of the physical devices 1, 2, 3. Instead, the application program interfaces incorporate a hardware-independent, abstract representation of generic physical devices. This representation is utilized to generate a sequence of abstract operations which are performed by the generic device in response to requests for services that require utilization of the physical devices. Abstract device operations generated by the application program interfaces, which vary in number depending upon the particular service that is requested by the application programs, are sent to the kernel in the form of variable-length messages. As an intermediate step in the processing, the application program interface executes any computational algorithms that are required to decompose requested services into the appropriate sequence of abstract device operations.

The kernel 20 accepts as an input messages containing a variable-length sequence of abstract device operations from the application program interfaces. Each abstract device operation is validated by the kernel in the case of operating systems that are alleged in the prior art to insure computer system integrity and to protect the system from external tampering. Next, the appropriate device driver is identified by the kernel and designated to manipulate the physical device as specified by the abstract device operations.

Device drivers provide a low-level interface to physical devices. Each device driver translates abstract device operations into actual device operations which are hardware-dependent and specific to the particular physical device in use. It can be seen by those skilled in the prior art that the application programs, application program interfaces, and kernel are independent upon the type of physical device being utilized. Hardware independence of the operating system is achieved by dynamically linking the kernel 20 with the set of device drivers 11, 12, 13 that are compatible with the particular set of physical devices 1, 2, 3, respectively, that are present.

Interrupts originating from the physical devices 1, 2, 3 are not delivered directly to application programs 41, 42. Instead, the device drivers 11, 12, 13 incorporate interrupt service routines which intercept and process interrupts originating from physical devices 1, 2, 3, respectively. The interrupt service routines send a message to the kernel 20 in order to communicate the results of intercepting and processing the interrupts. The kernel 20 dispatches these messages to the appropriate application program interfaces 31, 32, 33. Application program interfaces 31, 32, 33 perform additional processing on messages originating from device driver interrupt service routines, and output new messages to application programs 41, 42 indicating the results of the processing.

It can be seen that the operating system provides application programs with indirect access to physical devices using a method that involves the execution of three processes per physical device. The response time required by application programs 41, 42 to respond to random events equals the sum of the scheduling delays and execution times of the three operating system processes which cooperate in order to intercept and respond to interrupts originating from physical devices 1, 2, 3. Similarly, the service time required by application programs 41, 42 to access physical devices 1, 2, 3 equals the sum of the scheduling delays and execution times of the three operating system processes which cooperate in order to provide the requested service.

With reference to FIG. 1, application program 41 must execute prior to application program interface 31 in order to request services that require reading data and status words from physical device 1. Application program interface 31 must execute prior to the kernel 20 in order to generate the corresponding sequence of abstract device operations. The kernel 20 must execute prior to the device driver 11 in order to validate the sequence of abstract device operations and identify device driver 11 from among the device drivers that are present. The device driver 11 must execute prior to the kernel 20 in order to translate the abstract device operations into actual device operations in order to read the data and status words from physical device 1. Once this output becomes available, the device driver 11 creates a message containing the data and status words for input to the kernel. The kernel 20 must execute prior to application program interface 31 in order to receive the message containing the data and status words from the device driver 11. Finally, the application program interface 31 must execute prior to application program 41 in order to receive the message containing the data and status words from the kernel 20. In this example, process input-output relationships and process execution times are represented by the precedence graph of FIG. 2A. The numbers shown in parenthesis and brackets, all of which are quantities greater than zero, equal process execution times and scheduling delays, respectively. If process 41 begins execution at time t=0 then the aforementioned process sequence evolves as follows:

(a) process 41 for the period beginning at t=0 and ending at t=a.sub.R ;

(b) process 31 for the period beginning at t=a.sub.R +u.sub.R and ending at t=a.sub.R +b.sub.R +u.sub.R ;

(c) process 20 for the period beginning at t=a.sub.R +b.sub.R +u.sub.R +v.sub.R and ending at t=a.sub.R +b.sub.R +c.sub.R +u.sub.R +v.sub.R ;

(d) process 11 for the period beginning at t=a.sub.R +b.sub.R +c.sub.R +u.sub.R +v.sub.R +w.sub.R and ending at t=a.sub.R +b.sub.R +c.sub.R +d.sub.R +u.sub.R +v.sub.R +w.sub.R ;

(e) process 20 for the period beginning at t=a.sub.R +b.sub.R +c.sub.R +d.sub.R +u.sub.R +v.sub.R +w.sub.R +x.sub.R and ending at t=a.sub.R +b.sub.R +c.sub.R +d.sub.R +e.sub.R +u.sub.R +v.sub.R +w.sub.R x.sub.R ;

(f) process 31 for the period beginning at t=a.sub.R +b.sub.R +c.sub.R +d.sub.R +e.sub.R +u.sub.R +v.sub.R +w.sub.R +x.sub.R +y.sub.R and ending at t=a.sub.R +b.sub.R +c.sub.R +d.sub.R +e.sub.R +f.sub.R +u.sub.R +v.sub.R +w.sub.R +x.sub.R +y.sub.R ; and

(g) process 41 for the period beginning at t=a.sub.R +b.sub.R +c.sub.R +d.sub.R +e.sub.R +f.sub.R +u.sub.R +v.sub.R +w.sub.R +x.sub.R +y.sub.R and ending at t=a.sub.R +b.sub.R +c.sub.R +d.sub.R +e.sub.R +f.sub.R +g.sub.R +u.sub.R +v.sub.R +w.sub.R +x.sub.R +y.sub.R +z.sub.R.

It can be seen from this example that minimization of the service time required for application programs to read data and status words from physical devices, which corresponds to zero scheduling delay such that u.sub.R +v.sub.R +w.sub.R +x.sub.R +y.sub.R +z.sub.R =0, is not achieved in the prior art.

In another example, application program 41 must execute prior to application program interface 31 in order to request services that require writing data and control words to physical device 1. Application program interface 31 must execute prior to the kernel 20 in order to generate the corresponding sequence of abstract device operations. The kernel 20 must execute prior to the device driver 11 in order to validate the sequence of abstract device operations and identify device driver 11 from among the device drivers that are present. Finally, the device driver 11 must execute prior to the kernel 20 in order to translate the abstract device operations into actual device operations in order to write data and control words to physical device 1. In this example, process input-output relationships and process execution times are represented by the precedence graph of FIG. 2B. If process 41 begins execution at time t=0 then the process sequence evolves as follows:

(a) process 41 for the period beginning at t=0 and ending at t=a.sub.w ;

(b) process 31 for the period beginning at t=a.sub.w +u.sub.w and ending at t=a.sub.w +b.sub.w +u.sub.w ;

(c) process 20 for the period beginning at t=a.sub.w +b.sub.w +u.sub.w +v.sub.w and ending at t=a.sub.w +b.sub.w +c.sub.w +u.sub.w +v.sub.w ; and

(d) process 11 for the period beginning at t=a.sub.w +b.sub.w +c.sub.w +u.sub.w +v.sub.w +w.sub.w and ending at t=a.sub.w +b.sub.w +c.sub.w +d.sub.w +u.sub.w +v.sub.w +w.sub.w.

It can be seen from this example that minimization of the service time required for application programs to write data and control words to physical devices, which corresponds to zero scheduling delay such that u.sub.w +v.sub.w +w.sub.w +x.sub.w +y.sub.w +z.sub.w =0, is not achieved in the prior art.

Two types of prior information are available to schedule the activity of concurrent processes. The first type of prior information includes the priority of the task performed by each process. The second type of prior information includes process duration, execution time, and precedence constraints. A problem exists in that the kernel exploits the first type of prior information but not the second. The kernel 20 utilizes a simple priority queue or priority queue with preemption to schedule the activity of concurrent processes based task priority. The result is that the actual order and duration of process activation is inconsistent with process sequence input-output relationships and execution times. This inconsistency tends to increase scheduling delay, thereby degrading application program performance in terms of service and response times. Application program performance analysis, which takes the form of a queuing system with probabilistic arrival and service times, is non-deterministic and may only be characterized in terms of temporally averaged quantities.

In the prior art, a problem exists in that dynamic scheduling results in an exponential degradation in application program performance with increasing utilization of system resources. This behavior is predicted by queuing theory. Utilization of a system resource is characterized by a utilization factor. The utilization factor is a number between zero and one equal to the fraction of time that the resource is utilized by any process. The kernel is a process and must therefore allocation system resources to itself at the expense of the amount of resources which are available to all other processes which are present. A similar problem exists in that attempts to reduce scheduling delays using improved methods of dynamic scheduling must be traded against the fact that these methods require increased computation, thereby increasing scheduling delays due to increased kernel utilization of system resources.

In the prior art, a problem exists in that operating system performance cannot be traded against functionality in order to satisfy the broad spectrum of requirements corresponding to a diverse suite of applications. Operating systems developed for the IBM personal computer and compatibles, for example, have evolved to provide the functionality required by word processors, spreadsheets, and Web browsers. This functionality is not important in the case of real-time and embedded systems and engineering workstations. Furthermore, the resources which are consumed in order to provide this functionality tends to increase random scheduling delays. Engineering workstations require high-speed execution of computational algorithms used for modeling, simulation, filtering, prediction, and computer-aided design. Real-time and embedded systems monitor and control physical processes, and require data acquisition and processing capability in real-time, i.e., without the loss of temporal information, combined with a deterministic response to external events. Applications of real-time and embedded systems include smart appliances, environmental control, industrial process control, condition monitoring, signal and image processing, patient monitoring, data acquisition, robotics, machine vision, target tracking, security access, mobile robots, factory robots, sentry robots, traffic information display and control, components management, process control, quality control, vehicle control, telecommunication switches, and real-time event logging.

A problem exists in that new features are added to subsequent releases of the operating system, even after the benefit of the added features becomes negligible, the intellectual complexity of the application program interface becomes unmanageable, and average scheduling delays grow exponentially due to increased utilization of system resources. This problem is known in the prior art as creeping featuritis. An example of unbounded queuing delays resulting from creeping featuritis is the vicious virtual memory cycle, as described in the text book by G. Wm. Kadnier, entitled Windows NT 4: The Complete Reference, published by Osborne McGraw-Hill, and in particular Chapter 3 entitled "Setting Up Your System". Additional articles documenting creeping featuritis include articles by M. Leon, entitled "Java Battles Bloatware", which appeared on page 2 in InfoWorld, Jan. 6, 1997; M. Vizard, entitled "Is A Modular OS The Next Bloatware Cure?", which appeared on pages 1 and 18 in InfoWorld, Jan. 6, 1997; J. Dvorak, entitled "Inside Track", which appeared on page 89 in PC Magazine, Feb. 18, 1997; J. Dodge, entitled "Of Hard Drivers, Bloatware And Stubborn Fish Odor", which appeared on page 89 in PC Week, Jan. 27, 1997; J. Dodge, entitled "When It Comes To Their Own PCs, Pros Take It Personally", which appeared on page 3 in PC Week, Feb. 10, 1997; and B. Livingston, entitled "Though You'd Had Enough Fun? Here's More With Resource Ids In Windows 95", Infoworld, which appeared on page 32 in Jan. 27, 1997.

A problem exists in the prior art in that the testing used to validate the correct operation of operating system is inadequate. Recent experience indicates that the only difference between operating system development and maintenance is that a delivery date exists between these two activities. Evidence of the lack of validation testing is well documented in the current literature. See the articles by N. Petrely, entitled "IBM wins 1996 Fatal Error Awards And Shares General Protection Fault Awards With Microsoft", which appeared on page 126 in Infoworld Jan. 27, 1997; and B. Livingston, entitled "Though You'd Had Enough Fun? Here's More With Resource Ids In Windows 95", which appeared on page 32 of Infoworld in Jan. 27, 1997. Additional articles documenting the lack of verification testing include "The Bug Report: Microsoft To Fix Its Fixes", which appeared on page 14 in Infoworld, Jan. 20, 1997; and "The Bug Report: Service Pack 2 for Windows NT 4.0 Has Many Bug Fixes", which appeared on page 35 in Infoworld, Jan. 27, 1997.

In the case of a specific prior art operating system, which is the product of a corporation that also develops and markets application programs, certain routines of the application program interface are left undocumented. The purpose is to implement corporate strategy for gaining an unfair advantage in the development of competing products, which are not able to exploit the functionality of undocumented routines. Developers of competing products may be able to produce the functional equivalent to undocumented routines. Even so, the performance of the functional equivalent routines will always be degraded relative to that of the undocumented routines. This is because system resources are allocated to undocumented portions of the application program whether or not they are actually utilized by the application programs. The highest number of undocumented routines in the prior art is two hundred and fifty. For further information, the reader is referred to the text book by A. Scheilman, D. Maxey, and M. Pietrek, entitled Undocumented Windows: A Programmer's Guide to Reserved Windows API Functions, published by Addison-Wesley.

A problem exists in the prior art in that eleven incompatible versions of an operating system for the IBM PC/AT and compatibles have been released over a ten year period with additional releases scheduled in the near future. The effect of this shotgun approach to releasing operating systems is to allow a single corporation to control the environment in which development takes place. Beta program privileges for future releases of the operating system, which in some cases require steep license fees, has created a country club atmosphere in which members are given exclusive access to operating system specifications prior to its release. Early access provides a time-to-market lead in which to initiate product development and marketing programs. Non-members are sometimes able to regain competitive status by upgrading their product line, only to find their efforts invalidated in approximately one year with the release of a subsequent, incompatible version of the aforementioned operating system.

Prior art operating systems are limited in that, the functionality of the said operating system partially determines the functionality of application programs. One such operating system is DOS, which is distributed by IBM and Microsoft Corporation using the brand name PC-DOS and MS-DOS, respectively. It has been is widely acknowledged in the prior art that DOS is insufficient for modem computer applications. Section 1.2 of the web site at http://www.cmkrnl.com/faq.html confirms this insufficiency as follows: "In primitive PC operating environment such as DOS, drivers were specific to individual applications. For example, WordPerfect got pretty successful by including drivers that supported a wide variety of printers. But none of those drivers would work with any other printers." Another limitation of the DOS operating system is that concurrent processes are unable to access the video graphics adapter through a common graphics device interface. Despite the speed and efficiency of this operating system, this particular limitation contributed to the decreased popularity of application programs written for DOS as visual programs gained wider acceptance. Visual programs produce high-resolution, color graphics displays in the form of lines, polygons, solid shapes, symbols, text, and images. For further background, see the text book by Peter Norton entitled Programmer's Guide To IBM Personal Computers, published by Microsoft Press in 1985, and in particular Chapter 14 entitled "DOS Basics". A case study which documents the importance of graphical programs is given in the article by Dennis J. Velazquez, entitled "Making The Switch From DOS To Windows MMI", which appeared on pages 58 and 59 of the A-B Journal, November 1995.

Finally, a problem exists in the prior art in that applications are restricted to interface with the operating system which do provide a graphics device interface at very high levels of abstraction in an object-oriented environment. The utility of object-oriented programming is not universal. Programs for e-mail, word processing, web browsing, spreadsheets, and computer-aided drawing are assembled much in the same way an automobile is assembled from pre-defined components. For a many applications, however, software development in an object-oriented environment is similar to writing a story given a collection of stock paragraphs. Either the story is so similar to existing stories that it is not worth writing, or it is highly unlikely that the appropriate combination of paragraphs exist to write the story. In the later case, the time required to find an appropriate combination of stock paragraphs would be prohibitively long. Applications development demands the flexibility of a programming language just as writing a good book demands the flexibility of the English language.

The present invention aims to overcome the aforementioned and other problems and deficiencies in the prior art.

Accordingly, it is an object of the present invention to provide an improved method of interfacing concurrent processes and physical devices in a computer system without the overhead, restrictions, and complexity imposed by operating systems in the prior art.

It is another object of the present invention to provide application programs with access to physical devices using methods to minimize utilization of system resources and corresponding scheduling delays.

It is another object of the present invention to provide programming interfaces between application programs and physical devices which can be configured at runtime to optimize its performance and customize its functional behavior in order to satisfy the requirements of a diverse suite of application programs.

It is another object of the present invention to provide a programming interface between application programs and a particular physical device in use which can be combined in a mix and match way with other such programming interfaces to additional devices in order to develop new applications.

It is another object of the present invention to provide programming interfaces between application programs and physical devices that may be utilized as follows:

(a) to provide system services which are absent from the operating system;

(b) to replace operating system services in cases when the implementation of these services is inadequate;

(c) to provide a degree of functional modularity so that the operating system does not have to be rewritten in order to accommodate new application program development; and

(d) to provide a degree of functional modularity so that new versions of the operating system do not invalidate existing applications.

It is another object of the present invention to provide preferred embodiments of such methods which will enhance the capability of microprocessors such as the x86 family of microprocessors manufactured by companies such as Intel, Cyrix, IBM, AMD, and IMS.

It is another object of the present invention to provide preferred methods designed for use with computers such as the IBM PC/AT which utilize the x86 family of microprocessors.

It is another object of the present invention to provide preferred embodiments of such methods that will enhance the performance and functionality of application programs running under the DOS operating system by providing programming interfaces to the 8253/8254 timer-chip and video graphics adapter.

It is another object of the present invention to provide such methods that will, in alternate preferred embodiments, schedule the duration, frequency, and phase of concurrent process activation times in order to avoid contention for system resources.

In accordance with the previous summary, objects, features and advantages of the present invention will become apparent to one skilled in the art from the subsequent description and the appended claims taken in conjunction with the accompanying drawings.

In the drawings, closely related figures have the same number but different alphabetic suffixes.

FIG. 1 is a block diagram representing a prior art programming interface between application programs and physical devices in a computer system.

FIGS. 2A to 2B are precedence graphs depicting the input-output relations, execution times, scheduling delays associated with the process sequence which is utilized in the prior art to provide application programs with a programming interface to physical devices.

FIG. 3 is a block diagram representing the programming interface between application programs and physical devices of the present invention.

FIGS. 4A to 4B are precedence graphs depicting the input-output relations, execution times, and scheduling delays associated with the process sequence which is utilized by the present invention to provide application programs with a programming interface to physical devices.

FIGS. 5A to 5R are diagrams illustrating the effect of input parameters to a function, in alternate preferred embodiments of the present invention, providing application programs running in DOS-protected mode with the capability to fill enclosed regions of the graphics display screen using one of seventeen different fill patterns.

FIG. 6 is a diagram illustrating the effect of input parameters to a function, in alternate preferred embodiments of the present invention, that provides application programs running in DOS-protected mode with text display capability.

In accordance with the present invention a programming interface to a physical device in a computer system comprises private data together with a library of routines which are dynamically bound to application programs, and which manipulate the physical device independently of any other process.

Referring to FIG. 3, two application programs 41, 42 and three physical devices 1, 2, 3 are shown. Also, three application program interfaces 51, 52, 53 of the present invention are shown.

The application program interface 51 consists of private data 61 and a set of routines 71 which expose the functionality of the physical device 1. The private data 61 influences the behavior of the library of routines. The library of routines 71 modify the private data 61 in order to record state information during periods of inactivity. The library of routines 71 respond to interrupts which may originate from the physical device 1. Furthermore, the library of routines 71 are invoked by application programs 41, 42 to perform services that require utilization of the physical device 1 and to modify the private data 61. The application program interface 51 is provided in a dynamic-link library so that the set of routines 71 may be shared between the application programs 41, 42 and utilized in conjunction with other such programming interfaces 52, 53 to additional physical devices 2, 3, respectively. Application programs 41, 42 only have to conform to the peculiarities of the library of routines 71, in terms of the method of passing data and control information, without regard to implementation details of requested services. The library of routines 71 are dynamically bound only to the application programs 41, 42 and incorporate a hardware-dependent representation of the physical devices 1. This representation is utilized to execute a sequence of actual device operations that are specific to the physical device 1 and collectively result in the completion of requested services. It can be seen that exactly one process per physical device and one level of dynamic binding is utilized to provide the programming interface 51 between application programs 41, 42 and the physical device 1.

Application program 41 must execute prior to application program interface 51 in order to request services that require reading data and status words from physical device 1. The application program interface 51 must execute prior to the application program 41 in order to provide the said service by reading data and status words which are output by physical device 1. Process input-output relationships and process execution times are represented by the precedence graph of FIG. 4A. If process 41 begins execution at time t=0 then the process sequence evolves as follows:

(a) process 41 for the period beginning at t=0 and ending at t=p.sub.R ;

(b) process 51 for the period beginning at t=p.sub.R and ending at t=p.sub.R +q.sub.R ; and

(c) process 41 for the period beginning at t=p.sub.R +q.sub.R and ending at t=p.sub.R +q.sub.R +r.sub.R ;

It can be seen that the scheduling delay is zero since the order of process activation is determined exclusively by process sequence input-output relationships. Furthermore, the time required by the application program interface 51 to provide services that require reading data and status words from physical device 1 is deterministic since the execution times p.sub.R, q.sub.R, r.sub.R are deterministic.

Application program 41 must execute prior to application program interface 51 in order to request services that require writing data and control words to physical device 1. Application program interface 51 writes data and control words to physical device 1 in order to provide the said service. Process input-output relationships and process execution times are represented by the precedence graph of FIG. 4B. If process 41 begins execution at time t=0 then the process sequence evolves as follows:

(a) process 41 for the period beginning at t=0 and ending at t=p.sub.w ; and

(b) process 51 for the period beginning at t=p.sub.w and ending at t=p.sub.w +q.sub.w. It can be seen that scheduling delays are zero since the order of process activation is determined exclusively by process sequence input-output relationships. Furthermore, the time required by the application program interface 51 to provide services that require writing data and status words to physical device 1 is deterministic since the execution times p.sub.w, q.sub.w are deterministic.

The present invention is now described with reference to preferred embodiments designed for implementation in computers, such as the IBM PC and compatibles, which utilize the family of microprocessors manufactured by Intel, IBM, AMD, and Cyrix. These embodiments are given only to illustrate the general principals of the invention and are not to be taken in a limiting sense. The true scope of the invention can be ascertained by reading the appended claims.

Source code for the programming interfaces to the video graphics adapter and 8253/8254 timer-chip is listed in Appendix A and Appendix B, respectively. This source code is compiled using Borland Pascal 7.0 to produce dynamic-linked libraries GDI.DLL and TIMER.DLL. Dynamic-linked libraries provide language independent, code-sharing capability between DPMI (DOS Protected-Mode Interface) clients to include application programs and other dynamically linked libraries as per DPMI Interface Specification 0.9. Therefore, the procedures and functions which are exported by GDI.DLL and TIMER.DLL may be utilized by all DPMI (DOS Protected-Mode Interface) clients which are present. Furthermore, GDI.DLL and TIMER.DLL may be combined in a mix-and-match way with other such application program interfaces providing access to additional devices in a computer system.

Procedures and functions which are exported by GDI.DLL are itemized on lines 1031 to 1044 of the source code listed in Appendix A. GDI.DLL provides a programming interface between DPMI clients and video graphics adapters which utilize VESA (Video Electronics Standards Association) compliant SVGA (Super Video Graphics Adapter) chips. Procedures and functions which are exported by TIMER.DLL are itemized on lines 1230 to 1234 of the source code listed in Appendix B. TIMER.DLL provides application program interface to the 8253/8254 timer-chip.

It will become evident from a description of the operation of preferred embodiments of the present invention that GDI.DLL AND TIMER.DLL provide DPMI clients with inter-process communication capability, a scheduler, and a graphics device interface. This capability is provided using methods which require only one process and one level of dynamic binding per physical device. Furthermore, the source code is optimized for speed. The speed of the graphics device interface, for example, is indicated by image display rates equal to 1136 frames per second, 128.times.128 pixels per frame, using the Cyrix P166+ microprocessor with 70nsec random access memory and ATI Mach-64 video graphics adapter board running in 800.times.600 VESA mode. Full screen image display update rates using this hardware equal 70 and 45 images per second running in 640.times.480 and 800.times.600 VESA mode, respectively.

The client/server model identifies the manner of using the application program interface of the present invention in order to insure compatibility with mature, well-understood software development tools and methodologies in the prior art. This model advocates a layered approach to systems development. The basic goal of layering is to break up the problems involved in systems development into manageable pieces. This partition exists both on a conceptual and implementation level in that developers are able to understand the problems separately and make improvements in solutions to the different problems separately. In this model, each layer is regarded as a server that waits to be asked by clients in the layer above to provide a specific service. Servers exploit the functionality of the layer below to provide higher-level system services to clients in the layer above. Usually there is a standard interface and clients only have to conform to the peculiarities of this interface without regard to implementation details of requested services.

With reference to FIG. 3, the application programs 41, 42 and application program interfaces 51, 52, 53 interact as clients and servers, respectively, as per the aforementioned client/server model. Specifically, the application program interfaces 51, 52, 53 exploit the functionality of physical devices 1, 2, 3 in the layer below in order to provide certain services to application programs 41, 42 in the layer above.

The manner of using the application program interface to the video graphics adapter is now described with reference to Appendix A and FIGS. 5 and 6.

The function lnitGraph attempts to initialize the application program interface to the video graphics adapter and returns an integer indicating the success or failure of the initialization. Input parameter PathToFiles is the name of the directory containing initialization files `C`, `A`, `L`, and `F`. Input parameter Mode selects the spatial resolution of the graphics display. The procedure TermGraph terminates the application program interface to the video graphics adapter.

The procedure SetPalette updates a palette which is initialized and maintained by the graphics device interface with a new color. The palette is a table which associates 256 color indices with points in red-green-blue color space. A pixel on the graphics screen may be set to a given color by specification of the color index, which may be viewed as a cross-reference to that color in the palette. Similarly, drawing colors are specified using the color index. Drawing colors include a foreground, background, and fill colors. Text is drawn using the current foreground color. Symbol contours, lines, and polygons are drawn using a combination of the current foreground and background colors. Arbitrarily shaped regions are filled using a combination of the current fill and background colors. SetPalette input parameters Red, Green, and Blue are the relative intensities of the red, green, and blue components of a color, respectively, on a scale of 0 to 63. Input parameter Index is the corresponding color index. For example, SetPalette(0,0,0,0) and SetPalette(8,63,33,0) associate color index values 0 and 8 with black and orange, respectively.

The procedure SetBackColor sets the background color for subsequent drawing until reset. Input parameter Index selects the background color from one of the colors in the palette.

The procedure SetForeColor sets the foreground color for subsequent drawing until reset. Input parameter Index selects the foreground color from one of the colors in the palette.

The procedure SetLineStyle sets a line style for subsequent drawing until reset. Input parameter Style is a 16-bit word whose bit pattern specifies the sequence of foreground and background colors which are used to draw points on a line. For example, if the current line style equals FFFF(hexidecimal) and 0000(hexidecimal) then solid lines are drawn in the current foreground and background colors, respectively. If the current line style equals 5555(hexidecimal) or AAAA(hexidecimal) then points on the line alternate between these two colors.

Regions enclosed by boundary points are drawn using a fill pattern. The fill pattern consists of a background color, fill color, and spatial pattern of binary pixels obtained by thresholding a dither matrix using the fill style. The relationship between the dither matrix, fill pattern, and fill style is shown by FIGS. 5A to 5R. If a pixel at horizontal and vertical location x and y, respectively, coincides with the region to be filled, then it is set to the background color if the current fill style is less than or equal to D(x mod 4, y mod 4), where D(i,j) is the dither matrix with elements given by FIG. 5A. Otherwise, the interior pixel is set to the fill color. The fill style is an integer greater than or equal to 0 and less than or equal to 16. The relationship between fill style and fill pattern is illustrated by FIGS. 5B to 5R. The procedure SetFillStyle sets the current fill style used for subsequent drawing until reset. Input parameter Style is the fill style. The procedure SetFillColor sets the fill color for subsequent drawing until reset. Input parameter Index specifies the fill color from the palette.

The procedure SetTextStyle sets a text style which is used for subsequent drawing until reset. The text style is a 16-bit word which specifies the text font, orientation, justification, and character spacing. SetTextStyle input parameter TextStyle specifies the text style. TextStyle bits 0-7 select one of eight different text fonts. With reference to FIG. 6, TextStyle bits 10-11 and 12-13 select text justification in the direction parallel and perpendicular to text direction. The constants JustifyLeft, JustifyCenter, and JustifyRight are used to select text justification in the direction parallel to text orientation. The constants JustifyTop, JustifyMiddle, and JustifyBottom determine text justification in the direction perpendicular to text orientation. Input parameter TextStyle bits 14-15 select the method of spacing adjacent characters centers in the direction parallel to character orientation. These methods include proportional or non-proportional character spacing. The effect of proportional character spacing is to pack the text display in the smallest possible area since the distance between adjacent character centers in the direction parallel to character orientation is proportional to character width. The effect of non-proportional character spacing is to arrange character centers on a regular, two-dimensional array of points. In this case, the distance between adjacent character centers in the direction parallel to character orientation is constant and does not vary with character width.

The procedure WriteText draws a text string. Input parameter Message is the text which is drawn using the current text style and foreground color. Input parameters X and Y are the horizontal and vertical location of a reference point on the graphics screen, respectively. The relationship between text location and orientation relative to this reference point and the current text justification and direction is illustrated by FIG. 6. In this Figure, the location of the reference point is indicated by the intersection of the dashed lines.

The procedure GetTextDimen gets the height and width of a text string drawn in the current text style. Input parameter Message is the text string of interest. Output parameters Width and Height are the horizontal and vertical text string dimensions in pixels, respectively.

The procedure SetGraphParam sets the current text style, line style, fill style, and drawing colors used for subsequent drawing until reset. Input parameter Param is a record of type GraphParameters with data fields consisting of the current foreground color, background color, fill color, line style, fill style, and text style. The procedure GetGraphParam gets the current text style, line style, fill style, and drawing colors. Output parameter Param is a record of type GraphParameters. If two or more scheduled processes update the display screen by changing graphics parameters, then these processes may need to save and restore the graphics parameters using GetGraphParam and SetGraphParam, respectively.

The function GetForeColor, GetBackColor, and GetFillColor returns the color index of the current foreground, background, and fill colors, respectively.

The procedure GetScreenDimen gets the spatial resolution of the graphics screen. Output parameters Width and Height are the horizontal and vertical screen dimensions in pixels, respectively.

The procedure BitBit combines the pixels in a window, defined as any rectangular region on the graphics screen, with the contents of the pixels stored in a buffer array using logical operators. The buffer array is a contiguous region of random access memory which stores the pixels in raster scan fashion. Input parameters X and Y are the horizontal and vertical coordinates of the upper left-hand corner of the window, respectively. Input parameters Width and Height are the horizontal and vertical window dimensions, respectively. Boolean input parameter ExOr determines if the logical operation used to combine pixels in the window and buffer array is XOR or AND. Input parameter BufPtr is a pointer to the buffer array.

The procedure ReadPicture copies the pixels in a window to a corresponding pixels in a buffer array. Input parameters X and Y are the horizontal and vertical coordinates of the upper left-hand corner of the window, respectively Width and Height are the horizontal and vertical dimensions of the window, respectively. Input parameter lmgPtr is a pointer to the buffer array.

The procedure WritePicture copies the pixels in a buffer array to corresponding pixels in a window. Input parameters X and Y are the horizontal and vertical coordinates, respectively, of the upper left-hand corner of the window. Width and Height are the horizontal and vertical dimensions, respectively. Input parameter lmgPtr is the pointer to the buffer array.

The function ReadPixel reads a pixel from the graphics screen. Input parameters X and Y are the horizontal and vertical coordinates of the pixel, respectively. ReadPixel returns the color index which was used to draw the pixel.

The procedure WritePixel writes a pixel to the graphics screen. Input parameters X and Y are the horizontal and vertical coordinates of the pixel, respectively. Input parameter Index is the color index which is used to draw the pixel.

The procedure FillScreen sets the entire background screen to a single color. Input parameter Index is the color index which is used to draw each pixel on the graphics screen.

The procedure MoveScreen pans and scrolls the entire graphics display by redefining its origin relative to the physical graphics screen. Input parameters X and Y are the horizontal and vertical coordinates, respectively, of the pixel which appears in the upper-left-hand corner of the graphics display screen after execution of MoveScreen.

The procedure MoveWindow pans and scrolls all pixels inside a window. Input parameters X and Y are the horizontal and vertical coordinates of the upper left-hand corner of the window, respectively. Input parameters Width and Height are the horizontal and vertical window dimensions, respectively. Input parameters dX and dY are the number of pixels in which to move the window in the horizontal and vertical directions, respectively. The new location of the upper left-hand corner of the window after panning and scrolling is given by horizontal and vertical coordinates X+dX and Y+dY, respectively.

The procedure WriteLine draws a line specified by its endpoints using the current line style, foreground color, and background color. Input parameters X0 and Y0 are the horizontal and vertical coordinates of the first endpoint of the line, respectively. Input parameters X1 and Y1 are the horizontal and vertical coordinates of the second endpoint of the line, respectively.

The procedure WriteRectangle draws a rectangle consisting of four lines which are drawn in the current foreground color, background color, and line style. Input parameters X0 and Y0 are the horizontal and vertical coordinates of the upper left-hand corner of the rectangle, respectively. Input parameters X1 and Y1 are the horizontal and vertical coordinates of the lower right-hand corner of the rectangle, respectively.

The procedure WriteCircle draws a circle specified by its radius and center using the current foreground color. Input parameters X and Y are the horizontal and vertical coordinates of the circle center, respectively. Input parameter R is the radius of the circle. Input parameter Fill determines if the area enclosed by the circle is filled using the current fill pattern.

The procedure WriteCross draws a cross specified by its location and size using the current foreground color and line style. Input parameters X and Y are the horizontal and vertical coordinates of the center of the cross, respectively. Input parameter Size determines the size of the cross.

The procedure WriteCrossHairs draws crosshairs specified by its location and size using the current foreground color and line style. Input parameters X and Y are the horizontal and vertical coordinates of the center of the crosshairs, respectively. Input parameter Size determines the size of the crosshairs.

The procedure WriteDiamond draws a diamond specified by its location and size using the current foreground color and line style. Input parameters X and Y are the horizontal and vertical coordinates of the center of the diamond, respectively. Input parameter Size determines the size of the diamond. Input parameter Fill determines if the area enclosed by the diamond is filled using the current fill pattern.

The procedure WriteStar draws a star specified by its location and size using the current foreground color and line style. Input parameters X and Y are the horizontal and vertical coordinates of the center of the star, respectively. Input parameter Size determines the size of the star.

The procedure WriteWye draws the letter "Y" specified by its location and size using the current foreground color and line style. Input parameters X and Y are the horizontal and vertical coordinates of the center of the letter "Y", respectively. Input parameter Size determines the size of the letter "Y".

The procedure WriteSymbol draws a symbol specified by its location, size, and index using the current foreground color, background color, fill color, and line style. Input parameters X and Y are the horizontal and vertical coordinates of the center of the symbol, respectively. Input parameter Size determines the size of the star. Possible symbols which are selected by input parameter Spec include a point, star, cross, crosshairs, diamond, rectangle, circle, triangle, solid diamond, solid rectangle, solid circle, and the letter "Y".

The procedure WritePolygon draws a bar graph or polygon using the current drawing colors and fill style. Polygons may be drawn a symbol at each vertex of the polygon. Also, lines may be used to connect adjacent pairs of vertices. The procedure WriteSymbol is called by WritePolygon to draw a symbols at each vertex if input parameter Spec is greater than 1, in which case Spec and input parameter Size determine the symbol drawn at each vertex and its size, respectively. Input parameter Cnt is the length of the polygon or number of vertices. If input parameters Yb equals 1 then vertices are connected with lines using the current foreground color, background color, and line style. If input parameter Yb is greater than 1 then a bar graph is drawn using the current fill color, background color, and fill style where Yb is taken as the vertical position of the horizontal axis. If input parameter Yb equals 0 then only symbols are drawn at each vertex if Spec is greater than 1. Input parameter Poly is an array of polygon vertices.

The procedure FillBoundary fills the area enclosed by a polygon using the current fill pattern. Input parameters X and Y are the horizontal and vertical coordinates of any point inside the polygon, respectively. Input parameter Edge is the color index of the polygon boundary points.

The procedure UpdatePolygon updates a fixed-length polygon and corresponding display with a new data point. In many applications polygons represent a windowed sequence of numbers which evolve in time at fixed measurement update intervals. When an additional number of a windowed sequence that was previously drawn using WritePolygon becomes available, UpdatePolygon may be used to update the numbers inside the window and display the result. Input parameter Y is the new data point. The procedure WriteSymbol is called by WritePolygon to draw a symbols at each vertex if input parameter Spec is greater than 1, in which case Spec and input parameter Size determine the symbol drawn at each vertex and its size, respectively. Input parameter Cnt is the length of the polygon or number of vertices. If input parameters Yb equals 1 then vertices are connected with lines using the current foreground color, background color, and line style. If input parameter Yb is greater than 1 then a bar graph is drawn using the current fill color, background color, and fill style where Yb is taken as the vertical position of the horizontal axis. If input parameter Yb equals 0 then only symbols are drawn at each vertex if Spec is greater than 1. Input parameter Poly is an array of polygon vertices.

The procedure WriteBar draws a solid, rectangular region using the using the current fill pattern. Input parameters X0 and Y0 are the horizontal and vertical coordinates of the upper left-hand corner of the bar, respectively. Input parameters X1 and Y1 are the horizontal and vertical coordinates of the lower right-hand corner of the bar, respectively.

The procedure WriteTag draws a tag consisting of a text string superimposed on a bar which is large enough to enclose the text string. Input parameter TagStr is the text string. Input parameters PosX and PosY are the horizontal and vertical location of the center of the bar, respectively. Boolean input parameter Border enables drawing of the bar perimeter using the color indexed by input parameter Fore. Input parameter Justify determines the justification of the text string relative to the four edges of the bar. Input parameters Fore and Back select the color in which the text string and bar are drawn from the colors in the palette, respectively.

The procedure WriteTriangle draws a triangle specified by three vertices using the current line style, fill style, and foreground, background, and fill colors. Input parameters X0 and Y0 are the horizontal and vertical coordinates, respectively, of the first vertex of the triangle. Input parameters X1 and Y1 are the horizontal and vertical coordinates, respectively, of the second vertex of the triangle. Input parameters X2 and Y2 are the horizontal and vertical coordinates, respectively, of the third vertex of the triangle. Input parameter Fill enables filling the interior of the triangle using the current fill pattern.

The manner of using the application program interface to the 8253/8254 timer-chip is now described with reference to Appendix B.

The Intel 8253/8254 timer-chip consists of a timer-register, timer-counter, and time-base oscillator. The 16-bit timer-counter is continually decremented by the time-base oscillator at a rate of 1193180 Hz. Two events coincide with each timer-counter transition from 1 to 0. First, the timer-counter is reset by the 8253/8254 timer-chip using the contents of the timer-register. Second, a timer-tick interrupt is generated by the 8253/8254 timer-chip which activates a timer-tick interrupt procedure. The timer-tick interrupt procedure is the interrupt service routine with hardware interrupt vector number equal to 8. Effectively, the timer-register down converts the time-base oscillator frequency to determine the timer-tick interrupt rate, which is equal to 1193180 divided by the contents of the timer-register in Hz. The function InitScheduler initializes the application program interface to the 8253/8254 timer-chip by setting the timer-register value, creating a process descriptor list, saving the original timer-tick interrupt procedure, and directing timer-tick interrupts to interrupt procedure UpdateScheduler. The process list records information corresponding to each process which is managed by the application program interface to the 8253/8254 timer-chip. UpdateScheduler utilizes information contained in the process list in order to control process duration and activation times. InitScheduler writes input parameter RegValue to the timer-register in order to establish the scheduler interrupt rate. The scheduler interrupt rate equals 1193180/RegValue in Hz. Also, InitScheduler input parameter RefValue sets the frequency of a phase reference signal. The phase reference signal occurs every RefValue timer-tick interrupt or RefValue.times.RegValue/1193180 seconds, and is utilized to control the phase of process activation times in order to avoid contention for system resources.

The procedure TermScheduler terminates the application program interface to the 8253/8254 timer-chip and directs timer-tick interrupts to the original timer-tick interrupt procedure.

The procedure GetSchedParam gets the timer-register value and phase reference interval. Output parameter RegValue is the 8253/8254 timer-register value which determines the timer-tick interrupt rate. Output parameter RefValue is the phase reference interval.

The function GetTimerTicks returns the number of timer ticks modulo 65536 to provide a time reference which is incremented at a rate equal to the timer-tick interrupt rate.

The procedure GetProcList gets the process descriptor list. Output parameter NumPtr is a pointer to an integer equal to the number entries in the process descriptor list. Output parameter ListPtr is a pointer to the process descriptor list, which is declared in the source code as an array of process records. Process record data field VectNum is the software interrupt vector number of a process activation procedure. The process activation procedure is an interrupt procedure of type ActvProcedure, declared on line 1040 of the source code, which is utilized by UpdateScheduler to initiate process execution. Activated processes remain in a current state of execution until the activation procedure terminates, in which case the process enters a suspended state of execution. Process record data field CommProc is the starting address a process communication procedure. The communication procedure is a procedure of type CommProcedure, declared on line 1041 of the source code, which is utilized by the process to receive messages sent from other processes. Process record data field DescPtr is a pointer to private memory which may be utilized by the process to record a set of state variables. State variables may be utilized to customize the process for a particular application by defining and controlling the process runtime behavior. It can be seen that it is possible to create multiple processes with different runtime behavior using a single process activation procedure if the parameters which initialize process state variables are unique. Process record data field OkToRun determines if scheduled process activity is enabled or disabled. Disabled processes are ignored by UpdateScheduler until subsequently enabled. Process record data fields EventToGo, ActPeriod, and ActPhase control the number, frequency, phase of enabled process activation times. Process record data field TicksToGo is the number of timer-tick interrupts remaining until process activation. If the process is enabled, UpdateScheduler decrements the TicksToGo field in response to timer-tick interrupts. Coinciding with each TicksToGo transition from 1 to 0, EventToGo is decremented if its value is not equal to 65536. Furthermore, the process activation procedure is executed and TicksToGo is set to ActPeriod if the decremented value of EventToGo is greater than 0. If EventToGo equals 0, the processes is terminated and removed from the process descriptor list. Just as the timer-register down converts time-base oscillator frequency to determine the timer-tick interrupt rate, ActPeriod down converts the timer-tick interrupt rate to determine the activation procedure interrupt rate. It can be seen that process activation frequency equals the timer-tick interrupt frequency divided by ActPeriod. Initial execution of the process activation procedure is delayed until the number of timer-tick interrupts which occur after generation of the phase reference signal equals ActPhase. It can be seen that process activation phase equals ActPhase divided by one over the timer-tick interrupt frequency.

The procedure DisableScheduler disables the scheduled activation of all processes until subsequently enabled or the scheduler is terminated.

The procedure EnableScheduler resumes the scheduled activation of all processes if currently disabled.

The function SchedProcess schedules the activity of a process specified by its activation procedure and process descriptor, and the period, phase, and duration of its activation times. SchedProcess returns a process identification number which uniquely identifies the process. Input parameters DscPtr, Count, Period, Phase, and Enable initialize data fields DescPtr, EventToGo, ActPeriod, ActPhase, and Enable, respectively, of an available process record in the process descriptor list. Furthermore, the number of entries in the process descriptor list is increased by 1. Input parameter IntPtr is the starting address of the process activation procedure. The application program interface to the 8253/8254 timer-chip communicates with a given process at the time of its activation by setting activation procedure input parameters AX, BX, CX, SI, DI as follows:

(a) AX is the timer-tick interrupt count modulo 65536;

(b) BX is the process identification number equal to process record data field VectNum;

(c) CX is the current value of EventToGo which is equal to the number of timer-ticks until process termination;

(d) SI and DI is are the segment and offset address of DscPtr.

Interleaving the execution times of multiple processes by controlling their phase relative to each other serves to smooth microprocessor loading and avoid contention. Input parameter Count may be used to create precision countdown timers and alarms.

The procedure RemoveProcess terminates a process. Input parameter Procld is the process identification number.

The procedure EnableProcess enables the scheduled activation of a single process until subsequently disabled or the scheduler is terminated. Input parameter Procld is the process identification number.

The procedure DisableProcess disables the scheduled activation of a single process until subsequently enabled by EnableProcess. Input parameter Procld is the process identification number.

The procedure SetCommProc associates a process which is listed in the process list with a procedure which handles interprocess communication of data and/or control information. Input parameter Procld is the process identification number. Input parameter CommProc is the starting address of the process communication procedure. Communication procedures accept as an input five parameters. Communication procedure input parameter Src is the process identification number of the sender. Communication procedure input parameter Code is an application specific control word determined by the sender. Communication procedure input parameter DscPtr is a pointer to the private memory of the receiver process. Communication procedure input parameter Size is the length of a data buffer created by the sender, and DatPtr is the pointer to that data buffer.

The function SendPacket sends a variable length packet to a specific process. Input parameter Src is the identification number of the process which creates the packet and subsequently calls SendPacket. Input parameter Dst is the process identification number of the packet destination. Input parameter Code is the application specific control word determined by the sender. Input parameter Size is the length of a data buffer created by the sender. Input parameter DatPtr is the pointer to this data buffer. If Dst corresponds to a currently scheduled process, SendPacket invokes the communication procedure associated with the destination process and returns TRUE. Otherwise, SendPacket returns FALSE.

Thus the reader will see that application program interface of the present invention provides a programming interface between application programs and a physical device in a computer system. The application program interface consists of private data and of a library of routines which are dynamically bound to application programs. The library of routines may be utilized in a mix-and-match way with each other and also the library of routines provided by other such programming interfaces to additional devices. Furthermore, the library of routines of the programming interface perform hardware-dependent manipulation of the physical device in order to expose its functionality in a manner which minimizes utilization of computer resource and maximizes speed of execution. In contrast to the prior art, a single level of dynamic binding is utilized to provide the programming interface of the present invention.

Preferred embodiments of the present invention enhance the capabilities of the IBM personal computer and compatibles, and provide convincing evidence regarding the significant advantages of the present invention relative to the prior art. The preferred embodiments include application program interfaces which expose the functionality of the 8253/8254 timer-chip and VESA-compatible video graphics adapter chips. Collectively, these application program interfaces provide thread scheduling services, inter-process communication, and a graphics device interface to DPMI clients while utilizing less than 20 and 1.1 Kbytes of program and data memory, respectively. This capability enables the development of a diverse suite of visual programs which exploit the language-independent, code-sharing capability of dynamically linked libraries without the restrictions, complexity, and overhead of operating systems in the prior art. Program memory requirements of the Windows 3.11 operating system components providing access to the video graphics adapter and 8253/8254 timer-chip is not disclosed, but is approximated by the sum the files GDI.EXE, KERNEL.EXE, VGA.DRV, and TIMER.DRV. The sum of these files is equal to 375 Kbytes, which is at least 18 times greater than the program memory requirements of the programming interfaces of the present invention.

The programming interface of the present invention does not reflect the requirements of any particular set of applications or model of computing. This type of functional modularity protects investment in the development of applications software, effectively allowing programmers to focus their energies on the parts of new applications development which are unique instead of the parts which are common to a variety of applications, and businesses to leverage baseline software technologies in order to penetrate new markets.

The reader will recall that in 1985 Microsoft published a book stating that two or more application programs running under DOS are unable to share video hardware through a common graphics device interface. This capability is provided by the programming interface to the video graphics adapter of the present invention. Furthermore, the performance of this programming interface is unprecedented in the prior art. Running in 800.times.600 VESA mode on the Cyrix P166+ microprocessor with 70nsec random access memory and the ATI Mach-64 video graphics adapter, the execution time required to update a 128.times.128 pixel image display is less than 88 .mu.sec. With reference to the Quake Frame Rate Benchmark List, which is posted on the World Wide Web at http://www.cam.org/.about.agena/quake.html#version, full screen image update rates permitted by the programming interface of the present invention are 5.2 and 4.6 times faster than that achieved in the prior art using the Cyrix P166+ in combination with any graphics video adapter running in 640.times.480 and 800.times.600 VESA mode, respectively.

Concurrent process duration, frequency of occurrence, and phase are individually programmable by the programming interface to the 8253/8254 timer-chip of the present invention. This innovative feature allows designers to:

(a) develop and validate application programs with deterministic execution and response times;

(b) develop timelines that eliminate the need for elaborate schemes to synchronize the activity of concurrent processes;

(c) interleave concurrent process execution times in order to avoid contention for shared resources in a computer system;

(d) implement timing services to include synchronous alarms, clocks, timers, and delay functions; and

(e) generate time stamps with better than 1 .mu.sec accuracy.

Time stamp accuracy is independent of the scheduler update interval which is programmable from 18.2 Hz to 9.94 KHz.

While my above description contains many specificities, these should not be construed as limitations on the scope of the invention, but rather as an exemplification of preferred embodiments thereof. Many other variations are possible. For example, a programming interface of the present invention may be utilized to expose the functionality of additional devices which may be present in a computer system, such as a printer, modem, sensor data acquisition board, or digital signal processor. The source code implementing preferred embodiments of the present invention can be modified to improve its performance, to provide a programming interface to improved versions of the physical device, or to provide an interface to similar devices. For example, the source code of the present invention may be modified according to DPMI Interface Specification 1.0 and compiled using the TMT Pascal compiler for DOS, available from TMT Development Corporation, in order to optimize the performance of applications running on 32-bit microprocessors. In another example, the application program interface which permits the development of visual programs can be modified to interface to video graphics adapters which utilize the family of non-VESA compatible SVGA chips from manufacturers such as Ahead, ATI, Chips and Technology, Cirrus, Compaq, Everex, Genoa, NRC, OAK, Paradise/Western Digital, S3, Trident, TSENG, and Video 7.

Accordingly, the scope of the invention should be determined not by the embodiments illustrated, but by the appended claims and their legal equivalents. ##SPC1##