Best way to create DLLs?

[TecHNooB]

Assuming C++..

I'm trying to figure out what the ideal path is for splitting up code into DLLs. It seems like .net or COM are the way to go. However, COM seems to limit your inputs and outputs to windows specific types. However, I feel like I always want to pass my own user-defined types to a DLL. Is there a common practice ppl use to completely avoid passing user-defined types?

A route people used in the past is to create pure virtual interfaces and hand that off to whoever wanted to use the DLL. The DLL only has a few functions like GetHandle, GetVersion, ReleaseHandle which basically gives creates an instance of the object you want and returns a void pointer to it. You cast that pointer yourself into the object with the pure virtual class defined in the header file. However, the DLL has to implement a whole bunch of things which COM conveniently takes care of. I find it hard to believe that COM is popular though because it is kind of complicated. What is the most common route for splitting up code into DLLs?

Currently looking into doom3 source code to see if I can find any hints..

 

[brandonb]

It really depends on the use of the DLL. If you want to create an open DLL in which anybody can call and use its functionality, COM or better yet ATL is the best direction to go.

http://en.wikipedia.org/wiki/Active_Template_Library

Now the reason why someone might want to go with COM or ATL is because if the interface changes, you don't necessarily want to remove the existing interface because that would break compatibility with apps which used the previous interface. The QueryInterface function in COM is for that purpose. You tell it which interface you are working with, and it returns you the object/class to use. If you have an upgrade/changed interface, you would change the interface name, and now newer apps can write to that interface. The idea behind COM really is add, but never delete or modify an existing interface.

If you just want to organize your own code, then the use of a .dll or .lib file would work fine:

http://msdn.microsoft.com/en-us/library/3x2ta076.aspx

That way if your interface changes, who cares, because you will be recompiling/changing your code that links to this .dll anyhow.

 

[sao123]

you could simply use the C++ dllexport and dllimport.
as long as you package your dll with a proper header stub, its a relatively simple task.


These are the instructions I gave my students for doing this under Visual Studio 6. Of course this was almost 12 years ago...
BUT the concept is basically the same - #include it, reference it, and call it.

 Instructions for a simple DLL project.
  
 1)Create a new project – Win32 Dynamic Link Library.  Call it mydll.  Create an empty Dll Project.
  
 2)Create a new C++ source file, called mydll.cpp!
                 #include everything you will need – fstream.h, math.h, …
                 
                 The next line in your code should be…(no semicolon at the end)
                 #define DllExport __declspec (dllexport)
                 
                 Your functions should be done like this…
                 DllExport void function_name(int parameters)
                 { …Function body…}
                 The prototypes are in the .h file (you will make it later).
  
 3)Save it and compile it.  You now have 2 files mydll.dll and mydll.lib!
  
 4)Create a new workspace just like you normally would.  
 (Win32 Console Application)
  
 5)Now begin with creating mydll.h!
                 The first line in mdll.h should be…
                 #define DllImport __declspec (dllimport)
                 
                 Now create function prototypes.      
                 DllImport void function_name(int parameters);
  
 6)Next make main.cpp.  Then put the mydll.lib and mydll.dll files in the same folder as mydll.h and main.cpp.
  
 7)Finally to compile you must change one setting.
 <Project> <Settings> <Link TAB>
 In the “Object/Library Modules:” line add mydll.lib at the end.
  
 8)Compile.  You now have a working .exe and .dll – they must be in the same folder to work.

This is older code from pre STDLIB days, but the concept is the same:

 //********************************
 //(cpp file) code to make the dll itself 
  
 #include <fstream.h>
 #include <iostream.h>
 #define DllExport __declspec (dllexport)
 DllExport void compute_coins(int amt_in)
{
 int rmdr = amt_in;
  int num_qtrs = rmdr/25;
 rmdr = rmdr % 25;
  int num_dms = rmdr/10;
 rmdr = rmdr % 10;
  int num_nckls = rmdr/5;
 rmdr = rmdr % 5;
  int num_pns = rmdr;
 
 cout << amt_in << " cents should be returned as ->\n";
 cout << num_qtrs << " Quarters.\n"; 
 cout << num_dms << " Dimes.\n"; 
 cout << num_nckls << " Nickels.\n"; 
 cout << num_pns << " Pennies.\n"; 
 cout << "end of analysis!\n";
}
  
 //********************************
 //(.h file) stub to package with your dll
  
 #define DllImport __declspec (dllimport)
 DllImport void compute_coins(int amt_in);

  
 //********************************
 //(main) sample file to test the application.

 #include <fstream.h>
#include "mydll.h"
 void main()
{
   compute_coins(86);
}

 

[sm625]

DLLs make most sense as part of a driver. All the functions needed to interact with a piece of hardware should all be stored inside a DLL. Same could be said for any block of code that relates to something specific and "concrete". Like a Word or Excel interface library... all the functions required to programmatically manipulate a spreadsheet or a word document would all be contained within a DLL.

But in practice, they put pretty much anything in a DLL these days, and often there are X different names for X different versions. I think they are overused. The whole idea of DLLs is to reduce bloat by allowing code sharing. But somewhere along the way things just got so bloated that it really doesnt mean anything anymore. I would just do whatever is easiest.

 

[DaveSimmons]

One EXE with static linking of libraries for us. We use third-party DLLs when we have to, but the phrase "DLL Hell" exists for good reason.

What do you hope to gain using DLLs over just linking the code directly into your EXE?

 

[cabri]

One EXE with static linking of libraries for us. We use third-party DLLs when we have to, but the phrase "DLL Hell" exists for good reason.

What do you hope to gain using DLLs over just linking the code directly into your EXE?

Size of EXE is the only reason I ever was told.

Another ?questionable? is with 3rd party vendors, a method within their DLL may become more efficient and/or modified and using a DLL avoids having to rebuild the EXE

 

[DaveSimmons]

Size of EXE is the only reason I ever was told.

Another ?questionable? is with 3rd party vendors, a method within their DLL may become more efficient and/or modified and using a DLL avoids having to rebuild the EXE

The problem with that is the new DLL invalidates all the QA testing you've done. It might improve one thing and break two others. With static linking you know the code you're using won't change.

Installer size mattered much more 10-15 years ago when many people were still on dial-up. It still can matter now for patches, but less so.

When we switched to Amazon's cloudfront for patch deployment, we did get a shock from the 2.x TB of bandwidth charges after an automatic update.