[M3devel] <*external winapi*> silently ignored on all platforms?

[Olaf Wagner]

Quoting Jay <jayk123 at hotmail.com>:
> Olaf, yes you understand me.
>
> I strongly object to calling it SYSAPI however, or pretty much any   
> attempt at further abstraction here.
>
> I would consider some sort of qualifier that says when to pay   
> attention, when to ignore.
> For example using a platform name, <*external NT386:WINAPI*>.
> This is edging toward "preprocessing" but an incredibly small step.
> (Even though a big problem with preprocessing is rampant context   
> sensitivity, sensitivity to what the target is, and reparsing for   
> every target, is reasonable, and is how M3 already works.)
>
> It isn't the "system" calling convention really, it is just very   
> commonly used by the "OS". The "OS" is just a bunch of .dlls, and   
> many of them happen to use __stdcall aka WINAPI a lot, but not all,   
> and not for all functions. "system" MIGHT be how you call the   
> kernel, but that is different. (calling the kernel is not directly   
> exposed in Win32, "kernel32.dll" is not the kernel, ntoskrnl.exe is).

OK, so it's not system specific, but its system specific that there
are multiple calling conventions for Windows. However, I'm still not
convinced that this may affect only Windows systems and no others.
It may sound academic, but wouldn't it be possible that suddenly
Apple (or even some new OS player :) comes up with similar distinctions?

I think we shouldn't implement a pragma convention that is usable
only for Windows, but one that is more generic. If we can just
extend your example to something like

   <*EXTERNAL NT386:WINAPI,  
ANOTHER_TARGET:VERY_SPECIAL_CALLING_CONVENTION, ...*>

this would be better.

As for the semantic differences on different target platforms, I think
we could live with them given that all this stuff is system dependent
and unsafe anyway, but I'd like to hear the opinion of others on this
topic, too.

Olaf

> msvcrt.dll uses __cdecl for the most part.
> Anything that accepts varargs, which is very few functions, uses   
> __cdecl, out of necessity (at least give a "normal" point of view, I  
>  did used to use a system where calleee popped varargs...).
> If you write drivers, a small number of functions are __fastcall.
> I would rather drop the synonyms and just have __cdecl, __fastcall,   
> __stdcall, than to invent "SYSAPI".
> However I don't really want to do that, "WINAPI" and the other names  
>  are useful for a more literal translation of headers.
> There is a mix of calling conventions on x86 Windows and there is   
> not really one "SYSAPI".
>
> The negative affects of changing the default calling convention is   
> breaking all existing dynamic links where you only rebuild one side   
> and where the calling convention wasn't explicit (all of them). Very  
>  very bad.
>
>  > you'd like to declare the external procedures as WINAPI in general
>
> Not quite in general perhaps.
> But I guess any file for which someone has portable C and it is   
> built for NT386 and anything else.
> Explicit calling conventions are always reasonable on NT386 and   
> never reasonable anywhere else.
> The Visual C++ compiler has a command line switch as to what the   
> default calling convention is, and widely used headers should work   
> no matter what is the default.

-- 
Olaf Wagner -- elego Software Solutions GmbH
                Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
    http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194