OS/2 Comm Drivers

From OS2World.com Wiki
Revision as of 04:17, 25 May 2020 by Martini (talk | contribs) (Created page with " The OS/2 Data Communications Driver Who does what? Is it important? By Ray Gwinn ÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ When you...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

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


     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
     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