Communication via InputOutput Ports

Communicating via the Custom Driver

Although Windows also allows for the controlling of devices from the application level, most developers prefer to carry out such control using a custom driver capable of interacting with the drive both directly and via its driver. The latter method is preferable, since it allows for abstracting from specific equipment and ensures a unified interface for all drives . Most drivers of this type connect to ATAPI and/or SCSI ports and interact with the disk in a way similar to the ASPI driver that you have considered before.

Communication with applications is usually carried out by means of special IOCTL codes passed to the driver by the DeviceIoControl function. These IOCTL codes are labelled special , since the development of the protocol for organizing interaction between the driver and device is entirely on the conscience (and in the fantasies) of the developer of that specific driver. There is no such thing as standardization here! Furthermore, the DeviceIoControl function is not the only possible variant. Executing in ring 0 formally provides the right to access all resources of the operating system. If desired, even the most unimaginable perversions are possible. For example, it is possible to communicate with the application via the common memory area. In this case, breakpoints set on DeviceIoControl won t produce any result. However, the overwhelming majority of drivers operate via IOCTL and are not distinguished by original ideas. In some way, this position is justified. Actually, the more non-standard features are implemented in the driver, the higher is the probability of conflicts, and the lower its compatibility with other programs (including operating systems). Moreover, a sophisticated driver is much more difficult to debug and bring to perfection than a simple one. On the other hand, however, an unsophisticated driver is very easy to crack, and, therefore, the efforts spent on its development are not justified. In this case, it is much more reasonable to use ASPI, which ensures fully functional low-level interface, which is also system-independent. When using this approach, you won t have to create implementations of your driver intended for all existing operating systems and end up involved in feverish activity related to rewriting the code with the release of each new Windows version.