Developing for 32- and 64-bits

Running on a 64-bit Windows operating system does not mean all applications and ASCOM drivers are 64-bit. Virtually all astronomy applications run under the 32-bit subsystem, and use 32-bit drivers. They are unaware that they are running on a 64-bit system. This is a technical miracle from Microsoft.

The ASCOM architecture supports both 32- and 64-bit environments, however there is a great deal of confusion and old wives' tales surrounding this area. It's beyond the scope of this article to give general information on the 32- and 64-bit subsystems in Windows. What is important to driver writers, though, is that the implementation of COM (see How ASCOM Works) is separate for 32- and 64-bit applications and drivers. In other words, a 32-bit application cannot use a 64-bit driver, and vice versa. Furthermore, a driver must register itself for COM in the subsystem (32- or 64-bit) for which it was developed. At present (January 2014) virtually all astronomy software is 32-bit, and virtually all of the drivers out there are also 32-bit. Thus, if your driver is 32-bit, that will probably be sufficient for now and into the near future.

Developing with .NET: Universal 32- and 64-bit drivers

By following the recommendations of the ASCOM Initiative and using either C# or Visual Basic .NET languages, you will be able to create a universal driver that will run under 32- and 64-bit environment with no extra effort on your part. Simply make sure your driver project targets "Any CPU", and that you create an instance of it at least once from both a 32-bit and a 64-bit application. Note that the ASCOM Driver Installer Tool does not handle 64-bit registration. We hope to fix this in the future.

NOTE: If your .NET driver depends on any external DLL that is 32- or 64-bit only, the driver will not be iuniversal. It will be limited to the environment needed by the dependency DLL(s). See below for a way to manage this.

Using the .NET LocalServer to Produce a Universal Driver

The .NET LocalServer pattern (and template) produces an executable which serves instances of drivers. A single LocalServer can serve multiple instances of multiple drivers. It operates in its own process space, and is thus insulated from the bit-ness of the applications that use the drivers it serves. So you can develop a 32-bit-only driver (for example one which uses 32-bit only libraries etc.) and still be able to serve drivers to 64-bit applications. The LocalServer is more complex to use, but the template and its built-in help file should be sufficient for a skilled .NET developer.