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

[Tony Hosking]

On Feb 11, 2008, at 8:31 AM, Jay wrote:

> I don't think anyone else will commit the error of having multiple  
> calling conventions.
> It's a bad place to be.
> Granted, kernels often do have an unusual calling convention, but  
> that gets wrapped up in something "normal".
>
> > <*EXTERNAL NT386:WINAPI,
> > ANOTHER_TARGET:VERY_SPECIAL_CALLING_CONVENTION, ...*>
>
> In practice this will only ever be:
>
> > <*EXTERNAL NT386:WINAPI *>

I can live with this.

>
>
> and I am satisfied. :)
>
> oh, btw, the other obvious:
> > <*NT386:EXTERNAL WINAPI *>
>
> or even in general both -- pragms can all be prefixed with a platform.
> In practise, "external" is platform-independent, calling convention  
> is not.
>
> There might be exceptions, where particular platforms require a  
> Modula-3 wrapper. As Cygwin had briefly for semaphore  
> initialization. I guess this really does in general resemble  
> preprocessing, only by target, only of pragmas, and the point  
> really is to limit per-platform branching when the platforms are  
> indeed extremely similar.
>
> This is a common pattern -- if'ing stuff midly, if'ing stuff to  
> heck, vs. splitting out in separate implementation with no ugly  
> if'ing.
>
> OpenGL is in a similar boat here, except that it seems to be a  
> disproof.
> It appears the Cygwin/X OpenGL functions use __cdecl while the  
> Microsoft ones use __stdcall.
> Again the *.i3 files are almost the same, except for calling  
> conventions, but it seems the "NT386 POSIX" variant uses a  
> different calling convention than the "NT386 WIN32" variant.
>
> I am not 100% what is going on in OpenGL. Building "std" for  
> NT386GNU gets at least as far as anim3d, however I haven't run much  
> of the code at all -- only enough of cm3 to see it has a problem  
> with paths... I'm still just using a "regular" NT386 in a sort of  
> cross scenario.
>
>  - Jay
>
>
> > Date: Mon, 11 Feb 2008 14:12:03 +0100
> > From: wagner at elegosoft.com
> > To: jayk123 at hotmail.com
> > CC: m3devel at elegosoft.com
> > Subject: RE: [M3devel] <*external winapi*> silently ignored on  
> all platforms?
> >
> > 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
> >
>
>
> Helping your favorite cause is as easy as instant messaging. You  
> IM, we give. Learn more.