You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The changes introduced by commits 1fd3ef0/05ccf3e and c3abba5/86afeb6 include breaking changes of existing APIs. This means that, when a new version of HxD is released that incorporates these new additions in the plugin framework, old plugins will have undefined behaviour. Unless there's a way to check the format of arguments that a DLL's function expects,
I suggest adding a Version() function to the framework which would report to HxD what version of the framework a plugin targets. From there, if a loaded plugin reports an unexpected target version, HxD can either adapt to the plugin (if it targets an older version) or reject it, to prevent a plugin from misconfiguring itself, crashing, or producing some other undefined behaviour.
Though I will note, in the event that you won't have HxD adapt to plugins targeting older versions of the API, I'd highly encourage you to instead incorporate changes to existing APIs in new functions, so old plugins will always keep working without any surprises or requiring additional work.
The text was updated successfully, but these errors were encountered:
Right now every plugin is expected to be adapted to each new release, which is why the framework is tagged with version numbers. The changes so far have been minimal, and adding extra code paths to HxD would be counterproductive, since usually ABI changes are meant to improve the code/cleanliness/correctness.
Adding versioning information that is checked automatically makes sense and was mentioned briefly in this pull request: #2 (review)
If this commit is meant to create ABI stability, then I am afraid to say it won't change much, since it may likely break with new releases as I favor strong type safety over unchanging ABIs.
Versioning should be introduced though, to remind people of updating the interfaces, by requiring to pick the right ABI version, which will be checked upon loading the plugin.
Maybe I could use a checksum of the interface, a bit like it happens in ROS, which minimizes and standardizes interface definition code, and checksums it to generate a unique ID.
The ROS approach would be the best, as introducing manually managed version numbers would mean to really keep track of every little change in the function prototypes and be sure to never forget to update version numbers.
After writing a tool that creates a checksum out of a minimized and standardized interface file (the original/base version will always be in Delphi/Pascal), the versioning process would be automated. The translation to other languages would not be automated, however.
I think that's a good enough compromise between reliability and effort.
The changes introduced by commits
1fd3ef0
/05ccf3e
andc3abba5
/86afeb6
include breaking changes of existing APIs. This means that, when a new version of HxD is released that incorporates these new additions in the plugin framework, old plugins will have undefined behaviour. Unless there's a way to check the format of arguments that a DLL's function expects,I suggest adding a
Version()
function to the framework which would report to HxD what version of the framework a plugin targets. From there, if a loaded plugin reports an unexpected target version, HxD can either adapt to the plugin (if it targets an older version) or reject it, to prevent a plugin from misconfiguring itself, crashing, or producing some other undefined behaviour.Though I will note, in the event that you won't have HxD adapt to plugins targeting older versions of the API, I'd highly encourage you to instead incorporate changes to existing APIs in new functions, so old plugins will always keep working without any surprises or requiring additional work.
The text was updated successfully, but these errors were encountered: