In the dialog box procedure, function call somebody else, compile there is no problem, but a run error

 
//this is defined by others, I have introduced 
Extern "C" 
{
__declspec (dllexport) int Get_Picture_Open (HWND HWND); 
__declspec (dllexport) void Get_Picture_Data (DWORD * pData, ULONG nCount, BOOL bRet); 
} 

Then in the code using the

 
Int ret=Get_Picture_Open (hWnd);//break point is it can perform, there is no error 
Get_Picture_Data (pData, 100, TRUE);//this will be an error, the debug the error, esp what error 

Compiled passed, however, had problems with a running tips ESP error, see the online posts but could not find a solution, simply post questions, consult a great god help directly, thanks a lot

CodePudding user response:

ESP error caused by the general way is to call not

Try to block extern "C"

CodePudding user response:

Extern "C" int _stdcall GetRandomRgn (HDC HDC, HRGN HRGN, int iNum);

"What the esp error" error function agreed

CodePudding user response:

The value of ESP was not properly saved across indicates a function call. This is usually a result of calling a function declared with one calling convention with a function pointer declared with a company's calling convention

Is always prompt this error, it is call order wrong, but how do I change the calling convention? I add __stdcal in front or _cdecl these can't directly compiled through,

CodePudding user response:

refer to the second floor schlafenhamster response:

extern "C" int _stdcall GetRandomRgn (HDC HDC, HRGN HRGN, int iNum);

"What the esp error" error function agreed

I also know that error is agreed, that how to solve this problem now? In the code I add _stdcall and __cdecl these keywords directly compiled by
Extern "C" this is not my code, and refers to other people's files, just I saw the view definition, should be can not be changed, how to solve this problem? Thank you very much

CodePudding user response:

reference 1st floor zgl7903 response:

ESP error caused by the general way is to call not

Try to block extern "C"

How do I block extern "C"
This is what I see by looking at the function definition, the estimate is in. H or. Inside the lib, should can't be modified

CodePudding user response:

"This is defined by others, I have introduced"
Define your own
Extern "C" int _stdcall GetRandomRgn (HDC HDC, HRGN HRGN, int iNum);

CodePudding user response:

Collapsed in the pop-up dialog box, press the corresponding button to enter debugging press Alt + 7 key to view the Call Stack, namely "the Call Stack" from the inside to the following out of from the inner to outer function Call history, double-click a row to the cursor to the Call of the source code or assembly instruction, don't understand when double click on the next line, until we can read ,

Calling convention https://msdn.microsoft.com/zh-cn/magazine/9b372w95.aspx

CodePudding user response:

refer to 7th floor zhao4zhong1 response:

collapsed in the pop-up dialog box button to enter the corresponding debugging, press Alt + 7 key to view the Call Stack, namely "the Call Stack" from the inside to the following out of from the inner to outer function Call history, double-click a row to the cursor to the Call of the source code or assembly instruction, don't understand when double click on the next line, until we can read ,

Calling convention https://msdn.microsoft.com/zh-cn/magazine/9b372w95.aspx

From the error prompt, error is calling convention
The question is how to change the calling convention

CodePudding user response:

DLL export function name the things
Key words: vc + + DLL export functions
Often use VC6 Dependency check the name of the DLL export functions, can find the name of the DLL export functions are sometimes very different, the cause of different mostly and compile DLL when specified by the qualifier with the DLL export functions,
Vc + + to support two languages: C/C + +, this also is the root cause of the differences in the DLL export functions
We use VS2008 new DLL project, a project called "TestDLL"
The default source file suffix. CPP instead. C (C)
Enter the test code is as follows:
01 int _stdcall MyFunction (int iVariant)
02 {
03 return 0;
04}
In order to export the function above, we have the following several methods:
1. Using the traditional (. The module definition file (def)
A new suffix for. Def text file (here to build a TestDll. Def), the file content is:
The LIBRARY TestDll
EXPORTS
MyFunction
When the Link specified depends on input file:/DEF: "TestDll. DEF
"2. Visual c + + provides convenient way
Join before 01 done int __declspec (dllexport) keyword
Through the above two methods, we can export MyFunction function,
We use the Dependency check the exported functions:
The first method the exported functions as follows:
MyFunction
The second method the exported functions as follows:
_MyFunction @ 4
__stdcall can make the export function to add an underscore the names, followed a @ plus the number of bytes parameters, such as _MyFunction @ 4 parameters (int iVariant) is 4 bytes
__fastcall as __stdcall similar, but not in front of the underline, but a @, such as @ MyFunction @ 4
__cdecl is beginning the function name,
Summary: if you want to export the function in the C file, and don't let the compiler function name, def file is used to derive the function,
Let's take a look at c + + files
We use VS2008 new DLL project, a project called "TestDLL"
The default source file suffix for the CPP (namely c + + files),
Enter the test code is as follows:
01 int _stdcall MyFunction (int iVariant)
02 {
03 return 0;
04}
In order to export the function above, we have the following several methods:
3. Use the traditional (. The module definition file (def)
A new suffix for. Def text file (here to build a TestDll. Def), the file content is:
The LIBRARY TestDll
EXPORTS
MyFunction
When the Link specified depends on input file:/DEF: "TestDll. DEF
"4. Visual c + + provides convenient way
Join before 01 done int __declspec (dllexport) keyword
Through the above two methods, we can export MyFunction function,
We use the Dependency check the exported functions:
The first method the exported functions as follows:
MyFunction
The second method the exported functions as follows:
? MyFunction @ @ YGHH @ Z
Can see the second method to get the export function name is not what we want, and if used display method in exe MyFunction (LoadLibrary and GetProcAddress call) call will fail,
But with the import library (*. LIB) calls, the compiler automatically convert the function name, so there is no problem, always
Solve the problem of method is:
Using VC preprocessor directive to "# pragma" option to specify links,
As follows:
# pragma comment (would, "/EXPORT: MyFunction=? MyFunction @ @ YGHH @ Z ")
At this moment, you will find the exported function name in the table have we want MyFunction, but we found the original? MyFunction @ @ YGHH @ Z function is still there, then you can put the __declspec () modified to remove, you just need to pragma directive,
But also can make the following format:
# pragma comment (would/EXPORT: MyFunction=_MyFunction @ 4, "PRIVATE")
The role of PRIVATE and its role in the def file, more # pragram please see MSDN,
Summary: if you want to export functions in c + + files, and don't let the compiler function name, def file is used to derive the function,
At the same time can use the # pragma instruction can also be used in (C),
Conclusion:
In c + + compiler to generate DLL, adaptation, the name of the exported functions and different compiler USES adaptation rules are different, so the adaptation after name are different (typically involves the overloading in c + +, etc.),
nullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnull