Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Some questions regarding DllExport #45

Closed
bazzilic opened this issue Jul 24, 2017 · 1 comment
Closed

Some questions regarding DllExport #45

bazzilic opened this issue Jul 24, 2017 · 1 comment
Labels

Comments

@bazzilic
Copy link

Hello,

I'd like to clarify a couple of things for myself regarding DllExport that are still obscure to me.

  • Is there any support for platforms other than Windows? I.e., is it possible to export C# library into an .so library for Linux?
  • What exactly happens when we export using DllExport? Does it AOT-compile everything to native code and statically link it together in the DLL or it would require .NET Framework installed on the end-user machine anyway?
@3F 3F added the question label Jul 25, 2017
@3F
Copy link
Owner

3F commented Jul 25, 2017

All this are possible through mscoree.dll that processes the all communications with unmanaged layer through mechanism known as PInvoke, but vice versa:

Generally, the all .NET Modules (I mean .dll or .exe) initially contains injected a common entry point DllMain by default with _CorExeMain / _CorDllMain -> mscoree.dll

That's why we can't use DllMain by default - #5 (but as I said there, we can still inject anything else :))

DllExport prepares records via .export directive for ILAsm compiler (please note, it's specific directive for ILAsm compiler only, i.e. it's not IL instruction for VM at all). Then, ILAsm will just prepare required PE records (see mscorpe part with generator etc.)

yes, as you already noticed, we can be more flexible than current implementation via ILAsm & ILDasm

That is, clr is a core handler of this mechanism, and it all depend on this as you can see. But the using still is simple/or standard as is LoadLibrary/Ex -> GetProcAddress.

Thus, today: no, but yes it's possible.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants