Compiler as dll

[grauzone]

John Reimer wrote:
> ddl does not work for memory sharing like normal dll's, where multiple 
> applications have access to a single dll at runtime.  It appears that 
> such support would be quite difficult to implement and moves in the 
> direction of operating system features.

Couldn't this be achieved by simply mmap()-ing the file contents into 
memory? mmap() normally shared the memory pages with other processes.

Of course, this wouldn't work if the code both isn't position 
independent, and needs to be relocated to a different base address. But 
that's also the case with operating system supported dynamic shared objects.

> It does do runtime linking, however, which is extremely useful for 
> certain situations... specifically any sort of application that needs a 
> plugin architecture for D (ie.. it can link with libraries and object 
> files at runtime) that is gc and exception friendly.  

I never understood why this is needed. Can't they simply compile the 
plugins into the main program?

When it's a commercial program, the DLL plugin approach probably 
wouldn't work anyway: in order to enable others to compile plugins, you 
would need to expose your internal "headers" (D modules). Note that 
unlike in languages like C/C++, this would cause internal modules to be 
exposed too, even if they are not strictly needed. What would you do to 
avoid this? Maintain a separate set of import modules?

I think a purely extern(C) based interface would be better in these cases.

In fact, if you rely on the D ABI for dynamic linking, you'll probably 
have the same trouble as with C++ dynamic linking. For example, BeOS had 
to go through this to make sure their C++ based API maintains ABI 
compatibility:

http://homepage.corbina.net/~maloff/holy-wars/fbc.html

I'm not sure if the D ABI improves the situation. At any rate, it 
doesn't sound like a good idea.