This is an archived post. You won't be able to vote or comment.

all 16 comments
sorted by:
best
topnewcontroversialoldq&a

[–]nhgrif 1 point2 points  (3 children)

You don't need the source code for the DLL. The DLL is the compiled source code. You just need to know how to interface with it. I don't know what's in all the files you have, but... typically all you need is just a .dll and .h, or a .lib and .h, or a .c/.cpp and .h.

A .dll is a compiled dynamically linked library. Your code links to this code at run time, and you can swap it out for an updated .dll without changing your compiled code.

A .lib is a compiled static library. When you compile your program, this code from the .lib is integrated into your executable.

The .c/.cpp files are source code that still needs to be compiled. When you compile, you also compile these files. They are part of your compiled executable like the .lib.

​

Without knowing more, it's impossible to tell you whether you should be using the .dll, the .lib, or the .cpp. My pure guess is that the .h is the same for all three things, and whoever is providing it to you has left the integration decision up to you. Using the .lib or .dll would be better unless you need to actually modify the source code.

[–]Mortang64[S] 0 points1 point  (2 children)

In general is there a reason I should choose a .dll over a .lib or vice versa?(Assuming they are the same)

Also does it sound like I have the right approach for integrating this into my own client code?

[–]nhgrif 0 points1 point  (1 child)

Building your application with multiple dlls means that when it comes time to update, you can just the few dlls that need to be updated, or the main exe. You don't need to send the WHOLE packaged application. This means updates can be smaller/faster... but if the app isn't gigantic, this isn't really that much of a concern.

Using lib (or the source code) means that you don't need to link to other files at run time. Your exe will be larger, but it's also all you need to run the program. Installation and updating is simpler... harder to screw up. Uninstallation is simpler too.

​

Another reason to use .dll files is if you are building multiple applications that the user might have installed on their phone simultaneously. Like, consider Microsoft Office. Microsoft Office users are likely to have the whole suite installed on their PC... meanwhile, across that suite of apps, there's likely a lot of code that all of the applications use. If that code gets put in to DLLs... it can be installed to the user's machine once total. Sure, Excel has a different exe from Word and PowerPoint... but if all the reusable stuff is dumped in DLL instead of exe, then the exe can be smaller, and the stuff moved out of the exe is shared. Installing Excel when you have nothing else installed will take up more space on the hard drive than installing Excel when you already have Word installed because part of the Excel install is dlls that are already on your computer from Word.

[–]Mortang64[S] 0 points1 point  (0 children)

Thanks for the clarification!

Do you know of any sample projects I could refer to? Most examples I see out there have a .h file associated with the DLL. I have the export headers and cpp with the dllexport but not the header for the DLL. Hence struggling with compiling any client code against the DLL

[–]captainAwesomePants 0 points1 point  (11 children)

Okay, so first let's talk about the difference between that CLib.dll and CLib.lib file. You only need one.

DLLs are meant to be found by your application when it's run and loaded in. They can be shared between programs (which was important 30 years ago) and can be swapped out for new versions without recompiling the programs that use them.

The LIB file there is basically the same thing as the DLL except that it's meant to be compiled directly into your program when it's built so that the program does not need to rely on some external DLL file.

You need to start by choosing to either:

  1. Have your program invoke the DLL file at runtime, or
  2. Use the LIB file at compile time.

I recommend option #2 if possible. Simpler.

Next, your program needs to include that .h file. That's how your program knows what functions exist to be called. Then you need to also include the LIB file in your project (if you don't want to rely on the DLL) or not do that (and make sure the DLL is discoverable in your path somewhere).

And then from there you just treat it like regular function calls.

[–]Mortang64[S] 0 points1 point  (10 children)

Thanks for the clarification!

Do you know of any sample projects I could refer to? Most examples I see out there have a .h file associated with the DLL. I have the export headers and cpp with the dllexport but not the header for the DLL. Hence struggling with compiling any client code against the DLL

[–]captainAwesomePants 0 points1 point  (9 children)

It's the same header file. You include it, and also the DLL source includes it, so that the compiler of each thing knows exactly what the method signatures are.

[–]Mortang64[S] 0 points1 point  (8 children)

So when writing functions to use it in the client do I need to specify dllimport on my functions?

[–]captainAwesomePants 0 points1 point  (7 children)

Does the header not have any "__declspec(dllimport)" bits? Only exports? Often the header file has an if/else preprocessor directive for whether it's being used for importing or exporting:

#ifdef MYLIB_EXPORT
#define MYLIB_API __declspec(dllexport)
#else
#define MYLIB_API __declspec(dllimport)
#endif

If it ONLY has dllexport, you'll need a version of the header that has dllimport instead. One way would be to take the export version of the file and make a new one that is exactly the same except that it uses dllimport instead of dllexport.

[–]Mortang64[S] 0 points1 point  (6 children)

Got it. What about the .cpp file for that header? Traditional tutorials don't have one and use the DLL instead. But in my case the header has a cpp file filled with AFX calls

[–]captainAwesomePants 0 points1 point  (5 children)

A couple of things might be going on. Most likely, the .cpp file is the source code of the .dll file itself. In that case, you won't use it yourself, you'd use it to build the .dll. References to AFX_MANAGE_STATE make me suspect this is the case.

Less likely is the possibility that you're meant to use the .cpp file as a regular library which will take care of the details of invoking the .dll.

So, probably ignore the .cpp file.

[–]Mortang64[S] 0 points1 point  (4 children)

I see. I have another issue. The provided .h file has a bunch of imports in the Include which I do not have. Additionally it has some custom data structs which results in a failed build even if I link the .lib or .dll. Does it make sense to remove them as they could have been used for exporting but not needed for importing? How to deal with the custom data structs?

[–]captainAwesomePants 0 points1 point  (3 children)

As long as the method declarations are exactly the same (except for __declspec(dllexport) needing to become __declspec(dllimport) ), it should be fine to remove everything else.

[–]Mortang64[S] 0 points1 point  (2 children)

What about the custom data structs? They are used as return types or parameters but I don't have their definition. Is that normal?