Method and Apparatus for Communicating Peripheral Data to/From Minor Operating Systems Running as Subprocesses on a Main Operating System

A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office file or records, but otherwise reserves all copyright rights whatsoever. (37 C.F.R. .sctn.1.71(d)-(e).) Specifically, the computer program in Appendix A, which is incorporated herein, is subject to such copyright protection.

The present invention relates generally to computer systems and more particularly to computers having a minor operating system that runs under a main operating system and the processing executed under the environment of the minor operating system does data I/O with peripheral equipment controlled by the main operating system.

UNIX operating systems for personal computers has recently begun to appear in the American market. The IBM model AT and other 80386 based machines, such as from COMPAQ have been selling and will support UNIX. In particular, the AT&T System V Release 4 (or 3.2) UNIX runs on 386-based personal computers.

But only a very few application programs will run directly under UNIX. Whereas thousands of programs are compatible with the original MS-DOS operating system offered by IBM and Microsoft. So utilities that enable MS-DOS applications to run under UNIX begun to appear. Called "DOS BOX," MERGE 386 by Locus Computing and VP/IX by Interactive Systems and Phoenix Technologies. In a conventional DOS BOX, when an I/O command is generated by an MS-DOS application program, the activity is detected by a UNIX device driver. An emulation is then engaged to satisfy the MS-DOS device driver. In such cases, the time to do an I/O can be very long. For example, see Japanese Laid Open Patent 62-78631 (Apr. 10, 1987). Eliminating such emulations of peripherals would speed up the overall system.

Peripherals in prior art computer systems are typically under the control of a single, main operating system. Application programs run under the main operating system and transfer data with peripherals via device drivers provided by the main operating system. Minor operating systems emulate device drivers.

A keyboard, when operated, will usually trigger an input interrupt handler in a main operating system. Data is input and interpreted before being temporarily stored. The occurrence of such an input event and the stored input string will be messaged to a minor operating system as dummy interrupts, which activates an input interrupt handler. The minor operating system interprets the messages from the main operating system, and transfers the input type to an input buffer in a memory. Interrupt handlers therefore enable both the main operating system and minor operating system to accept keyboard and/or application program input.

But overlapping input interpretations in both operating systems creates an undesirable processing overhead. The system response to input and output can be very slow for application programs running under a minor operating system, so real time performance is sacrificed.

According to an embodiment of the present invention, a computer system comprises a minor operating system running under a main operating system configured such that applications programs running in the minor operating system's environment exchange data with systems peripherals solely controlled by the main operating system. The minor operating system has a memory that temporarily stores data for exchange with peripherals and a first device driver that shuttles an exchange of data between the process and peripherals via the memory. In the main operating system a data request detector responds to peripheral data I/O requests. A request handler determines whether or not a request corresponds to the minor operating system. A second device driver outputs and stores data to and from peripherals between memory associated with the first device driver and the peripherals when a request has been determined to correspond to the minor operating system. The input processing I/O with peripherals can comprise only input processing, only output processing, or both. The first device driver is used for keyboard input and the second device driver directly rewrites the contents of the memory in the first device driver. Determining whether or not data requests are related to the minor operating system involves referring to control data of the subprocess running under by the main operating system.

An advantage of the present invention is that processing overhead is significantly reduced and real-time performance is thus improved.

Other objects and attainments together with a fuller understanding of the present invention will become apparent and appreciated to those skilled in the art by referring to the following description and claims together with the accompanying drawings.

FIG. 1 is a block diagram of a system environment that exists in a first embodiment of the present invention;

FIG. 2 shows that the main operating system for the system of FIG. 1 contains the minor operating system which has the input buffer and application program control area;

FIG. 3 is a flowchart of the input interrupt handler for the system of FIG. 1;

FIG. 4 is a block diagram of a hardware system according to a second embodiment of the present invention;

FIG. 5 is a schematic of the data flow in the system of FIG. 4 from the keyboard to the driver interrupt handler and second keyboard driver in the main operating system, to the key interrupt routine and first keyboard driver in the minor operating system, to the application program running under the minor operating system;

FIG. 6 is a flowchart of the driver interrupt handler in the second embodiment of FIG. 4; and

FIGS. 7A and 7B diagram the situation that exists when key input for a minor operating system is assigned to one of multiple processes running under the main operating system.

