Ok this might get slightly long-winded but I think some initial explanation is required before I move onto my question.

My game engine is designed in a modularised format containing a few of the following DLLs:

Core.dll - foundation classes totally independent of any idea of a "game" (and event system def)
Engine.dll - math, engine foundation classes
Network.dll - TCP/IP and UDP, etc.
GUI.dll - User-interface defintion

My event system is based somewhat off that contained in the book with my own enhancements mixed in to meet the needs of my engine (threading being a huge part of it). My design was flowing smoothly until I came to defining events and data contained in those events. My hope was to define the events/data for each sub-system in their respective project (so network events in Network.dll, GUI events in GUI.dll, etc.) and have the remaining systems capture them. Unfortunately being contained in DLLs (.SO on Linux) the compiler requires the .LIB file for each project that wishes to capture these events and process them correctly. My problem with this being I DO NOT want the GUI having access to socket objects contained in Network.dll just to use the events defined in the system. The only DLL in the system which is statically linked to all others defined is Core.dll as there are a number of classes in here (CThread, CMutex, etc.) which all modules (may) require to function correctly and I would like to keep it this way.

I'm looking for some input from an end-user perspective how it woud be best to handle this issue and I've come up with the following possible solutions:

Option 1
------------
Move the event system outside of Core.dll into an Event module (Event.dll). This DLL would provide base definitions for the event system and would be where the end-user would extend these classes to define new events and data. This DLL would then be linked to every module in the system requiring use of the event system and therefore would have access to every event in the system.

Option 2
------------
Each "module" would define its own static library project named ModuleNameEvents.lib. This lib would contain all event and event data definitions for each subsystem and would be linked only to those DLLs requiring those exact events. This would also be where end-users could add in their own events to the system.

Option 3
------------
The event system definitions remain in Core.dll and this is where all events and event data are defined. Since this DLL is already statically linked throughout the system no changes would be made to the architecture but this pretty much nunkes my idea of no interface changes EVER being made to the core since this should not be required.

Of the above 3 options I'm leaning more towards 2 followed by 1...option 3 doesn't seem logical to me especially due to the definition of what my "Core" should contain. If anyone else has any ideas of how to better handle this than any of the 3 options above please feel free to put forth your suggestion...I'm looking for both ideas and feedback on which would be easiest to support from an end-user perspective.

Hopefully I've included enough here to explain what is going on...if not let me know and i'll update it as necessary (as long as I'm not posting my entire engine design doc :P).

Thanks,

Permafried-

As my design stands right now if the GUI were to load the network module the public interface allowing for sending/receiving of data as well as creating/destroying sockets is exported which would mean there would be nothing stopping an end-user from randomly creating a socket in the GUI (which I can't see why they would ever need to do that :)). Also, I'm considering exporting classes allowing an end-user to manipulate the socket object directly should they ever need to rather than having to do so through the main interface.

As far as the public interface this could perhaps be replaced to a certain extent by the event system but it won't totally go away.

EDIT::
Maybe a better example of why each module shouldn't necessarily be accessed by others in the system is my Direct3D.dll and OpenGLdll. These two implement the IRenderDevice interface and only the RenderController should ever load them for the simple fact that only the RenderController has direct access to geometry fed through the engine. While this might not be the best example when discussing the event system (since they don't handle any events whatsoever and are isolated 100% from the core) I thought it might provide a better example of modules which should not be loaded by more than one in the system.

That's a very good point and I guess there really isn't much I can do to stop someone from creating a raw socket or a D3D device without using my implementation short of assuming they won't do it (though that would pretty much torch multi-platform compilation :)).

You're also correct in that this does point to potential design issues with my system and I've actually started re-designing some things to address these keeping in mind, as you said, that any module in the system should be able to consume a DLL since you're never 100% sure how an end-user might wish to use the system.

Thanks again!

To a certain extent I can't see anyone not using a number of my foundation classes for threads, mutexes and events/conditions at least as base classes which they can extend but no doubt someone will find a better way of doing things in my system than I have which I could maybe learn from and pull it in for a future release.