Re: C/C++ calling convention
On Aug 30, 4:17 pm, "Alf P. Steinbach /Usenet" <alf.p.steinbach
+use...@gmail.com> wrote:
* James Kanze, on 30.08.2010 17:05:
On Aug 30, 11:23 am, Goran Pusic<gor...@cse-semaphore.com> wrote:
On Aug 29, 12:07 am, James Kanze<james.ka...@gmail.com> wrote:
In theory, we really have to start by defining what we
mean by "OS". I'm an old timer---for me, the OS is the
part of the code which has to be executed in kernel mode:
things like COM or the GUI aren't directly part of the OS.
I bet you can beat that, too: OS are software interrupts
that are used to call into... Well, OS :-).
But more seriously, if you take e.g. Telephony API on
Windows, sure, you can use it without COM, but how would
you not consider it a part of the OS?
What is the telephony API? I've never heard of it, and I've
been doing some pretty low level Windows programming lately.
You might look up RAS.
Looks like an in house version of SNMP. In other words, not
really part of the OS (but interacting with it).
And if the name is anywhere relevant, how could you consider
it part of the OS?
In Windows even the GUI is part of the OS. So much so that at
least still in Windows 2000, as I recall, the thread scheduler
interacted with window message loops; you could affect
performance by sprinkling in some window message queue
checking. Since that code reportedly is very very hairy
spaghetti it's probably still that way.
The GUI is a borderline case. Regardless of the system, it does
need some OS support; you can't have just any user process
writing anywhere on the screen (or capturing keystrokes or mouse
clicks that weren't intended for it). From what little I've
seen, it's clear that the boundary between the OS and things
like displaying a button in a window is much higher under
Windows than under Unix (at least Unix with X---I don't know
about Mac). But things like adding a button to a pane in a
Window still aren't really part of the OS. They're part of a
library which uses whatever lower level interfaces the system
provides.
One big annoyance is that DCOM (Distributed COM, sort of
remote procedure calls in a slightly object-oriented way) is
so very much part of the OS that if you stop that service then
the OS reboots.
:-). Well, it's fairly easy to write a program like that for
Unix, at least if you have root priviledges to install it.
(Many of the applications I've worked on, in fact, did this.)
That doesn't really make them part of the OS.
[...]
And of course, as good people here noted, why would you not
consider assembly?
Because Windows doesn't define the assembler level API.
Uh, it does. :-)
That's what an ABI means.
Defining that level.
Yes and no. An ABI does involve defining a number of low level
things, like how struct's are laid out (today---it wasn't always
the case). On the other hand, I've yet to see any Windows
documentation concerning how to call CreateFile (for example)
other than in C.
--
James Kanze