Pelles C forum
C language => Beginner questions => Topic started by: Hydronium on December 12, 2012, 04:05:46 AM
-
So, tinkering with DLLs and libs and stuff and I noticed some things:
1) 64bit console programs force you to use the __fastcall calling convention. Why?
2) The 64bit DLL that the wizard creates defines WINAPI as __stdcall. Why not __fastcall?
3) Linking the sample 64bit DLL/Lib with a test 64bit console program gives me a compile-time warning, saying SampleFunction cannot be __stdcall and changes it to __cdecl. Why?
4) Regarding 3) with respect to 1) above, why is it allowed to change to __cdecl if the compiler won't let me manually change from __fastcall?
I can't really find anything about why these things are used (I can find plenty of information about what they do, but that doesn't help me in this case).
Does anyone happen to know? Thanks.
-
Calling conventions comes from the effort to speed up the process of passing parameters.
Substantially you have to consider only two big classis: _cdecl method and all the others.
The _cdecl method pushes all parameters on the stack in reverse order in respect to the declaration (meaning left to right) and it is a job of the calling routine to clear stack after return. The goal of this method is that the caller can supply any number of parameters to allow for that routines, like printf, scanf, etc, that take a variable number of arguments.
Because the pushing and popping of the stack is samwhat slow they wonders about other ways to speed up the process.
So was born the _stdcall, promoted mainly by MS, that push the arguments on the stack like the _stdcall, but clean the stack in the called routine using one fast instruction (LEAVE or RET n).
Moreover to speedup more they introduced the _fastcall where parameters are passed in registers. Because the old IAPX32 architecture had few available registers that was somewhat limited (with 32bits you can pass only 2 32bits parameters in well defined registers, the others will be placed on the stack anyway).
With 64 bits architecture much more registers where available making the use of _fastcall more convenient, so MS decided to adopt it as standard way (for 64bits).
When you write a consolle application, supposedly to be a C99 or C11 compliant application, the default calling convention is _cdecl, while Win-OS API's are write in _stdcall.
That's why the compiler force you to adopt _cdecl convention for main routine (because the runtime call it in _cdecl fashion).
In the end: WINAPI are compiled as _stdcall by MS choice so you must use that convention to call them. Windows general GUI programming should be _fastcall again for MS choice (but you should be able to overryde it). C-standard functions, and most notably variable arguments functions, must be _cdecl and you cannot override them.
Of course if you mix compiled convention and calling convention the result is 99% a program crash for stack corruption.
I hope this clarifies :o
-
In addition to Frankie's well written explaination (Hi Frankie!)....
So, tinkering with DLLs and libs and stuff and I noticed some things:
1) 64bit console programs force you to use the __fastcall calling convention. Why?
This has to do with MS's standardized conventions... 64 bit programs use FastCall...
2) The 64bit DLL that the wizard creates defines WINAPI as __stdcall. Why not __fastcall?
Again this is about MS standards... most of their libraries are written with StdCall.
Also note that the Wizards in the new Project dialog are only examples, for use by beginners. Most of us use the empty project set.
You may want to take a look in the AddIns section, read the FAQ and then install the Workspace Manager (http://forum.pellesc.de/index.php?topic=4616.msg17675#msg17675) addin which is designed to allow a more flexible organization of workspaces and projects.
3) Linking the sample 64bit DLL/Lib with a test 64bit console program gives me a compile-time warning, saying SampleFunction cannot be __stdcall and changes it to __cdecl. Why?
MS Standards again ... Entry points are always CDecl ... which has to do with who cleans up what mess on the stack afterwards. (As Frankie explained)
4) Regarding 3) with respect to 1) above, why is it allowed to change to __cdecl if the compiler won't let me manually change from __fastcall?
Again, it's the conventions talking ... FastCall is the standard for 64 bit programs and is the only one used by the 64 bit compiler. You can change this setting outside the IDE, but be ready for things to get ugly if you do...
I can't really find anything about why these things are used (I can find plenty of information about what they do, but that doesn't help me in this case).
Does anyone happen to know? Thanks.
It pretty much comes down to decisions made by other people....
Sometimes you just gotta play along :D
-
Again this is about MS standards... most of their libraries are written with StdCall.
Also note that the Wizards in the new Project dialog are only examples, for use by beginners. Most of us use the empty project set.
So does the Pelles C compiler ignore the __stdcall calling convention if it appears in a 64bit DLL, and replaces it with __fastcall?
And if so, (out of curiousity) why doesn't the wizard define it as __fastcall from the start, given that it's a 64bit DLL? Or is it merely following the Microsoft practice?
Also, I assume I am free to declare __fastcall as the calling convention in DLLs I may make?
MS Standards again ... Entry points are always CDecl ... which has to do with who cleans up what mess on the stack afterwards. (As Frankie explained)
I'm not sure I follow you here. SampleFunction is not the entry point, DLLMain is. Are you talking about the DLLMain entry point being __cdecl? And if it is, do you mean that every other exported function must follow the same calling convention as the entry point? (Which I didn't think was the case, but again, I'm new to this DLL stuff).
Again, it's the conventions talking ... FastCall is the standard for 64 bit programs and is the only one used by the 64 bit compiler. You can change this setting outside the IDE, but be ready for things to get ugly if you do...
If I understand what you mean: the compiler knows what it is doing, so it changes the __stdcall to __cdecl instead of to __fastcall (even though I think in the end __cdecl is ignored by the compiler and __fastcall is used, from what I've read), but I am restricted to __fastcall in the compiler options to prevent me from messing around (because the compiler is smarter).
This was not meant to sound in any way sarcastic, I'm just trying to figure out the rationale between the calling convention conversions the compiler tells me it is doing which go against the user restrictions it is imposing on me. On the other hand, does the __fastcall calling convention option in the compiler options merely indicate the default convention to be used by function definitions/declarations that don't explicitly state one?
It pretty much comes down to decisions made by other people....
Sometimes you just gotta play along :D
Sounds about right. On the other hand, I would certainly like to know (even just a little) how Pelles C is implementing these conventions/decisions, and why. I just found it odd that everything I've seen regarding the sample DLL, etc, was everything other than __fastcall, and the compiler then changed it something that was still not __fastcall.
Thanks to you & Frankie, though the "why" is still haunting me a bit. :P
-
Sounds about right. On the other hand, I would certainly like to know (even just a little) how Pelles C is implementing these conventions/decisions, and why. I just found it odd that everything I've seen regarding the sample DLL, etc, was everything other than __fastcall, and the compiler then changed it something that was still not __fastcall.
Thanks to you & Frankie, though the "why" is still haunting me a bit. :P
The "Why?" question is very simple... Because that's the way they decided to do it.
Seriously... it's no more complex than that.
I make these same decisions a hundred times a day when writing code... Is do-while better than while in this case? Should I error trap this? Do I need an exception handler here? etc. They made decisions about how DLLs would be called. If we want our software to be interoperable with other software, we play along. Do remember that not every DLL is for use only with our own code ... The AddIns we write for POIDE are a perfect example; if POIDE can't call the entry point, it can't load the DLL.
The thing to understand here is that C stores variables --ints, structs, arrays etc-- in the executable module's stack. When these variables are created the stack is no longer as the calling function left it. Some clean up process is going to have to happen when a function exits or the program is going to crash.
Why _cdecl at entry points? Because in CDecl convention the calling process is responsible for cleaning up it's own stack space... DLLs have their own separate memory segments --thus their own stacks-- and cannot reach into the calling program to clean up when returning... CDecl lets the caller do it.
Why _stdcall for exported functions? Because you want the parameters passed to the DLL's function to end up in the DLL's stack... requiring the DLL code, not the caller to clean up when returning from a function.
_fastcall may seem an ideal answer to that --values in registers and all that-- until you realize that some functions pass 10 and 20 parameters, many of which are still pushed to the stack when fastcall falls back to stdcall. For an example of "too many parameters" check out the CreateWindowEx() function...
Now you are faced with a simple "square peg <-> square hole" problem... so you play along.
Oh, and ....
For the question of the compiler being smarter than we are... Yes sometimes it is.
But in this case we can both be ceratin the compiler writer (Pelle) is...
-
I'm sorry I don't have a 64bits machine to check (for me 32 is still enough), but I also think that there is something strange if things moves as Hydronium says.
I stated that, because PellesC try to be as much compliant with MS as it can, it follows MS standard definitions.
But you should be able to override calling convention or whatever everytime you want. Behind the scene there is a generic C99-C11 compliant compiler after all, not an OS specific one.
Compiler apply forcing only if you don't 'explicitely' declare what you want, means that if you declare a function _stdcall in prototype and in function itself it 'must' follow your request.
The _cdeclare must be not overridable only for those C library functions, as the 'main' function, but not for your self defined one.
-
I'm sorry I don't have a 64bits machine to check (for me 32 is still enough), but I also think that there is something strange if things moves as Hydronium says.
In the 64 bit compiler things are a little different, Frankie...
The only calling convention the IDE allows for 64 bit is FastCall.
http://msdn.microsoft.com/en-us/library/ms235286(v=vs.100).aspx (http://msdn.microsoft.com/en-us/library/ms235286(v=vs.100).aspx)
From the Pelles C help file...
FASTCALL calling convention
x86:
The caller will pass the first two arguments which fit into ECX and EDX, and push all other arguments onto the stack before the call (right-to-left). Arguments are only passed in registers if they are of integral or pointer type. The callee must remove any arguments from the stack; an assembly procedure should use the ret n form. The name of a FASTCALL function is decorated as @funcname@numbytes, where numbytes is the total size of all (promoted) arguments to the function. This calling convention is rarely an improvement on X86; use the CDECL or STDCALL convention.
X64:
The caller will pass the first argument in register RCX, the second argument in register RDX, the third argument in register R8, the fourth argument in register R9, and push all other arguments onto the stack before the call (right-to-left). Arguments are only passed in registers if they are of integral or pointer type. The callee must remove the arguments from the stack. The name of a function is not decorated. This is the only calling convention used by X64.
-
Tater, as I said I cannot actually make any check, but if the compiler is really tied to MS diktat is a terrible mistake in my opinion!
Moreover if it is really standard compliant it *must* permit to the user to choose.
-
Tater, as I said I cannot actually make any check, but if the compiler is really tied to MS diktat is a terrible mistake in my opinion!
Moreover if it is really standard compliant it *must* permit to the user to choose.
I agree.
I havent tested from the command line... the restriction is in the IDE... so I can't be 100% certain either.
Does anyone know what Mingw64 or LCC64 does?
-
Maybe the MS extensions in compiler options?
-
Maybe the MS extensions in compiler options?
LOL... good luck writing a Windows program without those!
Just tried that... The restriction is still in force ...
You can specify in code. Just tested this...
void _stdcall test(void) // _cdecl test(void)
{
MessageBox(0, L"This is a test", L" ", 0);
}
// cold start entry point
INT APIENTRY wWinMain(HINSTANCE Inst, HINSTANCE PrevInst, LPWSTR Cmdline, int CmdShow)
{ MSG msg = {0};
test();
return msg.wParam; }
-
It's very difficult to write a WIN program without WIN extensions ...... :D
Anyway the forcing to use MS formats is not a good thing anyway :-\
-
Anyway the forcing to use MS formats is not a good thing anyway :-\
Agreed ... they should be available but not forced.
-
Why _stdcall for exported functions? Because you want the parameters passed to the DLL's function to end up in the DLL's stack... requiring the DLL code, not the caller to clean up when returning from a function.
Ok. But the compiler switches the call to __cdecl, which goes against what Frankie says:
means that if you declare a function _stdcall in prototype and in function itself it 'must' follow your request.
Let me show you some pictures of the compiler warnings i get. Maybe I've been mistaken in my explanation/questions. Note: My DLL works, I just don't understand why Pelles C is so damn adamant about fiddling with calling conventions.
I've had "Enable Microsoft extensions" unchecked. This is a console program, so I didn't think to select it. Checking it removes the compiler calling convention strangeness, but changes main to __cdecl (which is mandatory, so that's fine). Would using a DLL require that option to be selected (I'm assuming not strictly any DLL, but DLLs with WINAPI defined perhaps?)? And what is it about Microsoft extensions that lets Pelles C relax and stop tweaking imported calls, but now it tweaks main?
-
The following is a bit inelligent but I'm not exactly sure how else to approach it,
so please bear with me...
Why _stdcall for exported functions? Because you want the parameters passed to the DLL's function to end up in the DLL's stack... requiring the DLL code, not the caller to clean up when returning from a function.
Ok. But the compiler switches the call to __cdecl, which goes against what Frankie says:
Because the program calling the function *expects* a given calling convention.
This is not mix and match time... it does matter.
My DLL works, I just don't understand why Pelles C is so damn adamant about fiddling with calling conventions.
Because it matters... Really it does!
I've had "Enable Microsoft extensions" unchecked.
Frankly I'm surprised you could write a DLL without Microsoft Extensions... A DLL IS a Microsoft extension... Normal C-99 or C-11 does not create DLLs.
About your attachments...
In the first image it's telling you that your entry point can't be _fastcall ... which is correct. The startup code that calls main() or winmain() expects a _cdecl function...
In the second case, the compiler is warning you that you can't use _declspec() to export functions without Microsoft extensions... which is also appropriate.
I'm sorry but I just don't see what your boggle is...
-
Hmm, didn't realize DLL was a microsoft creation. Seems the extensions would be necessary then. I suppose (in the second image) it can't use __declspec(dllimport) because that's microsoft related, and needs the extensions enabled? I was also trying to highlight the __stdcall to __cdecl in the second picture, not the __declspec, but that's fine.
So it seems the root of the compiler complaint in the second picture has to do with __declspec, and the __stdcall to __cdecl change is just incidental since the real problem is not using the /Ze switch (Microsft extensions).
I think I need to go figure out what Microsoft extensions are all about.
Because it matters... Really it does!
I understand they need to be the same. I just didn't get why (when extensions were disabled) the compiler was changing __stdcall to __cdecl even though the wizard that comes with Pelles C put __stdcall in there, not me. I'm going to guess that it's the microsoft extensions mixup that was involved in this, and I'm going to do what I mentioned above about looking into them before I go farther with this topic. I feel I'm going around in circles because I'm asking the wrong questions/worrying about irrelevant information. Or I just should never have /Ze disabled because everything's clean once it's used.
And don't worry too much, I'm just curious about this stuff. I'm not about to create my own compiler or something. Some of these compiler warnings and the way the compiler is handling things seems a little off, and I'm trying to figure out what understanding I am lacking. If you think you're wasting time trying to explain the workings of the compiler that's ok, since I'm probably wording my questions wrong or not explaining things properly. Let's give this topic a rest for a bit. :D
-
I think I need to go figure out what Microsoft extensions are all about.
In order to make Windows work, Microsoft had to "extend" (read: "Modify") their compilers to do certain things... such as the WinMain() and DLLMain() functions, _stdcall, and a fair bit more. Windows would never have happened without this. Look up the /Ze and /Zx optons for POCC in the help file (Press F1 on your keyboard) and you will find a more or less complete list of what had to be done.
I understand they need to be the same. I just didn't get why (when extensions were disabled) the compiler was changing __stdcall to __cdecl even though the wizard that comes with Pelles C put __stdcall in there, not me.
Because _stdcall is a Microsoft extension, necessary for calling functions in DLLs.
The only calling convention in C-99 and C-11 is _cdecl ... so guess where the compiler went...
(This btw.. is the Wizard's fault for not turning on the MS extensions for you.)
I'm going to guess that it's the microsoft extensions mixup that was involved in this, and I'm going to do what I mentioned above about looking into them before I go farther with this topic. I feel I'm going around in circles because I'm asking the wrong questions/worrying about irrelevant information. Or I just should never have /Ze disabled because everything's clean once it's used.
If you use the Workspace Manager AddIn (http://forum.pellesc.de/index.php?topic=4616.msg17675#msg17675)... as I've suggested, Microsoft and PellesC extensions are enabled by default, life is simpler and things just go ticking right along. :D
And don't worry too much, I'm just curious about this stuff. I'm not about to create my own compiler or something.
If you do... let me know, I've got some real interesting ideas on that topic...
Some of these compiler warnings and the way the compiler is handling things seems a little off, and I'm trying to figure out what understanding I am lacking. If you think you're wasting time trying to explain the workings of the compiler that's ok, since I'm probably wording my questions wrong or not explaining things properly.
No, I don't think I'm wasting my time ... My frustration (trivial as it is) comes from the feeling that I'm just not communicating this to you in an easily understandable manner. (The guts of compilers are a tad complex, if you haven't noticed ::) )
It would probably be a good idea for you to spend some time in the PellesC help file (Press F1 on your keyboard) ... most of what you need is in there.
-
There are some uncorrectness in the points that have come out.
First of all a DLL is not strictly a MS invention, but a dynamik code object that for MS use PE format, for Linux use ELF object format, but exist anyway.
More custom is the way they are loaded in the process space, MS make a call to an entry point that is expected to be something (maybe __stdcall), so it *must* be the samel or you will get in trouble.
About the calling conventions of functions in a library there is absolutely *no restrictions*, you can create whatever you want. I.e. if you want to create a variable arguments function you are allowed to make so.
What is important is that you declare in headers the convention you used, so the compiler can arrange the call. MS created also a way to make distinction on the type of convention addind the so called 'decorations'. That data is used by linker, when attaching the pseudo library during compilation, and by the loader to validate DLL contents before execution while loading library modules in memory.
A consolle program could be compiled without MS extensions, while a GUI program cannot. MS extensions basically allows some custom features created by MS, the most important of these is the use of unnamed structure structure members. Means that you can define a substructure in a structure without giving it a name. This allows to address substructure members like they were members of main structure. Because almost all WIN structures are defined so, this is the main reason for the thousands of errors you get trying to compile without the option.
Anyway I repeat myself: if the use of alternative calling is really not allowed or forced, it is not good at all! maybe it could even configure as a *bug*. I cannot confirm it until I will not have a 64bits machine to play with.
-
Thanks to Timovjl I have took a look to what are the practical conventions with 64bits code, and specifically to what MS says about (see http://msdn.microsoft.com/en-us/library/ms235286.aspx (http://msdn.microsoft.com/en-us/library/ms235286.aspx)).
I should have done it before :'(!
Anyway in plain words MS use only one way to pass parameters on 64bits architecture, the 64bits __fastcall convention.
All other qualifiers, i.e. __stdcall, _cdecl, etc, simply *don't exist!*
So the __stdcall in win api definition should be assumed as just a signpost.
That MS 64bits calling convention allows also for variadic functions, and is, at the end, a real universal convention.
The point is that in other environments they followed, in some sense, the road traced by MS introducing another way (i.e. SYS_V) to pass parameters reducing stack usage (even if, particulary in MS case, that is not completely true because MS force caller to create stack space for register spilling and the standard function epilog force stack push for R13-R14 and R15).
The conclusion is: PellesC is pedantically targeted to MS-WIN, so, like it or not, only one calling method is allowed (MS way).
-
First of all a DLL is not strictly a MS invention, but a dynamik code object that for MS use PE format, for Linux use ELF object format, but exist anyway.
Given that Windows existed years before Linux, I think we can figure out which way that water flowed.
In any case ... for the OP ... just accept that it needs to be done in certain ways and carry on learning!
-
Well first dynamic linking was realized in 1964 in the multics OS and even before, in 1960, something close was introduced in the MCS (Michigan shared Terminal one of the first time shared OS).
Anyway MS borrowed the concept from UNIX (someone remembers MS-DOS overlays?).
-
Given that Windows existed years before Linux, I think we can figure out which way that water flowed.
..., but Windows existed after UNIX, which Linux uses as a base, so Windows and Linux actually are following UNIX.
The equivalent to .DLL files are .SO files on UNIX systems and both are application extensions.
I think that here we have encountered another area where M$ is not following the ISO standard, but forcing its own standards as with HTML in IE.
-
Fully agree Stefan.
Anyway the calling convention should not be defined in the ISO standard as far as I know. The __cdecl, __stdcal, etc are not standard. Am I wrong?
-
Well first dynamic linking was realized in 1964 in the multics OS and even before, in 1960, something close was introduced in the MCS (Michigan shared Terminal one of the first time shared OS).
Anyway MS borrowed the concept from UNIX (someone remembers MS-DOS overlays?).
While "dynamic linking" has been indeed around for a while, I would not say that it "borrowed" anything from Unix in this regards. Dynamic loading ( and the linking of dynamic loadable modules) in Windows works significantly different (and more flexible) than in Unix/Linux.
And DOS overlays aren't the same thing either, specially as each and every compiler is (was) using it's own (incompatible) methods, there was never one unified system provided by the operating system...
So yes, DLLs are a "Microsoft thing" and for that matter, are around more +20 years now (and so is Linux!), it is hard to see that someone doesn't realize that this is something Microsoft (OS) specific and then is surprised that this might come to bear in a Windows specific compiler...
Ralf
-
So yes, DLLs are a "Microsoft thing" and for that matter, are around more +20 years now (and so is Linux!), it is hard to see that someone doesn't realize that this is something Microsoft (OS) specific and then is surprised that this might come to bear in a Windows specific compiler...
Hi Ralf...
The OP didn't know that DLLs are Windows... not C... specific. I think that was the cause of his boggle. He didn't realize that some things only work in Microsoft mode.
We all run into stuff we don't know about. The only real difference here is that with a bit more experience we've learned how to look this stuff up. In time Hydronium will get there too...
-
So yes, DLLs are a "Microsoft thing" and for that matter, are around more +20 years now (and so is Linux!), it is hard to see that someone doesn't realize that this is something Microsoft (OS) specific and then is surprised that this might come to bear in a Windows specific compiler...
Hi Ralf...
The OP didn't know that DLLs are Windows... not C... specific. I think that was the cause of his boggle. He didn't realize that some things only work in Microsoft mode.
DLLs are certainly not C specific, as they can be programmed in almost any programming language in Windows.
My point is still that if someone programs with DLLs that (s)he should know that this is something Windows specific. It always helps to know what/why someone is doing something...
Ralf
-
My point is still that if someone programs with DLLs that (s)he should know that this is something Windows specific. It always helps to know what/why someone is doing something...
Yes they should know... but in this case our friend didn't... It's not a biggy... just took a while to figure out.