Question on DLL example

[Daniel Keep]

Ok, let's see what I can help with...

Nox / Lux wrote:
> Hello all,
> 
> I have been trying out the "Win32 DLLs in D" example found at
> http://www.digitalmars.com/d/dll.html (the "D code calling D code in DLLs"
> section), and now I have many questions :)
> I am trying to figure out how a plugin system could be written in D.

To be perfectly honest, DDL is probably better suited for this.  It was
designed specifically for runtime loading of D code, and avoids many
problems that can crop up when using Windows DLLs.

http://dsource.org/projects/ddl

> Heh, the first thing that strikes me about the example is that there are quite
> a few things I don't understand. Like what is "HINSTANCE g_hInst;" and what
> does it mean?

I believe HINSTANCE is a handle to an instance of an application; a
running process.  Without more context, I can't be 100% sure.

It's a Windows API type.  If you don't know what it is, you should
probably go and read up on the Windows API.

> What does
> "extern (C)
> {
> 	void gc_init();
> 	void gc_term();
> 	void _minit();
> 	void _moduleCtor();
> 	void _moduleUnitTests();
> }"
> do and why is it contained within extern (C)? Isn't this D code interfacing
> with D code?

The first two functions are for starting and stopping D's garbage
collector.  The next three are for running module startup code, unit
tests, etc.

These functions are normally not directly used; the "main" function that
starts the program takes care of setting all this up before calling your
"main" function.  However, when you're making a Windows application, the
built-in main isn't used; WinMain is called instead.  As such, you need
to manually kick off the GC, initialize the modules, etc.

The reason they use "extern(C)" is that they are compiled with the C
calling convention, and they're kinda-sorta externs to the current
module.  This is done because these methods are called as part of
bootstrapping the application, and the C calling convention is about the
easiest way of doing this.  It also avoids name mangling problems, which
is where

> What does
> fp = GetProcAddress(h, "D5mydll16MyDLL_InitializeFPvZv");
> do, and why is the second argument a mangled name?

comes in to play.  GetProcAddress is a Windows API call.  Windows
doesn't know ANYTHING about D's name mangling.  It was designed for C
libraries, which don't use name mangling (apart from putting in an
initial "_" before the symbol's name).  As a result, in order to load a
D symbol from a DLL, you need to use the fully mangled name.

Ugly, eh? :P

> Also I noticed that if I copied the code of mydll.d into a second file and
> named it "mydll2.d", test.d would fail to run it after I compiled it to
> "mydll2.dll". It would fail "MyDLL_Initialize()" ("error loading symbol
> MyDLL_Initialize()"). But if the source file is named mydll.d, compiled and
> then simply renamed to mydll2.dll, test.d will load it without problem. Why is
> that? It is not very versatile of a program only to accept a plugin compiled
> under a certain name - I would like a more general solution. Is that possible,
> possible but complicated or impossible?

This is because a module's filename is the same as the module's name.
If we de-mangle the above name, the symbol's full name is:

  mydll.MyDLL_Initialize

When you rename the source file to mydll2, what happens is that the
symbol's full name becomes:

  mydll2.MyDLL_Initialize

You're basically changing what module the function is in, which is why
the application can't load the symbol; it exists under a different name!

You can avoid this by requiring that a plugin's initialize function is
named after the .DLL file itself.  So a plugin stored in "myplugin.dll"
would have an initializer function called "myplugin.Initialize".

> I realize by now that it probably would be good idea to read up on how DLLs
> work in general. Does anyone have any tips on where (websites, books) I could
> find an introduction to this?

Not especially.  Your best bet is just to google for information on the
subject, or maybe try MSDN.

> Many thanks!

Like I said above, if you want to write a D program that uses plugins,
you *need* to take a look at DDL.  It's absolutely brilliant.

Hope this helps,

	-- Daniel

-- 
Unlike Knuth, I have neither proven or tried the above; it may not even
make sense.

v2sw5+8Yhw5ln4+5pr6OFPma8u6+7Lw4Tm6+7l6+7D
i28a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP  http://hackerkey.com/