FIG. 1 is a system according to a first embodiment of the present invention. When a request for data input originates in a peripheral 10, the request is sensed to by a data request detector 12. If the request is determined by a request decoder 14 to correspond to a minor operating system 16, a device driver 18 in a main operating system 20 stores the necessary data directly into a memory 22 within a device driver 24. Driver 18 can exchange data for external peripherals with either memory 22 or main operating system 20, depending on whether or not minor operating system 16 should be involved in the transfer. Data stored in memory 22 can be read by or deposited any time by a process 26, such as an applications program, executing under the minor operating system 16. Device driver 24 puts output data from process 26 in memory 22. Output is sensed by detector 12. Decoder 14 determines whether or not the output corresponds to the minor operating system 16. If it does, then device driver 18 will output data stored in memory 22 directly to peripheral 10. Requests for the data I/O are tested to see if they correspond to the minor operating system 16. If they do, data is exchanged directly between memory 22 and peripheral 10. Process 26 is saved the burden of determining the environment minor operating system 16 is operating in. Systems 16 and 20 can share the same data I/O processes, and reduce system overhead as a result. Application programs emphasizing real-time performance can therefore be run under minor operating system 16.

In FIG. 2, a central processing unit (CPU) 31 communicates with a memory 32, an input peripheral 33, and a display 34. Memory 32 comprises a main memory area 35, and a minor memory area 36. Memory area 36 has an input buffer 38 that stores a line of type input from input peripheral 33. Main memory area 35 is accessible to a main operating system (e.g., a UNIX such as main operating system 20) running on CPU 31. Memory area 36 can be managed by a minor operating system (e.g., a MS-DOS such as minor operating system 16) running on CPU 31. A memory area 37 is reserved for loading an application program and its use.

The computer system of FIGS. 1 and 2 use a computer-implemented process represented by the flowchart of FIG. 3. In step 50, the computer system waits for input by being sensitive to interrupts coming from input peripheral 33. When an interrupt associated with data being input is received by CPU 31, an input interrupt handler in the main operating system is automatically called. Step 60 determines if the input is intended for a minor operating system running on CPU 31 (e.g., the respective peripheral had been assigned by the application program to run with the minor operating system). If so, step 70 emulates the original minor operating system's input interrupt handler, and data input is directly transferred to an input buffer, such as buffer 38. The minor operating system can thereby communicate input to an application program as if it were a real-time input event and had been taken care of by its own input interrupt handler. If input is not for the application program, then control is directed to step 80 which invokes the main operating system's interrupt handler.

FIG. 4 is a computer system according to a second embodiment of the present invention and comprises a CPU 101, a floating point unit (FPU) 102, a read only memory (ROM) 104, a random access memory (RAM) 105, a programmable interval timer (PIT) 106, a real time clock (RTC) 108, a direct memory access controller (DMAC) 110, a serial I/O (SIO) 111, a programmable interrupt controller (PIC) 112, a mouse 114 and interface 115, a keyboard 117 and interface 118, a floppy disk drive (FDD) 120 and controller (FDC) 121, a hard disk drive (HDD) 124 and controller (HDC) 125, a cathode ray tube (CRT) display 128 and controller (CRTC) 129, a printer 130 and interface 131, and an expansion slot 140. Devices 101 through 140 communicate via a bus common to all. CPU 101 is preferably an Intel 80386, or equivalent. FPU 102 is a floating point unit that operates as a coprocessor to CPU 101. ROM 104 stores a monitor program, etc. RAM 105 is the main memory and is read/write. PIT 106 is an interval timer that generates a periodic interrupt. RTC 108 is a real time clock circuit with a back up power supply source to keep the time. DMAC 110 controls direct memory transfers via the bus. SIO 111 controls RS-232C serial communications. PIC 112 is a interrupt controller that assigns a priority to and controls each type of interrupt. Mouse interface 115 receives user commands via the two-button mouse 114. Keyboard interface 118 receives user keyed input from keyboard 117. FDC 121 is a flexible disk controller that controls the flexible disk driver (FDD) 120. HDC 125 is a hard disk controller that controls the hard disk drive (HDD) 124. CRTC 129 sends video signal output to CRT 128, which displays the necessary data, etc. Printer interface 131 controls the output of data to the printer 130. Expansion slot 140 is used for future expansion, such as with add-on cards.

