OS/2 Comm Drivers: Difference between revisions

From OS2World.Com Wiki
Jump to navigation Jump to search
(Created page with " The OS/2 Data Communications Driver Who does what? Is it important? By Ray Gwinn ÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ When you...")
 
No edit summary
Line 1: Line 1:
;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 OS/2 Data Communications Driver
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.
Who does what?  Is it important?


By Ray Gwinn
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.


      When you initiate a download or upload, what role does your
Fast interrupt response, short duration of interrupt service
      communications application program play?  What role does an OS/2
processing, and buffering of data are critical to the smooth
      communications device driver play? When your favorite BBS paints
operation of a multi-tasking operating system like OS/2.  Readers
      a picture on your screen, how does the information reach the
should be aware that driving a modem at its maximum data rate is
      screen? The roles of the OS/2 communications device driver and
not a good measure of the speed of a driver. Data rates over
      the communications application program are misunderstood by many.
normal dial up phone lines are now approaching 3000 characters
      I hope to clear up some of the confusion by clarifying the function
per second. Depending upon the installed hardware, this can mean
      of the OS/2 communications device driver in this article.
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.


      References below to "the driver" are referring to the OS/2
For the on line, hooked in generation, the communications device
      communications driver.  In addition, this article ignores DOS and
driver is one of the most important and most overlooked drivers
      WinOS/2 communications under OS/2 which is a related but separate
on their system.  If it ever becomes a reality, the much
      subject.
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.


      The settings, buzz words, and tweaking options of data
Ray Gwinn
      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

Revision as of 05:01, 25 May 2020

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