Seriously, if you have a well-known library that is crashing all the time, then you are probably using it outside the bounds it was intended to be used. I would:
0. RTFM! and check that you are using the APIs correctly.
1. Check for limits on file storage (number of files that may be stored, upper limits on file sizes)
2. Check for limits on container size
3. Check for limits on the file-system containing your container (e.g. FAT32 can only handle files up to 4GB in size)
Yeah, that is right.
I think you're right, maybe the library isn't prepared for what I need. But the way to use unfortunately there isn't much documentation on so I had to use examples that I found on the internet.
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 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, System._Type...???
I've been using the OLE/COM Object Viewer to do this,...assuming that the mscorlib Type Library has the exact same interface definitions as the actual .NET Framework classes, types and methods,...but, I'm crashing my application with (presumably) incorrect parameters or signatures,...
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: Assembly Class), with its corresponding COM Interface for unmanaged applications: _Assembly, and get an idea for how they correspond.
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.
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?
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,...
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.
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):
I think adding the "Seriously, do it" was unnecessary, like I was some idiot.
Lighten up, Francis. I hate to tell you this, but that's part of my signature. It shows up on everything I post here.
Why do I have that link in there? Because over the 13 years I've been around here I've watched the quality of questions plummet. There are so many "questions" asked around here that don't qualify as questions at all and usually don't have any context to frame the question nor enough detail to answer them.
Asking questions really is a skill. As you are/were a teacher: Hi! I am a teaches a course in C# for beginners.
you should already know this.