Note: Do not use lcc-Win32 to create a dll, it will not work. Also dlls can be called through rundll32, this doesn't support passing parameters though (if at all), so create functions that don't have any parameters if you are going to call using this method instead of through an app.
What are you talking about?

Elysia's solution is what most everyone uses and is nice and elegant b/c you don't have to change code to export/import. I just created over 20 DLLs in my project using this method and it works just fine.

Linking with DLL export libraries is the easiest way to export classes and objects from DLLs. It requires no source code changes for the modules using the DLL. If you have a module with a bunch of C functions I would recommend compiling those as good old static libraries.

The only thing you cannot do easily in MSVS is export STL container instances across DLL boundaries and/or any template instances. Since you would be unwise to allow access to your underlying containers in the first place this should not be an issue. I also cannot fathom why you would ever allow access to a template instance so you should be ok there too. Note that this only applies to instances not the objects in the container. You can provide public methods to get the objects in an STL container that are within a class that is inside of a DLL. You can also export the instance of the container albeit with some very ugly code and export statements. I would recommend against it.

It's also not a good idea to allocate memory in a DLL and de-allocate it in another DLL. Microsoft claims if you use virtual destructors you should be ok but you will still get the scalar deleting destructor warning. Essentially MSVS is saying you have a new/delete mismatch. For more information you should look up the error message on MSDN.