I'm trying to use a COM library that makes use of a vtable. However, something funky is going on with the stack after I call the functions, which tells me I'm doing something wrong.
The header file with the vtable definition is pasted here: pastebin.com/m2d66c18c (see in particular the code starting at line 810). An example is pasted here: pastebin.com/m1b46e662.
The table is being filled with the correct locations for the functions, but when I call the function(s), they appear to be looking in the wrong locations for the arguments on the stack. Also, after calling the functions in the table, the stack is messed up and my program crashes. I've tried changing the function type to both __cdecl and __stdcall but this does nothing.
It's either my code or the library, and the company that wrote the library hasn't gotten back to me -- because it's the weekend, I'm assuming. Also, there is a demo application that utilizes the library, and it works -- so I think it's my code/compiler (gcc)/something else, not the library.
Could it be that there something in particular that you need to do in order to use a COM library?
Related
I am creating a C++/CLI wrapper for native C code that has it's own Object typedef and am receiving the C2872 'Object': ambiguous symbol error when linking. The compiler output is:
1>C:\src\OS_kernel.h(27): error C2872: 'Object': ambiguous symbol
1>C:\src\OS_types.h(261): note: could be 'ObjectStruct *Object'
1>C:\src\OS_kernel.h(27): note: or 'System::Object'
It may be worth mentioning that I am mocking this native C code for the purposes of the C++/CLI wrapper; not sure if that opens up a potential solution that would otherwise not be available if no source code was available. I'm guessing there is a way to specify which definition I want the code to use, but I don't know how to specify that. Is that possible? I want to specify it to use the ObjectStruct *Object.
It would be great if I didn't have to modify the mock code since it could potentially be hundreds or thousands of individual places.
As an aside, I am also receiving this error for other types the native library is using, such as Buffer and Boolean.
OK, since you're getting the error in OS_kernel.h, I'm guessing that's part of the C code you're wrapping.
Obviously, one possible solution is to treat the name Object as a reserved word, and edit your C code to not use it. One could argue that this is the most correct solution, but it may not be possible to do that.
Depending on how you're referencing the C code, it may be reasonable to compile it as C++, and stick it entirely within a namespace. That way, when the C code (now C++ code) uses Object it will see the typedef within its namespace, and you'll have the option to reference either namespace in your code.
The fact that you're getting this error from your library's header file indicates to me that you've got a using namespace System; directive, and that the #include of your library's header files comes after that using directive. Consider removing the using namespace System;, or at least moving it after the #include. This way, you won't get that error in the library's headers, you'll just have to deal with it in your code.
I'm creating an application in VBA that uses a reference from vbscript.dll
I'm trying to figure out the best way to load the library, and am having difficulty distinguishing between using a declare function (http://msdn.microsoft.com/en-us/library/aa716201(v=vs.60).aspx) or just dynamically adding it to the list of references (How to add a reference programmatically, part 2 of the top answer)
If anyone can clarify the difference in result between the two, and maybe some advantages of one, I would be very happy.
My Notes:
I like the looks of a simple declare function, for one thing it's short and looks nice. For another, I like avoiding hard coded paths unless I know the files won't be found in different places.
On the other hand, I really like the error handling in method 2.
Declare is (typically) used for calling stdcall-supported functions exported from Windows DLLs. The VB run-time takes care of calling LoadLibrary, GetProcAddress, etc. to locate and load the functions you've declared. Most of the Windows API is used this way from VB/VBA.
References are used for COM objects -- that is, libraries that define a type library and a COM interface.
It's rare for a library to support both. If what you have is a COM library (if it appears in the 'References' dialog), add a reference to it and instantiate it that way.
I'm trying to port a C++.NET (managed extensions) application to C++/CLI. However I'm not very strong with the syntax yet.
What I'm trying to do is to create a wrapper for a C Dll file.
To do this I'm using DllImport but I failed to found documentation on it's use. There are some problems due to changes of the syntax but I couldn't find out why yet.
The C++.NET line looks like this:
[DllImport("my.dll", CharSet = Ansi, CallingConvention = Cdecl, EntryPoint = "#10")]
static MY_STATUS CPPInit(MY_HANDLE *pLmxHandle);
The idea is to pass a reference of MY_HANDLE to the function which initializes it. One problem is that the keywords Ansi and Cdecl are unknown. I expect I need to put some class infront of them but it's a little hard without docs or samples.
The other thing I have is a function which returns a static string:
char *MyFunc();
Can I assume that it can be mapped to String^?
Thanks in advance.
thanks for the comment.
I thought to myself that I need to build a mixedmode library in order to avoid p/invoke. This just takes some time though.
Actually I solved the compile error in another way. Although I havn't tested it yet because I'm facing some 32/64 bit issues which I can't solve because of other bugs in Whidbey beta2.
My solution was to write the protype in the following way:
interior_ptr<MY_HANDLE> pMyHandle;
From what I understood it should give the function a reference (hence an address) to the dll function. Once I get to try it out I will see if my idea works.
Otherwise I will go for the following option (which i've been offered):
[Out] IntPtr p_MyHandle
Anyway I think the problem is solved because one of those should work.
It can be used to run arbitary Dynamic Link Library in windows,
how can it possibly know the entry point of an arbitary dll?
The answer depends on how much details you need. Basically, it comes down to this:
A DLL can optionally specify an entry-point function. If present, the system calls the entry-point function whenever a process or thread loads or unloads the DLL.
[...] If you are providing your own entry-point, see the DllMain function. The name DllMain is a placeholder for a user-defined function. You must specify the actual name you use when you build your DLL.
(Taken from the MSDN article Dynamic-Link Library Entry-Point Function.)
So basically, the entry point can be specified inside the DLL, and the operating system's DLL loader knows how to look this up.
The IMAGE_OPTIONAL_HEADER (part of the portable executable's header on Windows machines) contains an RVA of the AddressOfEntryPoint that is called by programs looking for an entry point to call (e.g., the loader).
More information on the IMAGE_OPTIONAL_HEADER can be found here. And this paper is good for just general PE knowledge.
What do you mean by "run a DLL"? DLLs aren't normal programs, they are just a collection of functions. The entry point itself usually doesn't do much apart from initializing stuff required by other functions in the DLL. The entry point is automatically called when the DLL is loaded (you can use LoadLibrary to do this).
If you want to call a specific function after loading the DLL, you can use GetProcAddress to get a pointer to the function you want.
Ok, well I have sorta of an odd situation. I have a two applications. One is the main application and the other is a helper bundle that is loaded during run time. What I want to do is to call a function defined within the main application from the bundle so that code does not have to be copied over. I have tried setting the header declaration for the function
NSString *TXReadableTime(NSTimeInterval date, BOOL longFormat);
within the helper bundle, but it still fails to compile. This is because one of my selectors is calling the function and the compiler is not finding it within the code. Only the header reference.
So I guess what my real question is, is there a way to have dynamic functions? One that is promised to the compiler, but is handled by a separate process. The helper bundle itself is allocated into memory so it has access to selectors of the main application, but I do not want to rewrite the function into a selector because it would require a lot of work.
Use -bundle_loader linker flag to specify the executable which will load the plugin. See ld man page, another Apple doc, and this informative blog post.