Using .lib and .dll in D applications

[docandrew via Digitalmars-d-learn]

On Sunday, 19 June 2016 at 18:33:36 UTC, moe wrote:
> On Sunday, 19 June 2016 at 18:00:07 UTC, Mike Parker wrote:
>> On Sunday, 19 June 2016 at 17:33:43 UTC, moe wrote:
>>
>>
>>
>>
>>
>>
>>
>>> Unfortunatelly I still don't get it. I would like to have an 
>>> independant project "dbar". The created lib is then used in 
>>> another project "dfoo". Assuming that "dfoo" has no access to 
>>> "dbar" other than the .lib file.
>>
>> You can't do it with only the lib file. You *need* the source 
>> file too for the import statement. As I explained, the lib 
>> file is used by the linker, not the compiler. The compiler 
>> needs the source file.
>>
>>>
>>> My folder structure is like this:
>>>
>>> -dtest
>>> --dbar
>>> ----source\barlib.d
>>> ----dub.json
>>> This project creates a dbar.lib file which seams to work.
>>>
>>>
>>> -dtest
>>> --dfoo
>>> ----lib\dbar.d  // copied from the dbar project
>>> ----source\app.d
>>> ----dub.json
>>
>> You don't need to copy dbar to the lib directory in this case.
>>
>>> This project would use the dbar.lib but should otherwise not 
>>> have access to the dbar project. Basically simulating, that 
>>> someone else made a dbar project to which I would not have 
>>> access other than using the dbar.lib. How do I have to 
>>> configure the dub.json file for this to work?
>>
>> One of two things would happen:
>>
>> 1) They would register the project with he dub registry, then 
>> you add a dependency to a specific version the library. Dub 
>> would then download the necessary files for you and ensure 
>> that everything you need is passed to the compiler when 
>> building your project.
>>
>> 2) They would provide some other means for you to get the 
>> source and the library. Then you would need to manually 
>> configure your dub.json to pass the import path to the 
>> compiler and link with the library.
>>
>>>
>>> I have tried a variety of configurations for the dub.json. At 
>>> this point it feels like a bad guessing game. That is no way 
>>> to deveop anything. I need to figure out how to properly 
>>> setup the dub.json but I don't seam to find the answer 
>>> online. "http://code.dlang.org/package-format?lang=json" 
>>> isn't very helpful.
>>
>> All the information you need is there on that page.
>>
>>>
>>> I have meanwhile adjusted my dtest/dfoo/dub.json to this:
>>
>>> 	"dependencies": {
>>> 		"dbar": "~master"
>>> 	}
>>
>>> This gives me the error: "Root package dfoo references 
>>> unknown package dear"
>>
>> As I explained above, you need a path attribute for the 
>> dependency in this case since it is on your local file system 
>> and not in the registry. The documentation link I gave you 
>> explains how to to this. Try this:
>>
>> "dependencies": {
>>     "dbar":  {"path": "../dbar"}
>> }
>
> I see where I went wrong. I thought that it's possible to only 
> use the .lib file without the source code of dbar. Having 
> access to the source makes what I am trying somewhat pointless. 
> Is it otherwise possible to provide some functionality without 
> having to give away your source? I would like to put together a 
> library that I can reuse, without having to rely on the source 
> each time. Maybe a dll instead?
>
> Note: I don't have a problem with giving away my code. I just 
> want to know if it can be done. Or maybe later build a plugin 
> system where the creator of the plugin does not need the source 
> of the entire application. And in turn the app does not need to 
> be recompiled in order to use the plugin.
>
> Thanks for your help!

Sure, you can just have a file with "extern" functions that tells 
the compiler that the source for those functions isn't available 
at compile time, but that later on when you link the library, the 
linker will find those function definitions in the .lib file (I'm 
not a Windows expert, but from my understanding .DLLs are a 
different ball game, and have to be loaded and called with 
special functions in your app.)

In your example, in your "dfoo.d", you can declare the functions 
from the dbar.lib inside as "extern myfunction();" and the 
compiler will say, "OK, myfunction() isn't defined here, so we'll 
let the linker sort it out." If you try and compile without 
telling it about dbar.lib, you'll get errors like "undefined 
reference to myfunction()...".

When you see that somebody wrote a "binding" in D for a library 
like OpenGL, etc., this is what they are providing, a .d file 
filled with "extern" definitions and maybe some glue code to 
convert D types into C types if the .lib file is a C library.

APIs generally work the same way. Library writers will provide a 
.h header file that doesn't expose any of their closed source, 
but gives users of the library the definitions of the functions 
they need to use it's functions.

I hope this helps!

-Jon