Why are add-ons rebuilt for new releases?

[Ralph Wessel]

oreopoulos wrote:
And then the plugins. That ****** decision ,old plugins not working in newer versions. That is totally unacceptable. This is intentional (because if i believe its not intentional then its a complete programming lack of skills) Plugins should work for every version. Period.

This quote came from another thread, but I thought it was already too chaotic without adding this to it.

From a programmer's point of view, the changing API is unfortunate but unavoidable. The tricky thing about software development is that a principle or method that works in one case may be irrelevant in another. There are environments where new releases don't (necessarily) break existing plugins, but it depends greatly on the relationship between the plugin and host - how much control the plugin has, the extent of its domain, the data exchanged between them, etc.

For an application as large and complex as ArchiCAD, the odds of the underlying data remaining constant from one release to another is practically zero. New tools are added, existing tools have more features, attributes and preferences change, etc, etc. This changes the memory allocation for data structures, the parameters passed in calls, and much more. If an old add-on was allowed to run, it could cause havoc with your project data.

Rapid change is a fact of life in the IT world, for hardware, software, and programming techniques. I count on having to throw away technologies and tools on a regular basis and take up new ones. Please don't hold Graphisoft to account for this. Believe me - if they had a way to avoid this, they would. The changes are hard (and very expensive) for them too (think transition to 64-bit platforms, e.g. Cocoa).

[Anonymous]

As you (if i remember well) said, you create wrappers for you API's.
Good programming can make an API backwards compatible

Even if geometry changes (has anything changed in AC??) you can make it backwards compatible. Its a decision and its not hard.

On the other hand there is NO SINGLE plugin that worked from one version to another. So its not a matter of compatibility but a matter of decision. Even the simplest plugin would require recompilation.

I would accept something to be broken 1 in 5 releases because it was necessary to change, but everything in every release its simply a policy
(and i speak as a programmer myself).

Its obvious that if there was a scripting language (like Ruby for sketchup), things would be REALLY different.

[Ralph Wessel]

oreopoulos wrote:
As you (if i remember well) said, you create wrappers for you API's.
Good programming can make an API backwards compatible

Even if geometry changes (has anything changed in AC??) you can make it backwards compatible. Its a decision and its not hard.

On the other hand there is NO SINGLE plugin that worked from one version to another. So its not a matter of compatibility but a matter of decision. Even the simplest plugin would require recompilation.

I would accept something to be broken 1 in 5 releases because it was necessary to change, but everything in every release its simply a policy
(and i speak as a programmer myself).

Its obvious that if there was a scripting language (like Ruby for sketchup), things would be REALLY different.

I'd prefer to discuss scripting under a different thread. I agree that it would bring significant changes, but it wouldn't replace the API or change the fact that API-based development would have to be recompiled at new releases.

I'll try to divide the rest of my reply into answers to specific questions:

• 1. Has anything changed in AC?
  Yes - a great deal. There's a very easy way to see the extent of these changes. Download the API devkit and read the New Features section (the history of changes in older versions is included). This includes changes to data structures, function calls, attributes, databases, etc.
  
  Consider the unique ID of an element, for example. In the past, this was a 32-bit unsigned integer. This was fine in the past - you could uniquely identify about 4.2 billion elements in a single project. But if an element was merged from an external source, there was no way to know if it was the same element or a new one. For database transactions (like Teamwork 2) a stronger solution was required. So, from ArchiCAD 11, all elements had a guid (a 16-byte data structure) that would always be unique no matter where or when it was created. If an old add-on referring to 32-bit IDs was run in an AC version using 16-byte guids, I'm sure you can appreciate the chaos that would ensue.
  
  2. Do I have a wrapper that provides backward compatibility?
  Yes, and no.
  
  Yes, I have developed a wrapper for the ArchiCAD API which allows me to compile the same add-on code for any version of ArchiCAD. This provides several advantages:
  i) I don't have to plan to target a specific version when I start;
  ii) It's easier and faster to develop add-ons with a uniform platform;
  iii) When changes occur, I implement them in the wrapper (the pain happens in just one place). All the add-on code can be recompiled unchanged.
  
  For example, I have always enclosed the element unique ID in a wrapper object so the add-on code never directly refers to the underlying data structures. Therefore, the change from 32-bit IDs to 16-byte guids caused no changes to my add-on code.
  
  But no, this does not allow add-ons to run across multiple versions of ArchiCAD without recompiling. Recompiling is essential for languages like C++ because the size and relative addressing of data structures is hard-wired into the code. If the addressing is not aligned precisely between add-on and host, it will cause havoc.
  
  3. Has Graphisoft, through policy or poor programming, been responsible for this problem?
  No. Having to recompile when data structures or function calls change is just a fact of life (for compiled languages) for the reasons discussed above. But even if that problem was eliminated, technologies like Teamwork have also introduced new policies and responsibilities because the user's privileges have to be taken into account. And the expansion of ArchiCAD with new tools (polyline tool, curtain-wall tool, etc) and databases (layouts, worksheets, details, elevations, etc) require thought and attention. An old tool might 'see' only a fraction of the project database.

This pain is the cost of moving technology forward, and no one escapes it. Look at the upheavals Apple has been through moving from OS 9 to the NEXTSTeP-based OS X, or from Motorola to PPC to Intel chipsets, or from 32-bit to 64-bit. Or Microsoft's disaster that was Vista, as they attempted to steer the Windows leviathan to the future. There's no easy option.