These are the words ASCOM have to say on driver compliance.

In order to be called "ASCOM compliant", a driver, component, or application scripting interface must meet all of the applicable guidelines in this document. Only then may a driver, interface, or a component's packaging and user interface, carry the ASCOM logo.

1. The driver must install and run on on Microsoft Windows 10, 8.1, 7, Vista, and XP with the latest service packs at the time of driver release, and with User Account Control enabled at its default/normal setting. It should work on both 32- and 64-bit systems. Support for Windows 2000 is no longer provided.

2. The driver author must implement the published standard for the device type as a late-bound COM interface. The published standards are specific about the data types that are used for properties and method parameters. These data types (and COM itself) are what make drivers cross language compatible. Note that by using a .NET language and the .NET driver templates we provide with the Platform Developer Components, this is all taken care-of for you. Also see item 6 below.

3.The driver must never "extend" the standard interface (add private members - properties and/or methods). If private members are desired, they must be exposed through a separate non-standard interface. Starting with Platform 6, driver authors can also extend their drivers through the new Action and SupportedActions members that are now common to all device interface standards.

4. The driver must never display a modal window which requires user interaction to dismiss. All errors must be raised/thrown back to the client.

5. The driver must use the Profile's Register() method for ASCOM registration. It is recommended that drivers also use the Profile object for storage of their persistent configuration, state data, etc., as well as the Serial object serial port I/O. for The components are part of the ASCOM Platform and serve to isolate drivers from changes in Platform architecture. They also make develpment easier by providing high level functionality commonly needed by drivers.

6. Prior to release, the driver must pass the Conform tests using the current/latest version of the Conformance Checker test tool.

7. The driver must be delivered as a self-contained installer. It is unacceptable to ask users to copy files, edit the registry, run BAT files, etc.

The items coloured in green EQMOD has no issues with. The Items in yellow are subject to interpretation, or are poorly specified.

Notes:

Item 3: It may be that this requirement is just poorly phrased. For EQMOD the standard interface that ASCOM sits upon is COM and EQMOD does provide a few additional COM interfaces for applications to use if they wish. This is entirely normal part of windows application design and is not something ASCOM has any right to attempt to restrict.

Item 4: EQMOD sometimes puts up some modal dialogs that require user interaction to dismiss but then that is fine because EQMOD is not just a driver but it is a mount control application in its own right.

Item 5. EQMOD uses the Register method as required but opts to retain control its own parameter management and serial comms.

Item 6: The interpretation of standards and compulsory guidelines is under continual review as is the conformance testing tool. This means that a driver that met all the necessary criteria when it was released (and is therefore compliant) may conceivably fail later releases of conformance tool. The conformance checker itself has had issues in the past and has many internal options that can freely be enabled or disabled which seems rather odd given its role in granting compliance. The EQMOD ASCOM driver does try to implement the ASCOM interface the way ASCOM intend but there are situations where ASCOM itself becomes a sticking point in getting drivers and applications to work. EQMOD therefore also provides several optional “workarounds” that put it in a non-compliant mode. EQMOD is not alone in this – indeed ASCOM's own simulator products provide options that will cause conform failures such as “disconnect on park”

Strict Compliance Mode:

The EQMOD ASCOM Driver V1.29a introduced a new “strict ASCOM compliance” mode that forces EQMOD top operate in a manner that pasess the ASCOM Conformance Cheeck tool (V6.2.58.0). When in this mode:

1. Exceptions are always raised and cannot be disabled

2. Side of Pier algorithm is always set to “Pointing” and there is no option to change this

3. MoveAxis methods are not supported.

If strict compliance isn't applied but side of pier algorithm is set to pointing and exceptions are set to be raised then the driver will fail he conform test with two issues relating to the way moveaxis is implemented – all other aspects of the driver pass their respective tests. The problem with moveaxis has never to our knowledge caused a real life practical issue. The MoveAxis command is essential should you wish to do satellite tracking via EQMODLX.

Unless your setup requires the moveaxis method, or requires exception's to be suppressed, the advice would be to place the EQMOD ASCOM driver into strict compliance mode.

So is EQMOD ASCOM Compliant? – yes pretty much but on any given day you can probably argue the toss either way. 

Does it play well with other ASCOM applications? – absolutely.