In the DLL or not in the DLL?

I've been creating DLLs recently for my graphics engine and I'm kind of confused as to what I should place in it, and what I should not.

So far I have core startup code, sound code, input code, etc, etc. But specialized code that is used for certain games I've been reluctant to add b/c it's not really core engine code. Also the Render(),Setup(), and Cleanup() code is the programmer's responsibility. I have no idea how a coder would want to render their environments so I've declared it and the other 2 functions as pure virtuals.

The programmer can create their own WndProc for both the game and any video's they play inside of the game via DirectShow. My DLL has helper functions that call the class-versions of the WndProc code.

So what should be in a core engine DLL and what should not be?

Also should I split sound, input, and multiplayer code into separate DLLs or is that overkill?

I like this DLL and import library stuff because now I can use an actual engine window as my main view in my MFC editor. I've totally scrapped the GDI sections in favor of using Direct3D. It's so much easier to do Direct3D than GDI and a lot more can be done with less code. No more DC's, blits, etc, etc.
Windows GDI..........um.............u suck.

>>So what should be in a core engine DLL and what should not be?

The answer depends on what you expect to get out of your engine. Chances are that some time in the future, you'll scrap this engine in favour of an entirely new design which addresses architectural issues in your current design that you haven't forseen yet, and can't be easily altered.

Personally, my engine is contained totally in a single DLL. Graphics, Sound, Video, Input, Text Display, Object Handling, Scripting, Basic Math Functions, Physics, Error Handling, Timers, etc. It's all in there. Everything that goes in must be designed with a totally dynamic structure to allow the engine versatility to develop multiple types of applications.

I deal with areas of the engine that will require specific code to be written per application, in a couple of ways. In some cases I can write code to assume a common method but then expose either a function or optional function parameters, to allow the programmer to alter default behavior to a custom one. This gives me basic options quickly and easily but still allows me to customise the areas I may need to. The second method is to require a function pointer to be passed into the section of code from outside the engine, which must complete the desired task in whatever way the programmer requires.

>>Windows GDI..........um.............u suck.

Yes. And once you've set up D3D, its remarkable easy to do most things.