5 Device Driver Software

First of all, what is a device driver and why are people interested in them?

Basically a device driver is a separate program that can communicate with any
application that supports the appropriate programming interface.

The most common device driver is probably a printer driver. Each operating
system provides a set of application services related to printing (such as list
available printers, open a printer connection, send data etc). That is the
application side of printing and has no relationship to the print drivers
themselves. The OS also defines a standard way for the print driver programs to
register themselves and receive the data that an application wants to print.

At startup all the available printer drivers make themselves known to the
operating system (well, actually its really the other way around, but thats not
important here). The OS therefore compiles a list of available printers
(it assumes that each print driver has a physical printer attached). When a
user selects 'print setup...' from the menu the list of printer is made
available for the user to select which printer to use, and what settings to
give it. The application knows nothing about the individual printers - the
different printer configuration GUIs are displayed by the printer drivers
themselves when the application asks the OS to handle the 'printer setup...'
function.

As the interface between a printer driver and the OS (and hence the
application) is well defined for any given operating system, anyone could write
their own print driver if they felt so inclined.

For model railway interfacing there is of course no operating system defined
standard, and the link would be directly between application and device driver.
Such an interface is called an 'API' (Application Programming Interface) and
defines a set of subroutines that the device driver must support, and the
mechanism by which it connects to the application.

One mechanism is the 'MRAPI' (Model Railway API) that Graham Plowman uses in
his SSI software. Whether this proves to be a generic API suitable for use
between various applications and railway hardware remains to be seen as SSI is
the only software implementing MRAPI. The mechanism Graham uses to link the
device driver to the application is the Windows DLL system. This of course ties
MRAPI to only the windows environment.

Most model railway software (commercial and private) doesn't use dynamically
linked device drivers at all, but proprietary software built into the
application. This makes the software a little easier to develop, but it means
that the software cannot be extended by other people (by adding for example
support for RPC hardware).

There are many mechanisms that can be used to link device drivers and
applications, among them are:

	1. Statically linked (code built-in at compile/link time)

	2. Dynamically linked (Windows DLL, Unix shared libraries)

	3. Java Beans (similar to dynamic linking, but more flexible)

	4. Networked socket connections

The network socket connection mechanism warrants special consideration. The
other three methods all assume that the hardware is connected to the one
machine that the application is running on. If, however the various parts of
the application all communicate with network (ie. ethernet) sockets then your
application is much more adaptible. 

The various 'parts' I refer to would be:

	1. Serial ports, USB etc, and associated device driver.

	2. Application core

	3. Each individual window that makes up the GUI

With such an arrangement you could use the screens of several computers
(probably to display mimic panels for each operator), and even split the
interface hardware between the different machines. Although this sounds really
advanced, it can actually be quite simple to program.

Performance needn't suffer, in fact it could easily improve as serial port
devices, and GUIs are both significant CPU consumers.

With more advanced application cores the processing couls also be distributed
among the various systems, further increasing performance, and reducing the
problems should one computer break down - you simply move its interface cable
to a spare port on another machine, and move that portion of processing also.
Such distributed arilway control applications are some way in the future
though, so don't hold your breath.

The significant message of this section is: if an application supports external
(non statically-linked) device drivers, and the interface is published then it
is possible for you to adapt that application for your own hardware if you can
write a device driver that conforms to the published specification.

If you want to use an application that doesn't support external device drivers
with a published interface and you want to use hardware they don't currently
support then you only have three choices:

	1. Be happy with the hardware they already support.

	2. Build yourself an adaptor from the interface standard they do
	support, to the one you want. This can be difficult if the interface
	they support isn't documented either.

	3. Write yourself an application that does all the functions you
	require, possible mimicing your chosen commercial software, but
	supporting the hardware you want to use.

	The fourth option (hastle the software authors to add your hardware
	choice) isn't really a viable option - hence the list of only three
	options.

I followed this route at first by making an adaptor from the CTI serial
interface loop to an RPC stack. Unfortunately adding this adaptor had a
noticable performance degradation, but at least it allowed by to use hardware
that I could afford.  The only way I could break free from using such
an adaptor was to write my own software that duplicated all the functions I
wanted of the software I had chosen.