SERVICES >Graphic Device Driver Development

Device Driver Development
A word about device drivers -
Device Drivers provide system extensibility by supporting new kinds of devices that are commercialized. For instance it is through the concept of Device Drivers that the Operating Systems can control different types of Display devices like monitors. It is not possible to know all the different kinds of devices when an OS is developed. So a logical interface is constructed which provides an interface to these classes of devices. For example, the OS decides that all display surfaces should support such attributes. This forms the logical device driver. A Physical Device driver satisfying this logical interface is developed by the vendor of the device. This nice separation of specific implementation details from the interface provides the necessary extensibility to the OS. The basic task of a Device Driver is to translate the OS function calls into commands known to the device. Internally also it is partitioned into logical and physical layers where logical layer concentrates on data common to that class of devices while physical layer concentrates on communication to the specific device.

Some of the common kinds of Device Drivers are Printer drivers, Video Adapter drivers, Hard Disk Driver, Network Card driver etc.

Kernel mode versus User mode

All modern protected mode Operating Systems usually separate their functions into 2 broad categories. Kernel mode which is the reserved part of running the kernel while user mode which is used to run user applications. Similarly in the case of Drivers there are 2 types of Device drivers Kernel Mode and User Mode.

Windows drivers can run in either user mode or kernel mode.
User-mode drivers run in the non privileged processor mode in which other application code, including protected subsystem code, executes. User-mode drivers cannot gain access to system data except by calling the Win32 API which, in turn, calls system services.
Kernel-mode drivers run as part of the operating system's executive, the underlying operating system component that supports one or more protected subsystems.
All Device drivers are divided into either one of these categories.
At Essel we gained some experience in both types of driver development

Essel Experience
The first experience
We at Essel embarked on an ambitious project to develop a virtual printer driver which would convert any electronic document into a custom script which could be analyzed by a proprietary application and rendered. This was a time when we had little experience in Device Driver development. Since a printer driver is a User Mode driver we found adequate debugging tools and finally developed the printer driver. More details can be had from the case study (link). It was found that we needed to extend the virtual printer driver for other OS like Windows NT. On Windows NT the printer driver is a Kernel mode driver. So we gained some experience in that as well.
It was an exciting journey to the world of Device Driver development. We gained intense exposure to the world of Printer Architecture. We analyzed the various components of a Printer driver like
a) Graphics Driver
b) Print Processor
c) Common Property Sheet User Interface ( CPSUI)
d) Port Monitor
We have deep understanding of the DDK build environment and in are well versed in using debugging using tools like SoftIce.
Printer Driver is a Graphic Driver which converts the Graphics Device calls into Device Dependent Interface calls. By gaining experience in the domain helped us to learn the internals of how Graphics Drivers work and how to customize different aspects of the process. We hooked into various DDI calls and were able to output script commands corresponding to each DDI call which resulted in the document being represented as a set of custom script commands.
We developed a new feature called Print Forking. This enables to print a document into a multitude of printers on a network with a single Print command.

Tiff Printer and PDF Printer
Another exciting project that we had to develop was the Tiff Printer driver which when printed to, creates a Tiff Image consisting of multiple pages corresponding to the document printed.

Our initial thought was to create a Graphic Driver which was a variant of the Bitmap Printer driver. However this didn’t create the necessary features that the output file should contain.

We embarked on a new pathway to conquer the problem. We studied the standard Post Script printer drivers and converted the post script commands using a post script interpreter (Ghost Script) .

We also customized the Port monitor to specify the output configuration options like the file name etc.