Currently, very few projects on the CE use hooks, and I believe this is likely to avoid causing issues with other programs that use them. I think that it would be a good idea to create a library that would provide an interface for managing hooks, rather than having all programs handle installing hooks themselves.

Right now I have a decent idea of how this would work in my head, but that doesn't really count for anything, so I created a GitHub gist explaining the basic idea. I'm posting this to get feedback, at this point mostly for any glaring issues with the concept. If there aren't any, I can start working on more polished design documentation and then start actually implementing it.

I'm currently not addressing memory management issues, only chaining issues, though that might change in the future.

Anyways, here's the GitHub gist:
I have improved the draft, formatting wise Razz

(Also added a const for the description string)
I think you should try this Smile I would recommend using some unused memory location rather than the D register though. Perhaps a negative flag location. Also I'm not sure I understand the point of subtypes. Are they really needed?

Also keep in mind we should probably have a wiki page with the registered hook IDs.
I've gone ahead and created a prototype, mostly written in C due to laziness, one of the three core virtues of programming. You can go ahead and check out a demo of it here:

As per Mateo's suggestions, I've removed subtypes since they're pointless and outside the scope of this library, and also changed the byte that determines whether more hooks will be run from d to bit 0 of (iy-10), an unused flag.

A few things to keep in mind:
Currently, the library is mostly written in C. I'll rewrite it in assembly for speed for the actual library, and remove the dependency on fileioc.
This is written in C11 because I'm too lazy to do int i; for(i...). It probably won't build on ZDS; use the llvm branch of the toolchain.
Currently, this is statically linked and part of a C project. This will eventually be a LibLoad library like graphx and fileioc.
This code is inefficient, both in terms of size and space. Later, I'll properly sort the database so that it can be accessed quickly, and probably change the getter functions to share most of their code.
Not everything I have planned is implemented yet - I want to make sure that what I currently have doesn't have any serious issues with it before continuing. I have the following planned:
Handling OS hooks that already have a hook from a program or app that does not use this library
Supporting localization hooks/language apps - I haven't looked into this much yet, but I'm pretty sure this would allow me to restore all of the hooks after a garbage collect or RAM reset
Allocating memory in a way that won't get clobbered on a garbage collect - I think Mateo said he had an idea for how to do this using relocation tables, in a similar way to how LibLoad does it. I may also provide this method as a library function, rather than leaving memory allocation to the user

If you have any other feedback, please be sure to let me know.

Don't attempt to use this prototype in actual programs - I will likely change the interface at some point and things will break.
I'm revisiting this project, despite it being a pretty weird time to do so.

I've added a bunch of tests so I can verify that the library behaves properly once I rewrite it in assembly.
In the process, I found a few major bugs in the prototype, which I've now fixed.
I also added documentation to the header file, so you can just read that instead of the rather messy github gist. I don't mention the return flag anywhere as of right now - I guess I could add that to the comment for hook_t.

I'm still looking for feedback on the interface, so take a look at the header file and let me know if you have any.
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
Page 1 of 1
» All times are GMT - 5 Hours
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum