Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Suggestion] Add a Version() function to the framework #4

Open
exodustx0 opened this issue Jun 23, 2022 · 1 comment
Open

[Suggestion] Add a Version() function to the framework #4

exodustx0 opened this issue Jun 23, 2022 · 1 comment

Comments

@exodustx0
Copy link

exodustx0 commented Jun 23, 2022

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.

@maelh
Copy link
Owner

maelh commented Jul 19, 2022

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants