Is there a way to host the .NET CLR runtime and register MethodImplOptions.InternalCall functions? (This is not a topic about P/Invoke)
A:
IMetaDataImport is your best bet, but can't really vouch for that. This seems like a specific task for C++/CLI.
arul
2009-08-23 06:13:40
Way off the mark, -1
Anton Tykhyy
2009-08-23 06:22:11
What exactly is "way off the mark" here? If there's no way to make InternalCall work using the COM api, P/Invoke is not an option, then C++/CLI is the best(only?) way to go managed->unmanaged.
arul
2009-08-23 06:36:37
InternalCall is below the level of CLI, so C++/CLI. jameszhao's question is very specific about what he wants.
Anton Tykhyy
2009-08-23 07:45:07
+3
A:
SSCLI code (specifically clr\src\vm\ecall.cpp) suggests that there is no way to register InternalCall methods, because the crucial gECClasses table is hardcoded.
Anton Tykhyy
2009-08-23 07:51:10
They sure are, but how?.. I can only suggest firing up your IDA and — public symbols in one hand, SSCLI code in the other — diving into `mscorwks.dll`.
Anton Tykhyy
2009-08-23 08:03:19
I've seen a number of people ask this question on forums - they either want to call something in a C++ DLL and think this might be the way to do it, or else they never say what they want to do. The answer either way is "No". Out of interest, why are you wanting to do this?
Daniel Earwicker
2009-08-23 08:26:25
FWIW, I've debugged into mscorwks.dll at the assembler level to fix issues with the .NET loader and investigate behaviour of `tail. call`, and can confirm in both cases that there was an exact correspondence between SSCLI and the actual machine code. From what I've seen, large chunks of the SSCLI are common with the CLR, and only sensitive things like GC and codegen are significantly different, with other things left out.
Barry Kelly
2009-08-23 10:31:49
@Earwicker. I need to avoid the marshaling cost of P/Invok. In this case C++/CLI is probably the way I'll go. Plus I was wondering if I can create some additional MSIL functionality in the VM.
jameszhao00
2009-08-23 16:51:08
@James: if so, I would separate the performance-critical code which needs to avoid p/invoke into an unmanaged library and write it in C/C++. Or indeed use C++/CLI. This should be much, much easier and much more portable.
Anton Tykhyy
2009-08-24 06:43:16