Jet Systems
Sofia, Bulgaria
phone: +359-2-975-3750
OPOS Development Tools
OPOS Libraries
The purpose of OPOS libraries is to simplify development of OPOS device drivers.
The design of the library is oriented towards porting the drivers relatively easy to other platforms by keeping the device specific functionality as abstract and independent of operating system as possible. COM and Windows specific features are hidden inside the library. The library architecture is as follows:
Here the arrows show the functionality provideÞuse relationship between the modules.
All libraries are implemented in C++, using MFC.
OPOS Base Library
Defines the architecture in terms of concept, interfaces and methods for development of OPOS device drivers. It implements the functionality, as defined by OPOS standard, common to all device classes, like support for:
Provides simplified abstract interfaces for the common features, defined by OPOS. For the needs of the device class specific libraries it gives interface for implementing them. It is used only by the device class specific libraries and not by actual drivers.
Device Class Specific Libraries
Each library provides an abstract interface for a simplified model of the device class functionality. The complicity of all functions concerning the OLE Automation interface, Windows API and any other functionality, common to all devices of the same class is hidden in the device class specific library. Therefore to implement an OPOS driver the developer needs to inherit a C++ class, defined in the library and to overload a few virtual functions.
Follows a scheme of interface between two classes:
Here the arrows show the event/control flow direction between the classes.
Each class can deliver messages (control) to the other or can poll the common data members. The interface, between the two, is defined by the base class. All methods and data members, participating in that interface, should be declared with protected scope.
Follows a class hierarchy design diagram.
Here the arrows show the inheritance baseÞderived relationship between the classes.
There are two groups of classes. First is device class specific group, which is implemented once for each device class. The other is the driver specific group, which is implemented for each device driver.
Abstract interfaces
These are the classes that just define the interface between the library and the device driver. They contain data members and methods to be called in the two directions--in and out. Also the methods to be redefined by the driver are supplied with bodies, that define default behavior of the driver. This default behavior is designed so that the driver is not required to redefine all methods, but only those, which it really needs. The abstract interfaces are modular. They are divided into common to all device classes and specific for each device class. They are designed to ease the device driver developer as much as possible.
Implementation
The implementation is the set of classes that implement the device independent part of the abstract interface.
MFC
This stands for Microsoft Foundation Classes library.
Port Libraries
OPOS Base library defines a mechanism for device port sharing and control. This makes it possible to share a physical port between two or more device drivers, in order to control the devices, attached to it. A port library is implemented, following a strictly defined method in OPOS Base.
Miscellaneous Libraries
Expose various functions, useful for implementation of OPOS device drivers, like hooking systems messages and system sound functionality.
Benefits
The usage of the libraries ensures complete compatibility with the OPOS standard. The testing of new implemented devices is much more simplified. As the device specific code is minimal, it's development, testing and documentation is much less effort.
OCXs
The purpose of the OCXs is to expose the functionality of an OPOS device driver to OLE Automation clients. There is one OCX for each device class. The OCXs are being designed according to OPOS 1.3 standard. They take care mainly of version control of the service objects.
Test Applications
During development and later on installation phase, a standalone test application is useful thing to have. Therefore a set of test applications is provided, one for each device class. It gives the user a possibility to test manually the most important functions of the device.
Driver Templates
To ease the implementation of OPOS device drivers, using the device class specific libraries, template device driver projects are provided. It is required to replace the programmatic and class Ids with another ones and to redefine few methods in order to have a working OPOS device driver.
Device Driver Development
A full service cycle for the development of OPOS device drivers is offered. To develop a device driver we need a device with documentation, present at our site. The customer has to provide his/hers requirements towards the driver, if any. Such requirements are target platform, OS, driver server type. After these things are available, we provide full cycle of development from requirements specification to customer site acceptance.
|
|
Jet Systems |