Author Topic: Modular Design using Dynamically Linked Libraries  (Read 1984 times)


  • Posts: 10
The night approaches dawn as I write this here in Sweden and I have been sketching, planning and thinking for a project I am about to start. As with all things it needs a name - and as imaginationless I am - I named it 'M' because it just happens to be the initial letter for so many words that best describes the project: Modular, Media player, kind-of Middleware, Marvelous etc etc.. although NOT Malware if you came to think of that ;)

Enough with the joking. I am studying - on my free time - the concept of modular design. I quickly came to think of Forth and thought: "Hell yeah, why not create a completely modular program that could be anything by using a lot of different DLL's?". I quickly sat down with my ancient Bloodshed Dev-C++ (don't ask why I am still using that compiler. I am just accustomed to it and I refuse to break this (bad) habit to use it) and after a few hours I had developed a (crude) module loader and handler. After a little experimenting I came to realize - to my horror - that while I am using DLL's I am also f*cking with threads. Threading is something I have NO experience of.

So to clarify how I have sketched and planned my project for now. I have a core module. This module loads and unloads modules and acts as the executable entry to the program. When a module is loaded, the core will call a function named "MacroLoader" from inside of the loaded module which returns a list of all the functions (here-by called 'macros') the module provides. All these macros are loaded into another list which the core handles. Every macro keeps a reference to the core module and can therefore call other macros from other modules.  Note that my macros might remind you of the words in Forth. A macro (for now) takes a std::map<std::string, std::string>-object and a reference to the core-object as parameters, and returns a std::string-object. The MacroLoader takes no parameters and returns a std::vector<macrofunctionpointer*>-object. All this work(s/ed) until I came to realize that it quickly becomes incomprehensible and way too complex for me when macros of one module utilizes macros of another module. Even more brain-aching is when a module utilizes something that is potentielly risky when used in threads etc, e.g third-party libraries.

I am more or less aware of that I have made a serious mistake when thinking about this. If anyone out there is experienced with threaded programming - please enlighten me of what I should focus on, what dangers and common errors I should beware of, what I should consider and avoid and I'd love references to books, websites and other sources where I can learn more.

As to finish this, the aim with this project is to develop a Media player that consists of many, many small modules that each and every one handles its own task(s). This should result in an easily maintained application that can be modified without the use of the full source code of one single application because the sources are divided among the modules. But I need help with how to implement this concept using DLL's and the concept of macros I wrote about above. If anyone got too much free time on their hands and would like to be part of something like this, don't be afraid of to ask. You don't have to be überskilled at programming to be part of it since some modules are only required very small yet important tasks.

The core is currently written in C++ and the few testing modules I have developed are also written in C++. I love C++.  C++ loves me. We just have an unstable relationship right now. I think she's having an affair with Threads. I hate Threads. :(
« Last Edit: 23 Jun '09 - 02:21 by Archaos90 »