Understanding ASCOM Alpaca and Classic ASCOM

PLEASE NOTE: Running "as Administrator" on Windows has caused many people problems, particularly with newcomers. Please take a few moments to read the info below.

The graphic below shows how our group, ASCOM itself, and both ASCOM Alpaca and Classic ASCOM COM relate. To see how this has been possible, and how it started, see About Alpaca and ASCOM.

If you want more info on why ASCOM was created and how ASCOM (Alpaca and COM) works, see the About Alpaca and ASCOM section. It tells the story in pictures. Otherwise proceed to the section that addresses the reason you came here, in the orange menu on the left.

ASCOM has undergone a rapid transformation from Windows-only to a universal technology. Classic ASCOM has been a fundamental cornerstone of astronomy innovation on the Windows platform. Now we have ASCOM Alpaca, a new way to accomplish the same things but via network connectivity and on any platform, even embedded controllers. Both Alpaca and Classic ASCOM seamlessly operate in the background of many of the products you are currently using. Both provide the same universal language so that any astronomy app/program can connect to any astronomy device which complies with the ASCOM standards. ASCOM has become essential through simplification and standardization. Without ASCOM we would not have seen the explosive growth and innovation we have experienced in the field over the last 20 years.

Running "as Administrator" on Windows

Running a program "as Administrator" on Windows causes it to run in a separate process space within which the normal protections are blocked. It is like running a program with sudo on Linux, only worse. Windows has rich inter-program communication (which ASCOM COM uses), and Windows prevents programs that are not running "as Administrator" from communicating with elevated/privileged programs that are.

For example, say an app needs to talk to a mount whose ASCOM driver is also an executable program (most are nowadays). If that app is running "as Administrator" it will not be able to talk to the mount unless the mount's control program/driver is also running "as Administrator". But wait ... there's more... Now you want to use another app to talk to the mount. Well, now that the mount controller is running "as Administrator", this new app cannot talk to the mount. Now you have to run the new app "as Administrator" to allow it to talk to the mount because the mount is running "as Administrator" so that it can work with the first app which is running "as Administrator"... Do you see the problem?

What would prompt someone to run a program "as Administrator" in the first place?

Fifteen years ago, when Windows Vista came out, and Microsoft introduced an enhanced set of security restrictions for Windows, existing programs often failed due to these new restrictions. This led to a wave of "solutions" where running these programs "as Administrator" bypassed the new security rules, restoring the programs' operation. "Try running it 'as Administrator', that might work."

Conclusion

While this was a useful workaround in the past, today's software should never require being run "as Administrator". To prevent inscrutable techical support issues caused by this, programs are increasingly detecting being run "as Administrator" and prohibiting it.