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