The computer system uses a time-multiplexed operating system capable of multitasking as both a main operating system and a single-tasking disk operating system running as a subprocess (minor operating system). Various types of application programs can be run under the control of the main operating system. Some commercially available application programs may only be able to run under the minor operating system. Keyboard 117, flexible disk drive 120, mouse 114, and the other peripherals, are all controlled by the main operating system. Data is exchanged between them and a process running on the main operating system via device drivers included in the main operating system. Data cannot be directly exchanged between peripherals and the minor operating system which has conventional device drivers. Application programs running under the minor operating system will input and output data via the various device drivers of the minor operating system, just as if the minor operating system was being used alone.

When the minor operating system is operating alone and there is an interrupt request from a peripheral, the minor operating system's device driver issues an input instruction (IN) or an output instruction (OUT) to the hardware assigned to the I/O address. Here, interrupt requests from the peripheral are controlled by the main operating system, and any interrupt request can be steered to the main operating system device driver or minor operating system device driver, as required. For example, input data from keyboard 117 will cause an interrupt request to be output to the keyboard driver in the main operating system, and will not be received by the keyboard driver of the minor operating system.

FIG. 5 shows how data flows from a keyboard up to an application program. FIG. 6 flowcharts the driver interrupt handler in the keyboard driver (e.g., driver 18) in the main operating system. When a key on a keyboard 117 is depressed, an interrupt is generated via a keyboard interface 118. This interrupt is routed to PIC 112 (FIG. 4), and if the interrupt is allowed, then processing is done by driver 18. An interrupt handler in the main operating system is called, and in step 200, data is read in from keyboard 117 via the keyboard interface 118. Step 210 determines whether or not keyboard 117 is currently assigned to the minor operating system by referring to an attribute table controlled by a system kernel, which is a subprocess in the main operating system. If data from keyboard 117 is assigned to the minor operating system, in step 220 data is written to a key input condition table so that the minor operating system can discriminate which key on the keyboard has been pressed. Step 230 checks to see if it was the shift key that was pressed, and if it was, then the shift condition table is substituted and step 250 converts the key code to a character code, which is output to the keyboard buffer in step 260. Afterwards, the routine executes a return. If step 210 decided the keyed input was not for the minor operating system, step 270 sends the data to the main operating system. Driver 18 stores data in a form that allows the main operating system to receive requests from the application program and it can also supply keyed input data to an application program.

Refer now to FIGS. 7A and 7B. Multiple subprocesses can be operated under a main operating system, and any of them can be minor operating systems. The subprocesses not necessarily need to deal with the fact that they are running as subprocesses. Keyboard 117 is assigned to a first process for purposes of this explanation only. Data from keyboard 117 is stored in a memory reserved to a keyboard driver belonging to the main operating system. The data is passed to the first process by a data request (system call) from the first process. But if keyboard 117 has been assigned to the minor operating system, the data is written directly to a table and buffer in a keyboard driver in a third process comprising a minor operating system (FIG. 7B) and an applications program. So, when data input from keyboard 117 has been assigned to a particular minor operating system, the keyboard drivers in the main operating system and the minor operating system do not duplicate each other, thus preventing an unnecessary overhead. This facilitates the running of application programs that emphasize real time performance. Since minor operating systems that operate as subprocesses of a main operating systems do not need to discriminate whether they are running on a main operating system or are running directly, the minor operating system and application programs that operate under the control of the minor operating system do not require any modification. Therefore, prior software libraries can be used to full advantage while also actively using high level main operating system.

A computer program listing is included here in Appendix A and represents one way to implement the above in "C" source code. At page 1, line 2, of Appendix A, the phrase if (V-active) checks to see if the current process is minor operating system and if so, sets a flag. At line 5, "*cp++" inputs data from device driver (key data). "Keyin" copies to memory 22. After line 8, the request decoder in data request detector 12 is implemented. Lines 12 through 214, spanning pages 1 through 4 constitute the table referred to in FIG. 6. The "keyin(procp, atscan)" phrase at line 217 begins steps 220 through 260 (FIG. 6). Lines 1-36 on page 8 of Appendix A are the data definition which is used in FIG. 6.

The present invention is not limited to the embodiments described above. Other input peripherals can be handled, as well as output devices. Whatever the peripherals being used, it is important to assign each temporarily or permanently to the minor and/or main operating systems such that those assignments can be accessed each time the main operating system's device drivers have peripheral data traffic.

While the present invention has been described in conjunction with several specific embodiments, it is evident to those skilled in the art that many further alternatives, modifications and variations will be apparent in light of the foregoing description. Thus, the present invention described herein is intended to embrace all such alternatives, modifications, applications and variations as may fall within the spirit and scope of the appended claims. ##SPC1##