Browse Prior Art Database

Redirection of Virtual COM Ports Under OS/2

IP.com Disclosure Number: IPCOM000123601D
Original Publication Date: 1999-Feb-01
Included in the Prior Art Database: 2005-Apr-05
Document File: 2 page(s) / 108K

Publishing Venue

IBM

Related People

Deuser, MW: AUTHOR [+2]

Abstract

A design methodology is disclosed that provides virtual COM port support through the existing OS/2 virtual and physical COM port device drivers. This implementation obviates the additional development and test efforts associated with writing a driver to replace the existing OS/2 virtual COM driver. Developers that want to intercept COM port data from both OS/2 and WinOS2 applications should find this design useful.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 52% of the total text.

Redirection of Virtual COM Ports Under OS/2

   A design methodology is disclosed that provides virtual
COM port support through the existing OS/2 virtual and physical COM
port device drivers.  This implementation obviates the additional
development and test efforts associated with writing a driver to
replace the existing OS/2 virtual COM driver.  Developers that want
to intercept COM port data from both OS/2 and WinOS2 applications
should find this design useful.

   OS/2 provides a device driver, COM.SYS, which provides an
API that permits native OS/2 applications to access the system's
physical serial ports.  To support the DOS and Windows applications
running under WinOS2, the OS/2 VCOM.SYS driver intercepts the
standard DOS specific COM port API (INT 14H and direct serial
hardware manipulation) and forwards the requests to/from COM.SYS
which owns the physical hardware.  VCOM.SYS and COM.SYS communicate
with one another via a special inter-device driver communications
(IDC) API.

   To redirect a WinOS2 application's COM port data to
another piece of hardware or a LAN protocol stack, driver code must
be written to intercept the WinOS2 INT 14H and/or serial hardware
interfaces.  This interception code is already part of the VCOM.SYS
driver and can be used to aid in the COM port redirection when two
new drivers (MYCOM.SYS and MYVCOM.SYS) are inserted between the
VCOM.SYS/COM.SYS IDC data path.  MYCOM.SYS will mimic the COM.SYS
driver IDC when communicating with the VCOM.SYS driver, while the
MYVCOM.SYS driver will impersonate the VCOM.SYS driver when
communicating with the COM.SYS driver.  MYCOM.SYS and MYVCOM.SYS will
also have an IDC between themselves.

   OS/2 loads all physical drivers into memory in the order
the drivers appear in CONFIG.SYS.  MYCOM.SYS should be loaded after
COM.SYS so that it may "steal" any desired OS/2 COM devices managed
by the physical driver.  COM.SYS uses the RegisterPDD API to register
itself with OS/2 as the "COM" physical device driver, and MYCOM.SYS
registers itself as the "MYCOM" physical driver.

   Next, the virtual drivers are loaded after all physical
drivers have been loaded.  As with the physical device driver, the
virtual drivers are loaded in order of their appearance in
CONFIG.SYS.  MYVCOM.SYS should be loaded prior to VCOM.SYS.

   When MYVCOM.SYS loads, it's initialization routine
registers itself (via VDHOpenPDD) with the CO...