Is ObjectARX 2022 really compatible with ObjectARX 2021?

[jeff.laing]

So, I ran a quick BeyondCompare across the SDKS for 2022 vs 2021 and turned up differences which I believe should identify that 2022 is in fact NOT binary compatible with 2021.

In AcApDocWindow, we have three new methods:

ACAD_PORT bool isFloating() const;
ACAD_PORT virtual void documentWindowFloated(AcApDocWindow* docWindow);
ACAD_PORT virtual void documentWindowDocked(AcApDocWindow* docWindow);

Fair enough, these are declared last in the class so hopefully that is safe, for the given set of compilers.  These methods aren't located by vtable offset.

However, in AcApDocManager, we have LOST this method:
ACCORE_PORT Acad::ErrorStatus appContextOpenPackage(const ACHAR *pszPackageName);

To my eye, that presumably makes code that compiled against 2021 fail if it is compiled against 2022 and used that method.  Or is that entry point still visible in the compiled binary even though it has been removed from the headers?

Similarly, the signature of AcDbDatabase::deepClone() has changed subtly - its last arg changed from Adesk::boolean to bool.  Ditto wBlockClone() - if these are located by name, then surely their mangled names should now be different?  Are you relying on coincident argument sizes?

[artc2]

isFloating is a non-virtual method, so that is ok to be added in a compatibility release.

The documentWindowFloated and documentWindowDocked methods were added to the AcApDocWindowManagerReactor class. They should not have been added in a compatibility release because they do indeed break API compatibility - but only if some class has derived from AcApDocWindowManagerReactor and added its own new virtual methods.

Adesk::boolean has been a typedef for bool for a number of years now (in adesk.h), so explicitly changing it in a function declaration isn't actually changing the function signature at all.

[jeff.laing]

Given that the use-case of reactors is to overload existing functionality, it seems to me that only the most trivial of usages would not have added their own methods.  If this is an accidental inclusion, that's fine, I can make sure we are careful to build around it (our code-base needs to compile against all versions of ObjectARX back to about 2016).

I note you didn't venture an opinion on AcApDocManager::appContextOpenPackage().

I'm concerned about these mostly because both document and window management are some of the most difficult areas to work and we have a LOT of code that stresses out pretty much anything AutoCAD offers in this space, and if I need to build different versions at every release because of breaking API changes, then I want to know sooner than later.

[artc2 · Accepted solution]

I agree that some reactor derived classes will implement their own new methods, but in my experience, those new methods are usually not virtual, so such methods wouldn't be affected by the newly added virtual methods in this reactor base class.
Having said that, I also realize that it's possible that some application might add it's own virtual methods to a derived class and this change would break that application. That's why I said that the methods should not have been added in an API compatibility release.
We haven't had any reports of such breakage and we had a beta program as well as the final released product. At this point I don't think that we can remove the improperly added methods because that might break some new app that is using them.
As for the AcApDocManager::appContextOpenPackage() method, that method did nothing and returned Acad::eNotImplemented, so it wouldn't be used by any application. But, it should not have been removed until the next time we break API compatibility.

[jeff.laing]

Understood. I can tell you that whenever we implement any reactor, we always overload pretty much every method to at least emit diagnostics so we can tell when they are being fired within our application. If we had done our 2021 port already, then this change would have broken us, and again, no big deal, we know how to cope. What hurts is that we assess "do we need to do a 2022 port or will the 2021 port, which is claimed to be binary compatible" be acceptable based on release notes, etc - then later on, we discover that no, we need a seperate 2022 port because of these sorts of things, and managers complain that a two week estimate turns into a four+ week process.

Neverthless, I think my point is made. 2022 is "probably" compatible, with some provisos on what you did in 2021

[artc2]

Building an app using ObjectARX 2021 that overrides all of the base class's virtual methods (which would of course not include the two methods added in ObjectARX 2022) would not cause any breakage when run in AutoCAD 2022 because all of the the methods being overridden are in the base class, so their places in the vtable won't change between 2021 and 2022. The only way to cause breakage would be to build using ObjectARX 2021 and add your own new virtual methods in the derived class that are not in the base class. Then your derived class's "new" virtual methods would conflict in the vtable with the new base class methods when running in 2022.