It is possible to implement drivers in the C++ language. For information about writing C++ drivers, see ``Writing drivers in C++''.
Note that, for ODDI drivers that run on SCO OpenServer 5, the space.c files are compiled with an old compiler that does not understand ANSI C syntax, so the space.c files must be coded with Kernighan and Ritchie C.
Drivers should not use Microsoft C extensions such as far and PASCAL.
For information about adhering to this guideline
in C++ drivers, see
``Driver name space issues''.
Note that DDI 8 drivers have less need for externally visible symbols than drivers written for earlier DDI versions and ODDI. If your DDI 8 driver is based on earlier code, look for symbols that no longer need to be global.
For resources that should be visible for debugging but static at other times, DDI drivers can code the declaration as follows:
STATIC int my_variable;The sys/debug.h header file includes code that will make this variable visible for debugging (when -DDEBUG is set) but static at other times.
SCO OpenServer 5 ODDI drivers can implement similar functionality by including code such as the following at the top of the driver source code:
#ifdef DEBUG # define STATIC #else # define STATIC static #endif
SCO OpenServer 5 does not enforce interface conformance as rigorously, but using obsolete or private functions can result in less robust driver code that is harder to port to future platforms.
Writing specialized routines to provide the same functionality as standard kernel functions significantly reduces the possibility that the driver will work in future releases of the operating system. Source code that has private copies of function prototypes for standard functions may also have porting problems; drivers should instead use the function prototypes that are included in the system header files.
One exception to this is that
ODDI drivers may view and modify the
b_error structure members directly.