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

[Jay]

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 *>
 
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.
http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080211/ab495358/attachment-0002.html>