Unmanaged Hosting of .NET Framework Version 4
-
You should have a good sense of humor to read this question. I'm writing an unmanaged project to host the .NET Framework CLR (version 4), and execute some of it's code. I'm writing the application in assembly language (but, you don't have to understand assmbly language to understand this question), and I don't have Visual Studio installed on my computer. Anyway, I've got all the preliminaries working correctly. I've called Enumerate Installed Runtimes, and called ICLRMetaHost.GetRuntime which causes the CLR (version 4) to be loaded but not initialized,...and then, called, ICLRRuntimeHost.Start method successfully. When viewing the process with ProcessExplorer, I see the clr.dll (version 4) being loaded into the virtual address space. Next, I call ICLRRuntimeInfo:GetInterface to retreive a pointer to the ICorRuntimeHost interface, and use that pointer to call ICorRuntimeHost:GetDefaultDomain. Then, I call IUnknown:QueryInterface to retreive the DefaultDomain (IID_AppDomain) interface pointer. At this point, mscorlib.dll or one of its variants (mscorlib.ni.dll) is loaded by the CLR into the address space. What I need now is to enumerate through some of the basic .NET types and methods, to retrieve addresses. And, what I need to do this, and don't have are definitions for the vtables of the interfaces of, for instance, [_Assembly](https://msdn.microsoft.com/en-us/library/system.runtime.interopservices._assembly
(v=vs.100).aspx) which expose the public members of the System.Reflection.Assembly class to unmanaged code. These are huge COM interfaces, and, to execute their methods correctly, one must know the offset of the method (function pointer) from the address of the interface virtual function table. To actually call these interface methods in assembly you don't even have to prototype the function (although doing so makes your code much more readable and understandable), all you have to is push the appropriate parameters onto the stack, and call the function with the function pointer. So, finally,...my question: where can I find the interface definition files, for mscorlib COM interfaces like: System.Runtime.InteropServices._Assembly, or, System._AppDomain interface, or, especially,I can't confidently answer your question at all... However here is what relevant info I found: 1st apparently to call .NET class from COM (or as COM component in your case) you need the mscorlib.tlb, as explained there How to: Reference .NET Types from COM[^] and a longer one Calling a .NET Component from a COM Component[^] I suspect these article might not help much or are nothing new for you, and you still wonder.. where is this damn mscorlib.tlb? Well.. it's somewhere in the .NET framework folder: Open
C:\Windows\Microsoft.NETAnd search for mscorlib.tlb, there are a few of them!A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
-
You should have a good sense of humor to read this question. I'm writing an unmanaged project to host the .NET Framework CLR (version 4), and execute some of it's code. I'm writing the application in assembly language (but, you don't have to understand assmbly language to understand this question), and I don't have Visual Studio installed on my computer. Anyway, I've got all the preliminaries working correctly. I've called Enumerate Installed Runtimes, and called ICLRMetaHost.GetRuntime which causes the CLR (version 4) to be loaded but not initialized,...and then, called, ICLRRuntimeHost.Start method successfully. When viewing the process with ProcessExplorer, I see the clr.dll (version 4) being loaded into the virtual address space. Next, I call ICLRRuntimeInfo:GetInterface to retreive a pointer to the ICorRuntimeHost interface, and use that pointer to call ICorRuntimeHost:GetDefaultDomain. Then, I call IUnknown:QueryInterface to retreive the DefaultDomain (IID_AppDomain) interface pointer. At this point, mscorlib.dll or one of its variants (mscorlib.ni.dll) is loaded by the CLR into the address space. What I need now is to enumerate through some of the basic .NET types and methods, to retrieve addresses. And, what I need to do this, and don't have are definitions for the vtables of the interfaces of, for instance, [_Assembly](https://msdn.microsoft.com/en-us/library/system.runtime.interopservices._assembly
(v=vs.100).aspx) which expose the public members of the System.Reflection.Assembly class to unmanaged code. These are huge COM interfaces, and, to execute their methods correctly, one must know the offset of the method (function pointer) from the address of the interface virtual function table. To actually call these interface methods in assembly you don't even have to prototype the function (although doing so makes your code much more readable and understandable), all you have to is push the appropriate parameters onto the stack, and call the function with the function pointer. So, finally,...my question: where can I find the interface definition files, for mscorlib COM interfaces like: System.Runtime.InteropServices._Assembly, or, System._AppDomain interface, or, especially,As a side note, can you talk about this project of yours? Looks.. interesting?! And you might consider loading .NET Core[^] instead of the normal framework?
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
-
As a side note, can you talk about this project of yours? Looks.. interesting?! And you might consider loading .NET Core[^] instead of the normal framework?
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
Hi, Super Lloyd, Yeah,...you understood essentially what I was getting at. The question is basically a COM question (since the .NET Framework classes, types, methods and attributes are 'exposed' to unmanaged applications through the associated COM interfaces). The idea behind the application is to see how difficult it is to use the .NET Framework assembly types and methods from a MASM assembly language application. And, actually, I didn't come up with the original concept,...I'm just writing a test app to demonstrate that the code does in fact work correctly. I assume that it's not impossible, because you could do the same thing in C++, using Visual Studio. The big problem with us assembly programmers is that we don't have all the header files that come with Visual Studio to rely on when we write our source, so we have to prototype everything from scratch (usually using the SDK header files, or files we can download from the Internet), and converting the syntax to that of an assembly language include file (the equivalent of a C or C++ header file), which is pretty simple. And, yes,...you were right about the type library (mscorlib.tlb). You can launch the OLE/COM ObjectViewer (which I think is included with Visual Studio), and, scroll down to the type libraries. A COM type library is supposed to be registered for COM activation (similar to the registry entries for a COM Server Dll) and has entries in the registry, which indicate its location on your computer. So, I can open up the type library and view its various interfaces in IDL format. I assume that the type library was created with Tlbexp.exe (Type Library Exporter), and so the order of implementation addresses for the various functions in the selected interface virtual function table should be the same as in the .NET Framework assembly. This has been working pretty well so far. I can call the method of a COM interface that corresponds to its .NET class, and retrieve the data requested without any difficulty. But, I'm uncertain, at this point how to reference the various .NET Framework types that I will need to supply as calling parameters to corresponding COM Interface methods, so that I can actually call [COM Visible] .NET methods in my unmanaged application. If you use an Intermediate Language decompiler, like ILSpy, you can open up mscorlib, and compare the actual .NET Framework class (for instance:
-
Hi, Super Lloyd, Yeah,...you understood essentially what I was getting at. The question is basically a COM question (since the .NET Framework classes, types, methods and attributes are 'exposed' to unmanaged applications through the associated COM interfaces). The idea behind the application is to see how difficult it is to use the .NET Framework assembly types and methods from a MASM assembly language application. And, actually, I didn't come up with the original concept,...I'm just writing a test app to demonstrate that the code does in fact work correctly. I assume that it's not impossible, because you could do the same thing in C++, using Visual Studio. The big problem with us assembly programmers is that we don't have all the header files that come with Visual Studio to rely on when we write our source, so we have to prototype everything from scratch (usually using the SDK header files, or files we can download from the Internet), and converting the syntax to that of an assembly language include file (the equivalent of a C or C++ header file), which is pretty simple. And, yes,...you were right about the type library (mscorlib.tlb). You can launch the OLE/COM ObjectViewer (which I think is included with Visual Studio), and, scroll down to the type libraries. A COM type library is supposed to be registered for COM activation (similar to the registry entries for a COM Server Dll) and has entries in the registry, which indicate its location on your computer. So, I can open up the type library and view its various interfaces in IDL format. I assume that the type library was created with Tlbexp.exe (Type Library Exporter), and so the order of implementation addresses for the various functions in the selected interface virtual function table should be the same as in the .NET Framework assembly. This has been working pretty well so far. I can call the method of a COM interface that corresponds to its .NET class, and retrieve the data requested without any difficulty. But, I'm uncertain, at this point how to reference the various .NET Framework types that I will need to supply as calling parameters to corresponding COM Interface methods, so that I can actually call [COM Visible] .NET methods in my unmanaged application. If you use an Intermediate Language decompiler, like ILSpy, you can open up mscorlib, and compare the actual .NET Framework class (for instance:
Alright then. It's really funny that you have an assembly question, while there was a very recent insider news about the rise of Assembly programming language! What a timely coincidence!
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
-
Alright then. It's really funny that you have an assembly question, while there was a very recent insider news about the rise of Assembly programming language! What a timely coincidence!
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
Assembly language is interesting. You can do almost anything,...it's like cheating. But, for the novice assembly programmer (like me) it's very error-prone. The biggest advantage is that it's extremely convenient to address anything in memory. This is why hackers prefer assembly language for their malicious code. Also, if you want total control over the precision of your data when implementing floating point calculations,...you'd want to write those procedures in assembly. Years ago, when I first discovered IDA Pro, which is a 32-bit disassembler, I realized that I was going to have to learn to read assembly language so that I could understand the output of IDA. So, I got a text book on the subject (there is only one text book on MASM Assembly Programming), and used it as a reference,...but, it is almost totally obsolete. The Intel® 64 and IA-32 Architectures Software Developer Manuals are by far the best source of information about the assembly language instruction sets.
-
Assembly language is interesting. You can do almost anything,...it's like cheating. But, for the novice assembly programmer (like me) it's very error-prone. The biggest advantage is that it's extremely convenient to address anything in memory. This is why hackers prefer assembly language for their malicious code. Also, if you want total control over the precision of your data when implementing floating point calculations,...you'd want to write those procedures in assembly. Years ago, when I first discovered IDA Pro, which is a 32-bit disassembler, I realized that I was going to have to learn to read assembly language so that I could understand the output of IDA. So, I got a text book on the subject (there is only one text book on MASM Assembly Programming), and used it as a reference,...but, it is almost totally obsolete. The Intel® 64 and IA-32 Architectures Software Developer Manuals are by far the best source of information about the assembly language instruction sets.
While I got you in a chatty mood... The last time I did assembly (yes, I did!) was around.. mmmm.. let me think... 1995? When Windows 1995, somehow I lost the plot (I think I didn't know how to compile program which supported the then new protected mode or something like that...).. I wonder, if I wanted to (briefly) play around with assembly today on Windows PC, what starting resource would you suggest? In fact, now that I think of it, I compared compiled C to assembly and it was pretty close, that might be another reason I gave up.... Do you write your all program in assembly? Or do you have __asm__ block (or something like that) inside C functions?
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
-
While I got you in a chatty mood... The last time I did assembly (yes, I did!) was around.. mmmm.. let me think... 1995? When Windows 1995, somehow I lost the plot (I think I didn't know how to compile program which supported the then new protected mode or something like that...).. I wonder, if I wanted to (briefly) play around with assembly today on Windows PC, what starting resource would you suggest? In fact, now that I think of it, I compared compiled C to assembly and it was pretty close, that might be another reason I gave up.... Do you write your all program in assembly? Or do you have __asm__ block (or something like that) inside C functions?
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
Super Lloyd, So, are you the only one here ??? Nobody has a clue as to where the mscorlib header files might be hiding ??? Dang, .NET Framework programmers,...:cool: I did find this blog about something similar: .Net Annoyances, 2004 The author says: "System.Object is defined in the mscorlib assembly. There is no mscorlib.h header file, and there is no mscorlib.idl to generate a C header file either. In order to get at this stuff I had to load up the binary type library file and export it as IDL." The simplest way to get back into assembly language programming is downloading: The MASM32 SDK
-
Super Lloyd, So, are you the only one here ??? Nobody has a clue as to where the mscorlib header files might be hiding ??? Dang, .NET Framework programmers,...:cool: I did find this blog about something similar: .Net Annoyances, 2004 The author says: "System.Object is defined in the mscorlib assembly. There is no mscorlib.h header file, and there is no mscorlib.idl to generate a C header file either. In order to get at this stuff I had to load up the binary type library file and export it as IDL." The simplest way to get back into assembly language programming is downloading: The MASM32 SDK
I'm posting this just in case someone out there in the galaxy has a similar problem. :-D As it turns out, I had the correct approach, but, I made a simple mistake (an incorrect assumption). If you open the mscorlib Type Library in the OLE/COM Object Viewer, and select one of the COM interfaces, it will produce the IDL code of the interface virtual function table's implemented methods in the correct vtable order. I did this, for example, with the System.Reflection._Assembly interface that exposes the public members of the System.Reflection.Assembly class to unmanaged code. What I didn't notice was that the System.Reflection._Assembly interface was derived from IDispatch, instead of IUnknown, like I was assuming. IUnknown has three methods and IDispatch has four methods (in addition to IUnknown's three methods),...so, my count of the offset to the correct COM method implementation function pointer within the interface vtable was off by 4x4bytes. Embarrassing,... ...Just for some serious overkill, here is the IDL output of the System.Reflection._Assembly interface (from OLE/COM Object Viewer):
[
odl,
uuid(17156360-2F1A-384A-BC52-FDE93C215C5B),
version(1.0),
dual,
oleautomation,
custom({0F21F359-AB84-41E8-9A78-36D110E6D2F9}, "System.Reflection.Assembly")]
interface _Assembly : IDispatch {
[id(00000000), propget,
custom({54FC8F55-38DE-4703-9C4E-250351302B1C}, "1")]
HRESULT ToString([out, retval] BSTR* pRetVal);
[id(0x60020001)]
HRESULT Equals(
[in] VARIANT other,
[out, retval] VARIANT_BOOL* pRetVal);
[id(0x60020002)]
HRESULT GetHashCode([out, retval] long* pRetVal);
[id(0x60020003)]
HRESULT GetType([out, retval] _Type** pRetVal);
[id(0x60020004), propget]
HRESULT CodeBase([out, retval] BSTR* pRetVal);
[id(0x60020005), propget]
HRESULT EscapedCodeBase([out, retval] BSTR* pRetVal);
[id(0x60020006)]
HRESULT GetName([out, retval] _AssemblyName** pRetVal);
[id(0x60020007),
custom({0F21F359-AB84-41E8-9A78-36D110E6D2F9}, "GetName")]
HRESULT GetName_2(
[in] VARIANT_BOOL copiedName,
[out, retval] _AssemblyName** pRetVal);
[id(0x60020008), propget]
HRESULT FullName([out, retval] BSTR* pRetVal);
[id(0x60020009), propget]
HRESULT EntryPoint([out, retval] _MethodInfo** pRetVal);
[id( -
I'm posting this just in case someone out there in the galaxy has a similar problem. :-D As it turns out, I had the correct approach, but, I made a simple mistake (an incorrect assumption). If you open the mscorlib Type Library in the OLE/COM Object Viewer, and select one of the COM interfaces, it will produce the IDL code of the interface virtual function table's implemented methods in the correct vtable order. I did this, for example, with the System.Reflection._Assembly interface that exposes the public members of the System.Reflection.Assembly class to unmanaged code. What I didn't notice was that the System.Reflection._Assembly interface was derived from IDispatch, instead of IUnknown, like I was assuming. IUnknown has three methods and IDispatch has four methods (in addition to IUnknown's three methods),...so, my count of the offset to the correct COM method implementation function pointer within the interface vtable was off by 4x4bytes. Embarrassing,... ...Just for some serious overkill, here is the IDL output of the System.Reflection._Assembly interface (from OLE/COM Object Viewer):
[
odl,
uuid(17156360-2F1A-384A-BC52-FDE93C215C5B),
version(1.0),
dual,
oleautomation,
custom({0F21F359-AB84-41E8-9A78-36D110E6D2F9}, "System.Reflection.Assembly")]
interface _Assembly : IDispatch {
[id(00000000), propget,
custom({54FC8F55-38DE-4703-9C4E-250351302B1C}, "1")]
HRESULT ToString([out, retval] BSTR* pRetVal);
[id(0x60020001)]
HRESULT Equals(
[in] VARIANT other,
[out, retval] VARIANT_BOOL* pRetVal);
[id(0x60020002)]
HRESULT GetHashCode([out, retval] long* pRetVal);
[id(0x60020003)]
HRESULT GetType([out, retval] _Type** pRetVal);
[id(0x60020004), propget]
HRESULT CodeBase([out, retval] BSTR* pRetVal);
[id(0x60020005), propget]
HRESULT EscapedCodeBase([out, retval] BSTR* pRetVal);
[id(0x60020006)]
HRESULT GetName([out, retval] _AssemblyName** pRetVal);
[id(0x60020007),
custom({0F21F359-AB84-41E8-9A78-36D110E6D2F9}, "GetName")]
HRESULT GetName_2(
[in] VARIANT_BOOL copiedName,
[out, retval] _AssemblyName** pRetVal);
[id(0x60020008), propget]
HRESULT FullName([out, retval] BSTR* pRetVal);
[id(0x60020009), propget]
HRESULT EntryPoint([out, retval] _MethodInfo** pRetVal);
[id(Well done! :)
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
-
Well done! :)
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
WHAT ???
-
WHAT ???
you solved your problem! ;)
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!