6. COM Connectivity

Let's start with the classic ASCOM, which we call ASCOM COM, and see how client apps communicate with the adapter/driver modules. COM is a clever interfacing technology provided by the Windows OS(*). From the standpoint of an app/client developer the ASCOM standard functions (methods) and variables (properties) of the device appear in the app's native language, and this includes over 20 languages! For adapter/driver developers, the available languages are fewer but still include VB6, C#, VB.Net, and for the hard core ATL/C++. The point is that a driver may be written in one language and serve its interface to any of 20 languages being used by apps/clients.

Two Types of COM Drivers

The In Process driver is the simplest type of COM driver. It is a DLL that loads into the app. In this case only that app may use the driver (and the device). The DLL has a special low-level structure that exposes the driver's interface via the Windows COM rules. The driver's bit-ness (32- or 64) must match that of the app. These types of drivers support a single type of device, and are often used with simple devices like focusers and rotators.

The Local Server driver is the most flexible type of COM driver. It is a separate executable. The app and driver communicate through the Windows OS using a service called Local Procedure Calls (LPC), along with special structures to preserve that language independence and manage the two programs (the app and the driver, which in this case is also a program). When the app makes a request (read/write a variable or call a function), the app is put to sleep awaiting the response from the driver program. When a request comes into the driver program it processes the request, and for reading variables/properties, returns a value. The local server can (and usually does) perform other functions for the device, with incoming app requests being only one of its tasks. An example is a mount control program which is doing servo loops, pointing corrections, PEC, etc., along with handling incoming ASCOM app requests. Also, a single local server executable may serve drivers for more than one type of device, such as a Telescope and Focuser.

COM has provided the communication between apps and devices for years, but now ASCOM's universal interfaces (patterns) are also implemented using network protocols as the communication medium. For information on this, continue on to 7. Alpaca Connectivity.


(*) Rumors continue to persist that COM is going away. That's not going to happen. To be convinced, just open the Registry Editor to HKEY_LOCAL_MACHINE and count the COM objects upon which Windows itself depends, many of which are intrinsically part of the Windows OS itself. Most WIndows services are accessible through COM.