I am trying to understand InternalCalls. The book says: “InternalCall means that the method is a stub for an unmanaged code implementation, which is provided at runtime by a hard-coded lookup map contained in the CLR.” So, if I understand it correctly, I can call a method marked as InternalCall myself in any part of my code. Is that correct?
I have tried calling:
Private m_baseAddress, m_size As UInteger
Sub Test()
NativeGetRlpInfo(m_baseAddress, m_size)
End Sub
<MethodImpl(MethodImplOptions.InternalCall)>
Private Sub NativeGetRlpInfo(ByRef address As UInteger, ByRef size As UInteger)
End Sub
But that gave me CLR_E_NOT_SUPPORTED exception. Same happens with [em]NativeLoadElf[/em] and others. Why?
@ iamin - Yes, you can call methods marked as internal call from your program so long as the method is implemented on the native side in the firmware you are using.
You cannot just define the function like you did though. It does not know how to map from your function to ours. The assembly, namespace, parameters, return value, and name are all part of the signature that NETMF checks before executing a call. You have to use reflection to get a reference to our version of the functions.
What if I extract the source code out of your GHI.Hardware.dll using Reflector, modify your source code and recompile it back to GHI.Hardware.dll? Will it work? I would prefer to avoid using reflection.
Also, why don’t you share the managed source code of your libraries? There are many tools that can decompile these libraries, so source code is already partially open.
@ iamin - I honestly do not know if that would work or not. I do not know exactly how Visual Studio calculates the checksum of a library. The fields of the class also get mapped to the native side. So if you change anything in a class, then it is possible that NETMF will complain about an invalid checksum until you recompile the firmware, which you can’t do for the closed boards. You can always try and see if your changes work though.
What would you get from our library sources being open?
[quote=“John”]You can always try and see if your changes work though.
What would you get from our library sources being open?
[/quote]
I would be willing to try, but Reflector does not do a perfect job at decompiling. You have to go and manually fix many things. Having original source code would make it much more easier.
@ John - At the moment I want to reimplement your [em]RuntimeLoadableProcedures.NativeFunction.Invoke[/em]. If I succeed, I would be interested in doing modifications in other parts of your libraries. That’s why I was asking about making your libraries derivable in other thread.
@ iamin - While you could probably clone one of our assemblies, compile it, and have it work, when you try to change anything at all, it will almost always change the checksum of the assembly. At which point NETMF will refuse to load it since any library that uses native code must be compiled with the firmware and have its checksum embedded in it.
Even if you called our native stubs via reflection, we make use of private fields from both the managed and native side along with some static constructors and native to managed events. As we do not document the interactions between all of that, calling the native stubs will be tricky and liable to break between releases. It’s doable, but not easy. You won’t be able to stop our code in events and such from continuing to function though.
So, sadly, until and if we ever make our libraries derivable, there is no easy or reliable way to do what you want. Which is why I ask what you are trying to accomplish. If there are parts of our libraries that you want to change for ease of use or functionality, perhaps there are areas we can improve for everyone.
Thanks John for an extensive answer.
My current requirements are very specific and won’t be of much interest to general users/developers. When I have something to suggest/request that could be beneficial to everyone, I will let you know
Just one last question (I did not receive an answer in another thread). How hard would it be for you to add “virtual” modifiers and change all “private” to “internal” in your libraries? I understand you want to document everything and make everything else “right”, but that is very time consuming and won’t happen any time soon. On the other hand, doing those two changes should be relatively quick and it won’t brake in any way the current way everything is working.
@ iamin - It would be trivial to do that and only that (though you’d want protected, not internal). We will look into making your use case easier for the next SDK, but there are no promises.
