I work on a project that requires .Net interoperability with unmanaged code. I started to work with .Net a couple of weeks ago, though I have a lot of experience with C/C++, and I am surprised how CLR deals with P/Invoke. Here are the details. My colleague wrote this function
__declspec(dllexport) int __stdcall ReadIPWSensor(unsigned int deviceClassId, void *buffer) {...}
and I had to call it from C# module. I imported the function as
[DllImport("ipw", CallingConvention = CallingConvention.StdCall)]
extern static int ReadIPWSensor(uint deviceClassId, IntPtr buffer);
just to find out an exception (System.EntryPointNotFoundException, Unable to find an entry point named 'ReadIPWSensor' in DLL 'ipw'). I used DependencyWalker tool and found that the function was exported as ?ReadIPWSensor##YGHIPAX#Z (my colleague forgot to export it in the DEF file). Just for the quick test (the unmanaged DLL compiles very slowly) I changed my import definition to:
[DllImport("ipw", EntryPoint = "#22", CallingConvention = CallingConvention.StdCall)]
extern static int ReadIPWSensor(uint deviceClassId, IntPtr buffer);
as the ordinal was 22. The test passed successfully with the new import definition.
My first question is: What are the good practices when dealing the mangled function exports? Is it a good practice to use the export ordinals?
In my case I had access to the C++ source code and the DEF file so I added the export and changed back the import definition to
[DllImport("ipw", CallingConvention = CallingConvention.StdCall)]
extern static int ReadIPWSensor(uint deviceClassId, IntPtr buffer);
I knew there is another function we already use in our project and wanted to compare my code with the existing one. The function is defined as
extern "C" __declspec(dllexport) int __stdcall LoadIPWData(void
*buffer)
and is imported as
[DllImport("ipw", CallingConvention = CallingConvention.StdCall)]
extern static int LoadIPWData(IntPtr buffer);
To my surprise DependencyWalker tool shows that the function is exported as _LoadIPWData#4 (my coworker forgot to export it in the DEF file again). However with this function there is no System.EntryPointNotFoundException error. Obviously, the CLR somehow managed to resolve the right name. It seems there is some sort of fallback mechanism that allows CLR to find the right function. I can easily imagine the it sums the sizes of the parameters and is looking for "function_name#the_sum_of_all_parameter_sizes" though it seems quite simplistic.
My second question is: How does CLR match the exported function names during P/Invoke?
In this scenario I think CLR is so clever that it actually hides a bug - LoadIPWData function should be accessible by its name from other unmanaged modules. Maybe I am a bit of paranoid but I prefer to know how actually CLR works. Unfortunately all my google searches on that topic were fruitless.
The pinvoke marshaller has built-in knowledge of a few common DLL export naming schemes. It knows that __cdecl functions often have a leading underscore and that __stdcall in 32-bit mode is commonly decorated with a leading underscore and a trailing #x where x is the size in bytes of the arguments passed on the stack. It also knows that winapi functions are exported with a trailing extra A or W, a naming scheme to distinguish functions that accept strings and for which there's both an ansi and a Unicode version. The corresponding [DllImport] property is CharSet. It just tries them all until it finds a match.
It doesn't know anything about C++ compiler name decoration rules (aka mangling) so that's why you have to use extern "C" to suppress that by hand.
Related
I am creating a DLL and exporting a SimpleMAPI DLL function and one of the functions signature is as following:
extern "C" ULONG __declspec(dllexport) WINAPI MAPISendMail(LHANDLE lhSession, ULONG_PTR ulUIParam, lpMapiMessage lpMessage, FLAGS flFlags, ULONG ulReserved);
I am using C++ Builder, using clang compiler. Compiler issues warning:
[bcc32c Warning]: redeclaration of 'MAPISendMail' should not add 'dllexport' attribute mapi.h(262): previous declaration is here
It compiles and works, but I am bothered by this warning. Can it be avoided?
As #RemyLebeau pointed out, the warnings happened because I included <mapi.h> header.
If MAPI DLL is being created (creating your own DLL that other programs will use or exporting MAPI functions), so if one is implementing MAPI support in their own program, then the required structures and #define are copied from the original mapi.h file into a custom header file which is then included. #define such as FLAGS or MapiMessage struct.
If MAPI is being used (so using calling MAPI functions from other DLL, or other programs) then <mapi.h> is included.
So after creating a custom mapidefs.h file which only contained required structures and #define, the problem is now solved.
There is also this example on StackOverflow as well.
Consider this small C file:
#include <stdio.h>
void f(void) {
puts(NULL);
}
I'm running the WP and RTE plugins of Frama-C like this:
frama-c-gui puts.c -wp -rte -wp-rte
I would expect this code to generate a proof obligation of valid_read_string(NULL); or similar, which would be obviously unprovable. However, to my surprise, no such thing happens. Is this a deficiency in the ACSL specification of the standard library?
Basically yes. You can see in the version of stdio.h that is bundled with Frama-C that the specification for puts is
/*# assigns *stream \from s[..]; */
extern int fputs(const char * restrict s,
FILE * restrict stream);
i.e. the bare minimum, an assigns clause (plus a from clause for Eva). Preconditions on s and stream. Adding a precondition on s would be easy; things are more complex for stream since you need a model for the various objects of type FILE.
I have application that contain statically linked lua 5.2 inteperpreter (and haven't access to code).
When I trying to write extension with next code:
#define LUA_LIB
#define LUA_BUILD_AS_DLL
#include "lua.hpp"
extern "C"
{
static int test(lua_State* state)
{
return 1;
}
static const struct luaL_Reg functions[] = {
{"test", test},
{NULL, NULL},
};
int __declspec(dllexport) luaopen_test(lua_State* state)
{
luaL_newlibtable(state, functions);
luaL_setfuncs(state, functions, 0);
return 0;
}
}
And compile it with statically linked lua52.lib .
I get "multiple vms detected" error when I trying to require it fromn lua code.
What I can do in this situation?
You can't compile it with statically linked lua52.lib as the main application loads its own version of lua52.lib and when this module is "required", it loads its own copy, which leads to "multiple VMs detected" message.
With statically compiled VM you have two options (on Windows): (1) include all your modules statically, or (2) compile your modules against Lua52.dll, but instead of the actual DLL include a "proxy" DLL that will forward Lua API calls to the methods in the statically compiled executable (the API methods also need to be exported in the executable).
See this thread for the discussion on how the executable needs to be compiled and LuaProxyDllFour page for the proxy DLL.
On Linux you don't need to have a proxy library, but you still need to avoid linking Lua interpreter into the library and export symbols from the executable by using -Wl,-E linker option; see lhf's answer for details.
The symbol # was seen in one the program ,But i could not find why it is used .
The syntax is
const unsigned char Array_name[] #(INFO_Array+1) = {................};
The meaning of # operator can be different for the particular compiler in which the code is compiled.
For example, in IAR Embedded Workbench's C/C++ compiler the # operator can be used for placing global and static variables at absolute addresses.
If you are using IAR C/C++ compiler, the compiler will place Array_name in the address (INFO_Array+1).
# operator can also be used to place a variable or object in a particular section of the object file:
uint32_t CTRL_OFFSET_x86 # "MY_RAM_SECTION";
The above line will place CTRL_OFFSET_x86 in the object file section MY_RAM_SECTION.
#pragma location can also be used for this purpose.
To me, it looks like a compiler flag to disable interpreting the string "INFO_Array+1" as an expression. In C# for example, you can use the #-Operator to tell the compiler to use the following expression as String without trying to evaluate it.
A quick googling showed:
For example, this line will fail to compile:
int new = 1776; // 'new' is a keyword
However, this line compiles without error:
int #new = 1776;
I have installed the current stable JEDI Code library in C++ Builder XE3 on Windows 7 x32. It works fine, but only as long as I don't include files like JclFileUtils.hpp which are including JclWin32.hpp. Then I get always the compiler error E2040: "Declaration terminated incorrectly" (in file JclWin32.hpp, line 682, second line in the following code snippet):
#define NetApi32 L"netapi32.dll"
static const System::Int8 CSIDL_PROGRAM_FILESX86 = System::Int8(0x2a);
#define RT_MANIFEST (System::WideChar *)(0x18)
I neither have an idea were this error comes from, nor could I found any hints to this. What could be the cause? Thanks in advance.
I got help and the solution for this problem. Just replace the static const declaration:
static const System::Int8 CSIDL_PROGRAM_FILESX86 = System::Int8(0x2a);
with this macro definition:
#define CSIDL_PROGRAM_FILESX86 0x2a
This is a bug in JclWin32.pas.
In C/C++, the Win32 API declares CSIDL values in Microsoft's shlobj.h header using preprocessor #define statements, eg:
#define CSIDL_PROGRAM_FILESX86 0x002a
After the preprocessor is run and performs #define symbol replacements, the compiler ends up seeing the following invalid declaration in JclWin32.hpp:
static const System::Int8 0x002a = System::Int8(0x2a);
JCL should not be re-declaring CSIDL_PROGRAM_FILESX86 (or any other CSIDL value) at all. It should be either:
using Delphi's own Winapi.ShlObj unit, which already declares CSIDL values.
if not using the Winapi.ShlObj unit, then it should at least be declaring its manual CSIDL values as {$EXTERNALSYM} so they do not appear in the generated JclWin32.hpp file. If needed, JCL can include an {$HPPEMIT '#include <shlobj.h>'} statement to pull in the existing Win32 API declarations for C/C++ projects to use.