OS/2 Comm Drivers

The OS/2 Data Communications Driver Who does what? Is it important?

By Ray Gwinn ÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ

When you initiate a download or upload, what role does your communications application program play? What role does an OS/2 communications device driver play? When your favorite BBS paints a picture on your screen, how does the information reach the screen? The roles of the OS/2 communications device driver and the communications application program are misunderstood by many. I hope to clear up some of the confusion by clarifying the function of the OS/2 communications device driver in this article.

References below to "the driver" are referring to the OS/2 communications driver. In addition, this article ignores DOS and WinOS/2 communications under OS/2 which is a related but separate subject.

The settings, buzz words, and tweaking options of data communications are both bewildering and fascinating to users. Many will be surprised to know that a standard OS/2 communications device driver is modem ignorant (a major design     flaw). This is why you perform any modem configuration in the application program and not elsewhere such as your CONFIG.SYS. The driver only passes a stream of data characters to and from the application program. This means that the driver is unaware of any upload or download protocol, such as ZMODEM. Again, the upload and download protocols as well as screen painting are completely implemented by the application program while the driver is only passing a character stream. On the other hand, the application program is unaware of the I/O port address and IRQ of the communications port under OS/2 as the hardware is only accessed by the driver. This is why an OS/2 communications program does not (need not) ask for I/O address and IRQ of the communications port.

The OS/2 operating system provides a good environment (the best     known to the author) for data communications. The OS/2 communications device driver provides a software interface between the applications program and the communications hardware. The above statement "only passing a character stream" is a     tremendous understatement. The communications device driver is     probably the most complicated device driver that any operating system may provide; and many operating systems provide none at     all (such as DOS). The communications driver seems (to the     author) to have innumerable tasks to perform and check. The lowest level of the driver is the interrupt service routine. The highest levels of the driver include processing commands from the OS/2's kernel and command line processing at load time. The higher levels also block (suspend) execution of the application program when a received request cannot be satisfied. The interrupt levels usually unblock the application when the operation can be (or has been) satisfied. The driver also performs time critical functions that are happening so fast that the application can not respond in time. An example is     handshaking of all types.

Fast interrupt response, short duration of interrupt service processing, and buffering of data are critical to the smooth operation of a multi-tasking operating system like OS/2. Readers should be aware that driving a modem at its maximum data rate is     not a good measure of the speed of a driver. Data rates over normal dial up phone lines are now approaching 3000 characters per second. Depending upon the installed hardware, this can mean as many as 3000 interrupts a second for communications alone. A     high interrupt rate and a poorly coded driver will bring a system to its knees by using large amounts of processor time to service the interrupts. The time required to service interrupts is often referred to as overhead or processor overhead. The amount of     processor overhead that a driver places on the system is an      important measure of the quality of that driver. Overhead caused by DOS and Windows communications programs are beyond the scope of this article.

For the on line, hooked in generation, the communications device driver is one of the most important and most overlooked drivers on their system. If it ever becomes a reality, the much acclaimed Information Superhighway will only increase the importance of the communications device driver. New technologies, like the COM-bic UART developed by Hayes Microcomputer Products Inc., insure the data communications hardware is ready for operating systems like OS/2 and the future. Good device drivers for a given operating system, written by      experienced communications professionals are needed to insure that software is also ready for the future.

Ray Gwinn