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

[Jay]

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



> Date: Mon, 11 Feb 2008 12:30:37 +0100> From: wagner at elegosoft.com> To: m3devel at elegosoft.com> Subject: Re: [M3devel] <*external winapi*> silently ignored on all platforms?> > Quoting Jay <jayk123 at hotmail.com>:> > > I know this won't be popular but...> > over in m3-db\odbc\src, there is POSIX and WIN32, and they are > > ALMOST identical.> > The differences are> > the UNUSED type SQLHWND is ADDRESS or HWNDThis should just be removed.> > In Win32 all the <*external*> pragmas have WINAPI.> > In Posix, they lack it.> > For this and other reasons, I suggest that all CM3 frontends accept > > but silentlyignore the Win32/x86 calling conventions in <*external*> > > pragmas,similar to what the non-x86 Windows compilers do.> > The other reasons would be the "FARPROC" warning that I already > > cleared up otherwise.> > And anything else minor that comes up.> >> > I know this won't be popular but I REALLY REALLY REALLY believe is > > the right thing.It is a small safe change that will allow a little > > more Modula-3 source portability.> > If I understand you correctly, you'd like to declare the external> procedures as WINAPI in general and let all backends except the> Windows one ignore it. We should not call it WINAPI then, I think;> what about SYSAPI as a general abstraction?> > > A similar suggestion would be to change the default calling > > convention in Modula-3,it would very possibly reduce code size, but > > is very very very much a breakingchange so probably can never > > happen.Better probably would be to a) add a switch for this b) > > extend the .m3exportsor whatnot files to indicate what switch was > > used.> > We shouldn't change the default calling conventions. That is, we should> check very very carefully if there are negative effects of doing this> and how we cope with them.> Until this has been done, we shouldn't change the default calling> conventions :-)> > > A "blanket pragma" might also be good, so that the various *.i3 > > files cansay just to assume __stdcall for the rest of the file > > instead of annotating each functions.> > You're talking about a pragma default for all declarations in a> file, aren't you? I wouldn't object to that, but it would> probably need some compiler extensions, wouldn't it?> > Olaf> -- > 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> 
_________________________________________________________________
Connect and share in new ways with Windows Live.
http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080211/58564833/attachment-0002.html>