The life and death of CIO

[Akos Somorjai]

Hi everyone,

We're planning to remove the CIO (Compatible IO) part of the InputOutput library. Its primary purpose was to provide a C interface to the InputOutput module, which was kept compatible accross maintenance releases (i.e. even if the InputOuput module was modified, the CIO interface was intact). Its drawback is that only part of the functionality of the InputOutput module was available through that interface. Please tell us if you relied heavily on its services, and also if it would take a huge amount of work to switch to normal IO calls (e.g. instead of CIO::File you would have to use IO::File from now).

Thanks in advance,

Akos

[Karl Ottenstein]

Hi Akos,

From your subject, I thought you were sharing an interesting story about a Chief Information Officer. 😉

Seriously though ... I haven't used CIO, so it's up to the other guys. (Did you want this question in this forum, or in the general API one?)

Best regards,
Karl

[Oleg]

I used both interfaces. But my code does not heavy rely on it,
therefore I do not think, that I shall have the big issue move to IO.

However, in general, compatibility across releases seems very
important. I think, it concerns whole API but not just the IO
module.
If for example some Addon is compiled using 1 API release, then lets
2 release of ArchiCAD released and corresponding API which has some
binary incompatible changes, interface exported from some module DLL,
or even some imlementation as there are exported C++ classes. This
Addon can result a crash at using in the upgraded release of ArchiCAD.
I dont know, may be the mechanism already exists, but I think, that if
changes of interfaces are incompatible, ArchiCAD automatically should
not load Addons compiled with previous incompatible API release ( like
it works at changing of major version. And this API should be available
ASAP for developers to recompile their AddOns. )

Compatibility and versioning are always issues. Use of pure abstract
interfaces is often more preferable than the chosen strategy of
class export from the point of compatibility, but it certainly is not
always convenient.

[Fabrizio Diodati]

I fully agree with Oleg: an ArchiCAD procedure should take care about add-ons loading depending of the AC release (I know this could be reached by the add-ons itself but it should be an AC procedure).

About CIO: we heavily used it!
But we could live without it. What is important, if GS will take the decision to discontinue it, is to get this warning and all the related documentation as soon as possible: fixing for these reason 12 add-ons could be a nightmare.

Friendly
Fabrizio

[Oleg]

Fabrizio wrote:
I fully agree with Oleg: an ArchiCAD procedure should take care about add-ons loading depending of the AC release (I know this could be reached by the add-ons itself but it should be an AC procedure).
Friendly
Fabrizio

Yes, we can prevent loading of an Addon by itself checkung the current
relase. It is acceptable for preventing its loading into some previous
relase, if it will need. However I meant an opposite case.
When we have compiled an Addon based on some release, we can not
predict, that one of the next releases will be incompatible. Though
technically it is possible to forbid loading the Addon for all relases
except version used at compilation, but it is absolutely unacceptable
practically. I may be mistaken, but IMHO this case should be handled
by ArchiCAD.

[Fabrizio Diodati]

Hi Oleg,

yes I understood what you said and this was just what I meant!
We had the same trouble: how can I predict if my add-on will work or not with future releases?

friendly
Fabrizio

[Oleg]

Hi Fabrizio

My English often is not so clear, therefore I use so many words to express the simple idea

[Akos Somorjai]

Thanks to all for the feedback. And so the CIO interface will go away with Nautilus... R.I.P.

On the compatibility issue:
- the current plan is that there will be no R2 releases (as it is now with ArchiCAD 9)
- anyway we do our best to provide binary compatibility between Rx releases
- if the interface of a C++ module changes, there are several cases:
1. your add-on won't load at all, because of DLL versioning (it won't find the appropriate DLL), so the LoadLibrary/GetDiskFragment call would fail
2. if the add-on loads, we can get the API version it was compiled with, and the Add-On Manager can reject the add-on if it's supposed to be incompatible
3. we can inform you well in advance that the interface will change, and provide the API kit that is compatible (getting the appropriate ArchiCAD version before release would still be a problem)

(Of course you cannot prepare for the future, but you can prepare for the change.)

BR,

Akos

[Oleg]

Hi Akos,

There is small question out of the subject.

Does the AddOn Manager used the LoadLibrary function.
Just in this case, can you to consider using the LoadLibraryEx with LOAD_WITH_ALTERED_SEARCH_PATH flag instead.
So custom DLLs used by the AddOn will load from a Addon's folder.

[Akos Somorjai]

Oleg wrote:
Does the AddOn Manager used the LoadLibrary function.
Just in this case, can you to consider using the LoadLibraryEx with LOAD_WITH_ALTERED_SEARCH_PATH flag instead.
So custom DLLs used by the AddOn will load from a Addon's folder.

Yes, currently it is using LoadLibrary on Windows. I'll take a look at that. Currently custom DLLs are either loaded from ArchiCAD's folder, or manually from the add-on itself.

Problem may arise from the fact that the LoadLibrary call is wrapped by the GSUtils module, and as such, called by many other parts of the application.

Thanks,

Akos