• Advertisement

Archived

This topic is now archived and is closed to further replies.

Plugin architecture?

This topic is 6214 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I''m wondering if anyone here can give me advice on a Delphi plugin architecture. I''m trying to give as much flexibility to the DLL''s as possible, like being able to load TFrames from the module into application TPanels, `hooking'' my network calls, that kind of thing. Anyone have any tips, `gotchas'', or schemes that have worked well in managing a large amount of plugins? I''ve never done anything as modular (on such a large scale) in Delphi before, and I''m looking for a little insight ;] Also, I''d like to inquire on the memory/performance overhead of dynamically loaded DLL''s vs runtime-loaded Packages. I appreciate any responses, thanks. Mike Owens

Share this post


Link to post
Share on other sites
Advertisement
I developed a generic plug-in DLL system last year for one of Charlie Calvert''s game programming contests. To make it very generic, I refrained from using any Delphi-specific types such as objects, strings, var arrays, etc. I stuck with integers, floats and pointers and declared all exported functions as stdcall. This allows anyone to create a DLL in Delphi, C++ Builder or Visual C++ and my Delphi application would be able to use it.

The essence of my system was that each DLL exported one function of a specific name. In my case, this function was called EnumPlugInFuncs. The system would load each DLL in a certain directory and look for this function. If it did not find this function, it unloaded the DLL and continued on to the next. If it found the function, it called the function with one parameter. This parameter was a pointer to an enumeration function in the Delphi application that was called by the DLL once for each plug-in module that the DLL provided. This enumeration function was passed parameters such as plug-in name and the pointer to the plug-in function in the DLL. These plug-in functions were stored in a TStringList for easy management. The loaded DLLs were also stored in a TStringList so I knew which DLLs were currently loaded and what their filename was.

A run-time package is a DLL under a different name, so memory and performance overheads are exactly the same.

Steve ''Sly'' Williams  Code Monkey  Krome Studios

Share this post


Link to post
Share on other sites

  • Advertisement