When learning about debugging OpenGL I implemented a function callback which would receive any debug error messages from the OpenGL API whenever something went wrong. In the tutorial it said that the function signature was:
typedef void APIENTRY funcname(GLenum source, GLenum type, GLuint id,
GLenum severity, GLsizei length, const GLchar* message, const void* userParam);
So on Windows I implemented this callback. On Windows APIENTRY is a define for __stdcall. __stdcall I believe is a Windows-specific keyword specifying the calling convention. Later I ported my code to Linux, and for starters my GCC with Eclipse didn't recognise APIENTRY, because it's a Windows define. So I changed it to __stdcall, which I'm not sure if it recognised or not, but regardless it threw an error saying:
"Expected initialiser before glCheckError_"
As my callback function is void __stdcall glCheckError_(/Params/).
Removing the __stdcall preface makes the program work fine without it.
I'm wondering whether this prefix is necessary, for either Windows or Linux? The funny thing is that the place that suggested I add __stdcall to the function signature was the Khronos webpage, which holds documentation for OpenGL, so as far as I can tell it shouldn't be specifying OS-specific information, as OpenGL is cross-platform. So do I need this __stdcall prefix?
On windows, and only under 32bit, then it will make a difference. (The default is __cdecl calling convention, v.s. the __stdcall used by openGL). This can end up corrupting the stack if you use the wrong convention (the compiler should error with any luck).
On 64bit windows, it makes no difference (because stdcall isn't available, so all __stdcall/__cdecl will default to __fastcall).
It make no difference to linux/macos/android/ios.
Wrapping this in a macro should be all that's needed.
#if definded(_WIN32) && !defined(_WIN64)
# define STDCALL __stdcall
#else
# define STDCALL
#endif
Related
Im reading some of the game fix codes which deal with memory manipulation to fix a game's "issue". I found out that the code uses 2 macros that are WINAPI and STDMETHODCALLTYPE. These macros all get evaluated into __stdcall which specifies the calling convention for a function. I also found out that APIENTRY is also another macro alias for WINAPI. So are there any differences between these macros ? It seems to me that they are just aliases. Why are there so many of them ?
All data types and calling conventions in the Windows API are defined as aliases (preprocessor macros or typedefs). This allows for a stable ABI, irrespective of the compiler or toolchain. It also allows to change the ABI without breaking existing code (e.g. when 64-bit Windows was introduced).
Both WINAPI and STDMETHODCALLTYPE expand to the same thing: __stdcall for x86 and nothing for everything else. So why have 2 aliases for the same thing then? Because they control the calling convention for different subsets:
WINAPI specifies the calling convention for the flat C-based Windows API.
STDMETHODCALLTYPE, on the other hand, controls the calling convention for COM (Component Object Model).
COM and the Windows API are independent. Having 2 aliases to control the calling convention for either makes perfect sense. You wouldn't want to break all COM, just because you're moving to a new ABI for Win128.
Because back in 16-bit all these were different conventions. Since x86 flat mode, everything windows-related is __stdcall (Push right to left, callee clears the stack). __cdecl, __fastcall also exists.
Since x64, there is practically only one and all these are ignored.
The same occurs to many other Windows elements, like WPARAM and LPARAM. Once WPARAM was 16 bit, in x86 they are both 32-bit and in x64 they are both 64 bit.
I have read an article about Calling convention (__stdcall, __fastcall, pascal, cdecl etc...)
And I wonder: Why is often __stdcall (WinAPI) declared for WinMain() function?
As I read, __stdcall operates with the stack, __fastcall operates on registers and not using stack at all.
So , I've tried to declare WinMain() with the __fastcall. Compiler (Visual C++) has given me an error.
error C2373: 'WinMain' : redefinition; different type modifiers
c:\program files\microsoft sdks\windows\v6.0a\include\winbase.h(2560) : see declaration of 'WinMain'
Why can't I use __fastcall for WinMain() and is there any possibility to use it for it?
Because to work on registers without using stack is miles faster, isn't it?
PS
My suggestion is, that there are some method contracts that disallow me to use __fastcall, but it's only my suggestion.
You can only specify the calling convention on functions that you write and/or you have the source code of.
You cannot change calling conventions of function that are in a library (static/dynamic) since those are already compiled/linked.
Important is that the declaration and definition have the same convention.
BTW : you wouldn't gain anything by having (win-)main having the fastcall convention since it's only called once!
You would consider fastcall on functions with many small parameters (that fit in registers) that are called very very often during long periodes of time.
The (buildin) startup routine for windows programs will call either WinMain or main (depending on GUI or Console app) with a specific convention.
If you write a WinMain or main with a different convention then the linker will complain.
WinMain must be __stdcall. It's called by the CRT start-up code, which is already built to pass parameters in a way defined by __stdcall convention.
I've been working on this code for hours, and it is driving me crazy!
The entire source is here http://pastebin.com/Urxh68W4 but I'm pretty sure I know the problem.
extern "C" NTSYSAPI LONG NTAPI ZwUnmapViewOfSection(HANDLE, PVOID);
When I run it I get the following error:
Error 1 error LNK2019: unresolved external symbol __imp__ZwUnmapViewOfSection#8 referenced in function _wWinMain#16
I'm guessing that there is some dll or library I should be including so I added Ntoskrnl.lib into my project because it contains the ZwUnmapViewOfSection function.
I have absolutely no idea what to do. Should I have used the Ntdll.dll? If so, how do I even link a dll? I thought you could only use the libraries in Visual Studio 2010.
Also, what exactly is NTSYSAPI and NTAPI? There is hardly any information on the net.
This looks like user-mode code, so you'll likely not want to link against ntoskrnl.lib. You would rather link against ntdll.
The way I would probably do this is to use dynamic linking and call GetProcAddress passing in a HANDLE to ntdll.dll and ZwUnmapViewOfSection.
Example code:
typedef LONG (NTAPI *pfnZwUnmapViewOfSection)(HANDLE, PVOID);
HMODULE hMod = GetModuleHandle("ntdll.dll");
pfnZwUnmapViewOfSection pZwUnmapViewOfSection= (pfnZwUnmapViewOfSection)GetProcAddress(hMod, "ZwUnmapViewOfSection");
I haven't compiled this, but it should look something like that (maybe add some error checking, etc).
With regard to your other questions: NTAPI is a macro that defines the calling-convention, in this case __stdcall. The calling convention has to do with how the arguments to the function are passed, and who will be cleaning up those arguments.
For example, __stdcall requires the arguments to be pushed on the stack in reverse order and the callee will clean-up the stack.
Similarly, NTSYSAPI is a macro that just resolves to __declspec(dllimport) if I recall correctly.
Also, I should point out that calling functions exported by NtDll in user-mode is generally frowned upon. And, the code that you're writing will also have additional problems along the way (even after it appears to be working).
In case you're looking for another example of code that performs a very similar task to the one you're writing, you might check here. It was a technique used by the Duqu malware. Good luck!
It seems to me, that MSVS ignores __stdcall directive on my functions. I'm cleaning up the stack manually, but the compiler still append ADD ESP instructions after each CALL.
This is how I declare the function:
extern "C" void * __stdcall core_call(int addr, ...);
#define function(...) (DWORD WINAPI) core_call(12345, __VA_ARGS__)
return function("Hello", 789);
And this is how the output looks like:
(source: server4u.cz)
I've marked with arrows redundant ADD instructions, which MSVS automatically append after each call, despite the fact, that cleaining the stack is a callee responsibility (reference: http://en.wikipedia.org/wiki/X86_calling_conventions#List_of_x86_calling_conventions) and this causes the crash of my progrm. If I manually replace the ADD instructions with NOPs, program works as supposed. So, my question is... Is there a way how to force the compiler to stop addaing these instructions?
Thanks.
The problem is here: , ...).
Functions with variable number of arguments cannot be __stdcall.
__stdcall functions must remove all their stack arguments from the stack at the end, but they can't know in advance how much stuff they will receive as parameters.
The same holds for __fastcall functions.
The only applicable calling convention for functions with variable number of arguments is __cdecl, where the caller has to remove the stack parameters after the call. And that's what the compiler uses despite your request to use __stdcall.
In MFC VC++, setTimer function is setted using a CALLBACK procedure. From the link I read that
A function that is marked with __stdcall uses the standard calling
convention so named because all Win32 API functions (except the few
that take variable arguments) use it.
And from that, this is what I have understand, ALL THE VC++ MFC FUNCTIONS USE __stdcall as their calling conversions.
And CALLBACK is defined as follows....
#define CALLBACK __stdcall
What I have read:
Preceding a function with CALLBACK is used to emphasise that the particular function will be called automatically whenever necessary(like in this setTimer case or onClick case in javascript),
My doubt is , In MFC VC++ all functions(except the few
that take variable arguments) has a default calling convention of __stdcall. Hence either preceding or not preceding a function with CALLBACK or WINAPI or PASCAL has a same effect?
Is it absolutely necessary for the computer? It depends on the context. When you mismatch the calling convention, you could either get lucky because the datatypes on the stack happen to match the requirements of the API, or it could fail miserably when your code is run on a different architecture like x64 and crashes every time.
Is it absolutely necessary for the maintenance programmer? Yes, it is. You know, the poor person who will have to figure out your non-standard conventions and clever "optimizations." Some day, that poor person might be you.
The compiler was yelling at you for a reason when you tried to subvert the API.