<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class='hmmessage'>I don't think anyone else will commit the error of having multiple calling conventions.<BR>
It's a bad place to be.<BR>
Granted, kernels often do have an unusual calling convention, but that gets wrapped up in something "normal".<BR>
<BR>
> <*EXTERNAL NT386:WINAPI, <BR>> ANOTHER_TARGET:VERY_SPECIAL_CALLING_CONVENTION, ...*><BR><BR>
In practice this will only ever be:<BR>
<BR>
> <*EXTERNAL NT386:WINAPI *><BR>
<BR>
and I am satisfied. :)<BR><BR>
oh, btw, the other obvious:<BR>
> <*NT386:EXTERNAL WINAPI *><BR>
<BR>
or even in general both -- pragms can all be prefixed with a platform.<BR>
In practise, "external" is platform-independent, calling convention is not.<BR>
<BR>
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.<BR>
<BR>
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.<BR>
<BR>
OpenGL is in a similar boat here, except that it seems to be a disproof.<BR>
It appears the Cygwin/X OpenGL functions use __cdecl while the Microsoft ones use __stdcall.<BR>
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.<BR>
<BR>
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.<BR>
<BR>
- Jay<BR><BR>
<HR id=stopSpelling>
<BR>
> Date: Mon, 11 Feb 2008 14:12:03 +0100<BR>> From: wagner@elegosoft.com<BR>> To: jayk123@hotmail.com<BR>> CC: m3devel@elegosoft.com<BR>> Subject: RE: [M3devel] <*external winapi*> silently ignored on all platforms?<BR>> <BR>> Quoting Jay <jayk123@hotmail.com>:<BR>> > Olaf, yes you understand me.<BR>> ><BR>> > I strongly object to calling it SYSAPI however, or pretty much any <BR>> > attempt at further abstraction here.<BR>> ><BR>> > I would consider some sort of qualifier that says when to pay <BR>> > attention, when to ignore.<BR>> > For example using a platform name, <*external NT386:WINAPI*>.<BR>> > This is edging toward "preprocessing" but an incredibly small step.<BR>> > (Even though a big problem with preprocessing is rampant context <BR>> > sensitivity, sensitivity to what the target is, and reparsing for <BR>> > every target, is reasonable, and is how M3 already works.)<BR>> ><BR>> > It isn't the "system" calling convention really, it is just very <BR>> > commonly used by the "OS". The "OS" is just a bunch of .dlls, and <BR>> > many of them happen to use __stdcall aka WINAPI a lot, but not all, <BR>> > and not for all functions. "system" MIGHT be how you call the <BR>> > kernel, but that is different. (calling the kernel is not directly <BR>> > exposed in Win32, "kernel32.dll" is not the kernel, ntoskrnl.exe is).<BR>> <BR>> OK, so it's not system specific, but its system specific that there<BR>> are multiple calling conventions for Windows. However, I'm still not<BR>> convinced that this may affect only Windows systems and no others.<BR>> It may sound academic, but wouldn't it be possible that suddenly<BR>> Apple (or even some new OS player :) comes up with similar distinctions?<BR>> <BR>> I think we shouldn't implement a pragma convention that is usable<BR>> only for Windows, but one that is more generic. If we can just<BR>> extend your example to something like<BR>> <BR>> <*EXTERNAL NT386:WINAPI, <BR>> ANOTHER_TARGET:VERY_SPECIAL_CALLING_CONVENTION, ...*><BR>> <BR>> this would be better.<BR>> <BR>> As for the semantic differences on different target platforms, I think<BR>> we could live with them given that all this stuff is system dependent<BR>> and unsafe anyway, but I'd like to hear the opinion of others on this<BR>> topic, too.<BR>> <BR>> Olaf<BR>> <BR>> > msvcrt.dll uses __cdecl for the most part.<BR>> > Anything that accepts varargs, which is very few functions, uses <BR>> > __cdecl, out of necessity (at least give a "normal" point of view, I <BR>> > did used to use a system where calleee popped varargs...).<BR>> > If you write drivers, a small number of functions are __fastcall.<BR>> > I would rather drop the synonyms and just have __cdecl, __fastcall, <BR>> > __stdcall, than to invent "SYSAPI".<BR>> > However I don't really want to do that, "WINAPI" and the other names <BR>> > are useful for a more literal translation of headers.<BR>> > There is a mix of calling conventions on x86 Windows and there is <BR>> > not really one "SYSAPI".<BR>> ><BR>> > The negative affects of changing the default calling convention is <BR>> > breaking all existing dynamic links where you only rebuild one side <BR>> > and where the calling convention wasn't explicit (all of them). Very <BR>> > very bad.<BR>> ><BR>> > > you'd like to declare the external procedures as WINAPI in general<BR>> ><BR>> > Not quite in general perhaps.<BR>> > But I guess any file for which someone has portable C and it is <BR>> > built for NT386 and anything else.<BR>> > Explicit calling conventions are always reasonable on NT386 and <BR>> > never reasonable anywhere else.<BR>> > The Visual C++ compiler has a command line switch as to what the <BR>> > default calling convention is, and widely used headers should work <BR>> > no matter what is the default.<BR>> <BR>> -- <BR>> Olaf Wagner -- elego Software Solutions GmbH<BR>> Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany<BR>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95<BR>> http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz: Berlin<BR>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194<BR>> <BR><BR><br /><hr />Helping your favorite cause is as easy as instant messaging. You IM, we give. <a href='http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join' target='_new'>Learn more.</a></body>
</html>