64bit DLLs and __fastcall

[Hydronium]

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.

[CommonTater]

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 ... as I've suggested, Microsoft and PellesC extensions are enabled by default, life is simpler and things just go ticking right along. 
 

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.
 

[frankie]

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.

[frankie]

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).
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).

[CommonTater]

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!

 

[frankie]

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?).

[Stefan Pendl]

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.

[frankie]

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?

[Bitbeisser]

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

[CommonTater]

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...

[Bitbeisser]

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

[CommonTater]

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.