There were also issues with external dependency linking. For example, if a component of the framework made use of a dynamic library, it was necessary to dynamically link that library and possibly signal for success or fail. In this way, it was not possible to static link the dynamic library, otherwise the library link failure would cause the whole application to fail, so it was necessary to dynamic link all dynamic libraries used as external dependencies. This was a major hadicap, particularly as external dependencies grew. Imagine an application that must support a plethora of graphics libraries, such as cairo, skia, opengl, vulkan, directx12, not only it was necessary to dynamic link all the libraries, but also to include all the binary code to manage the library into all the framework components.

For this and other reasons, I refactored the entire framework to have a modular glib-style architecture while maintaining object-oriented c++ programming. The framework already had an architecture based on a set of objects with inheritance derived from a single Object class, so the refactoring was feasible. One of the difficulties I had to solve was to further simplify the core module, to extract a further minimal Common library, which from now on will be the only static library to include for accessing basic framework funcionality, such as dynamic modules handling. All the other modules, including the core library, will be dynamic libraries. The external dependencies of these modules can be linked statically or dynamically without breaking the application.

The objects with the various functionalities will be created by the modules where the implementation lies and the functionalities will be accessible to the other modules through a virtual interface which is very reminiscent of the Microsoft COM (Component Object Model) but with several simplifications. One of the best feature I wanted to implement is the ability to create a class that inherits from a class whose implementation lies on a different module. I have therefore introduced a hierarchy of dependencies between modules included in the framework. For example, the Object class implementation lies in the core module, while a Texture class inheriting from Object may lie in a separate module for generic graphics, and finally a D3DTexture class inheriting from Texture that lies in the Direct3D module. With the same architecture, I was able to easily implement a plugin system. In fact, the objects created by a module can also use a generic virtual interface that doesn't necessarily expose any specialized functionality for the type of implementation. For example, the D3DTexture object may be created by a Direct3D plugin module and managed externally via the generic Texture interface by the application or other modules. Now that the framework refactoring is finished, I can dedicate my self to develop the missing parts and software applications with it.