Get Dll functions at compile time

[Moritz Maxeiner via Digitalmars-d-learn]

On Wednesday, 9 August 2017 at 02:11:13 UTC, Johnson Jones wrote:
> I like to create code that automates much of the manual labor 
> that we, as programmers, are generally forced to do. D 
> generally makes much of this work automatable. For example, I 
> have created the following code which makes loading dlls 
> similar to libs:
>
> [...]

Yes, this is essentially what people are doing right now, see 
e.g. [1] where all of the dynamic loading components are 
generated from the declarations used for linking.


> But this got me thinking that we don't even need to have to 
> specify the function in D, hell, they already exist in the lib 
> and we are just duplicating work.
>
> What if, at compile time, D could get all the functions and 
> their type information and build a class for them for us? We 
> could then just write something like
>
> struct DLLImports
> {
> 	@("DLLImport") string libgdk = "libgdk-3-0.dll";
> }
>
>
> and have some ctfe meta functions extract all the function from 
> libgdk and insert them in to the struct.
>
> There are two problems with this, one easy and one 
> hard/impossible(which would be easy if people were intelligent 
> enough to have foresight):

There's a third one: This is not what object code is for, you'd 
have to write code for every object code format, because they're 
inherently platform specific.
>
>
> 1. Get the dll function by name from the dll at compile time. 
> This would probably require manually reading the dll file and 
> scanning for the function.

And you'd have to demangle all the symbol names for anything 
that's not C mangled. Such as D. Or C++.

>
> 2. Get the type information to build a declaration. This is 
> probably impossible since dll's do not contain the type 
> information about their parameters and return type(or do 
> they?). If they did, it would be easy. I would suggest that all 
> dll's generated by D include this information somewhere and an 
> easy way to extract it for future programmers so such things 
> could be implemented.

Again, this is not what object code is for:
If you want to bind to anything that was written in D, you're 
going to have the declarations, anyway (either in .d or .di 
files), so you wouldn't need the information in the object code. 
If it's not written in D, it's not going to be in the object 
code, anyway.

>
> Alternatively, maybe a master database could be queried for 
> such information by using the function names and dll name? I 
> don't know if D has network capabilities at compile time though.

D doesn't have arbitrary I/O at compile time.


[1] 
https://github.com/Calrama/llvm-d/blob/master/source/llvm/functions/load.d#L124