is the C library a wrapper for windows API?

[Keith Thompson]

Hardware is isolated from the programs by the OS, that
FORBIDS any direct hardware access.

That's typically true. I don't believe it's universally true.
(Doesn't MS-DOS allow direct hardware access?)

And I know this because
that's the definition of an Operating System (OS).

Really? Can you cite such a definition?

Here's what Merriam Webster's Collegiate Dictionary says:

Main Entry: operating system
Function: noun
Date: 1961

: software that controls the operation of a computer and directs
the processing of programs (as by assigning storage space in
memory and controlling input and output functions)

I don't believe that precludes direct hardware access.

 

[Keith Thompson]

I am referring to disk access/keyboard access, not any other access.

If that's what you meant, then you need to write more carefully.

What you actually wrote upthread was:

| Hardware is isolated from the programs by the OS, that
| FORBIDS any direct hardware access. And I know this because
| that's the definition of an Operating System (OS).

The phrase "any direct hardware access" is not limited to disk and
keyboard access; it means *any* direct hardware access.

In any case, the question of whether programs under MS-DOS can perform
direct access to the disk, keyboard, or any other hardware device is
clearly off-topic.

In a typical hosted implementation, there are, or can be, one or more
layers of software between a user program and the physical hardware.
If I call fwrite() to write to a disk file, *something* has to perform
direct hardware access. Whether that something is part of the
"operating system", part of the "C runtime library", or part of the
firmware in the device itself typically isn't an important question,
and the dividing line between them can be vague. As far as your
program is concerned, they're both part of the "implementation", and
all you should really care about is that your bits get written to disk
somehow.

 

[Mark McIntyre]

As far as I remember MSDOS required to set some values in al, then
do some interrupt to talk to the hardware.

Then you remember wrong. I still have my 8086 programming manual on
the shelf and it still tells me how to directly access hardware
devices, without going through the OS. I still have source code for
programmes that did this, and as far as I know they'd still work on a
modern x86, since the same instruction set is still there.

Even in MSDOS, no program talked directly to the hardware. You are
just confused. When you call the OS with an interrupt that is still
an OS call.

The same is the case for CP/M.

You're still wrong. It was just as easy on z80 and similar hardware.
Do you actually have any experience of such environments?

I started off reading this thread thinking Richard Bos had been
unnecessarily harsh on you, but I'm rapidly changing my mind. I find
it had to sympathise people who clever yet too proud to admit when
they're in error.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

 

[Skarmander]

Sorry for the possibly silly question.
Am i right in saying that the C library i use on a windows machine
really utilises the windows API for all its operations e.g. opening
files, printing to the console etc.etc.

Depends on what you mean by "all its operations".

Big parts of the C library can be implemented in a platform-independent way,
and those may use particular calling conventions but not need to defer to
any external API (or only minimally so, as in using a malloc()
implementation that calls such an API). Other parts may be
platform-dependent, but not OS-specific, like the floating-point routines
(frequently, though even here the OS may play a role).

As soon as you're talking OS-specific things, though, the library
implementation will need to depend on the API(s) provided by the OS. This
only applies if the OS is truly an OS, with hardware abstraction and memory
protection, as opposed to something like DOS, which allowed and virtually
necessitated bypassing it. (And to ward off any flames: I will readily
acknowledge that the definition of "true OS" or even just "OS" varies with
the speaker, and that there are C implementations for platforms where there
is no OS as such.)

So yes, in all likelihood, your C library on Windows will ultimately issue a
call to ReadFile() somewhere when you use fread() -- or it might use
MapViewOfFile() and read directly from memory, or maybe it uses the NT API
rather than the Win32 API, but ultimately it stops just at the point where
the OS is managing things.

It is important to keep in mind, though, that it would be a grave mistake to
conclude from this that it's "just a wrapper", and you're better off calling
the API functions directly. Not only is this not logical (since many API
functions are *themselves* wrappers), in doing so you throw away a big chunk
of portability you could have had for free, for no discernable benefit.

If you're programming in C, it's rarely a good idea to call WriteFile() on a
console handle rather than use printf(). The former will only work on Win32,
the latter on a great multitude of platforms (though not all; some systems
may not have any character output facilities).

You should consider the standard library before considering
platform-specific solutions, and even then you should take care to isolate
platform-specific code from platform-independent code. Some additional
discipline is required, but it's well worth it.

Similarly, using an (n)curses implementation for a screen-writing
application may be worth considering over calling WriteConsoleOutput()
yourself, because even if obtaining and learning such an implementation is
more work, your application will be more portable (and you learn how to
write code that works on more platforms). You may not always be able or even
willing to use libraries to increase portability, but it's worth thinking
about it.

And the reason I'm telling you all this when you didn't ask for it is
because I've seen the reverse (gratuitous dependence on platform-specific
facilities) all too often, and *especially* in Win32 programs. It's not
(semantically) wrong, but it's a darn shame.

S.

 

[Skarmander]

Oops, i should have said that i'm reading a book "windows system
programming 3rd edition", and i'm just getting a little confused as to
what the win32 API is.
I know its essentially the 'interface' to windows but when some of the
code snippets in the book use e.g. windows.h and functions such as
CreateFile i'm wondering is it that these are considered part of the
API or again just wrappers.

You're better off asking questions like these in a group dedicated to
Windows programming, like comp.os.ms-windows.programmer.win32, as they have
little or nothing to do with the C language.

That said...
<OT>
....functions like CreateFile() are both "considered part of the API" and
"again just wrappers". CreateFile() is part of the Win32 API. On Windows
NT-based Win32 platforms, CreateFile() is a wrapper around NtCreateFile(),
which in turn wraps around ZwCreateFile(). The latter is a system call in
the kernel itself, but it's inaccessible to user-mode programs. Only
CreateFile() is a Win32 function, and there's rarely a need to concern
yourself with the levels below that.

As a programmer, you typically do not worry about what function wraps around
which (if you're not dealing with a macro outright!), and you simply use
whatever API is suitable for your task. That API could operate on any level;
to you only the abstractions it provides should matter.
</OT>

S.

 

[Stephen Sprunk]

As far as I remember MSDOS required to set some values in al, then
do some interrupt to talk to the hardware.

This is the case for all disk accesses and all input from the
keyboard.

You remember very, very wrong.

DOS _provided_ an API to access files, the keyboard, and the screen, but
you were welcome to bypass all of that if desired and anyone writing
more than "Hello World!" programs did so for performance reasons. You
had to poke at hardware controllers for everything you did, and I still
remember having to hook the video refresh interrupt so that writing to
the screen didn't make it flicker on CGA cards.

Just about the only thing that people still relied on DOS for was file
access, because the hardware was so slow that reimplementing it didn't
matter -- until protected mode arrived and you had to because DOS would
crater if the API wasn't called in real mode, and getting back to real
mode was a monstrous pain involving manipulating the keyboard controller
(a part of which is now integrated into the core for this very reason, a
horrible hack) and triple-faulting the CPU.

Even in MSDOS, no program talked directly to the hardware. You are
just confused. When you call the OS with an interrupt that is still
an OS call.

See above.

The same is the case for CP/M.

DOS provided an API that matched CP/M's almost exactly because MS and
IBM assumed that the vast majority of programs would be ported from
CP/M. If you wanted _anything_ that performed better or did more
interesting things than CP/M offered, you _had_ to talk to the hardware
directly.

If everyone had used the DOS API, MS wouldn't have gone through a decade
of hell trying to get DOS programs to work under Windows; they had to
intercept all of those hardware accesses (for hundreds of different
types of hardware) and translate them into Win16 API calls, and a lot of
the Windows API today is still littered with functions that are
completely illogical but map to how some piece of hardware worked 20+
years ago and is still being emulated in-kernel today.

S

 

[jacob navia]

Stephen Sprunk a écrit :

You remember very, very wrong.

DOS _provided_ an API to access files, the keyboard, and the screen, but
you were welcome to bypass all of that if desired and anyone writing
more than "Hello World!" programs did so for performance reasons. You
had to poke at hardware controllers for everything you did, and I still
remember having to hook the video refresh interrupt so that writing to
the screen didn't make it flicker on CGA cards.

Just about the only thing that people still relied on DOS for was file
access, because the hardware was so slow that reimplementing it didn't
matter -- until protected mode arrived and you had to because DOS would
crater if the API wasn't called in real mode, and getting back to real
mode was a monstrous pain involving manipulating the keyboard controller
(a part of which is now integrated into the core for this very reason, a
horrible hack) and triple-faulting the CPU.

We were speaking of the standard C library.
Accessing the keyboard directly was not so popular as you would imagine,
since made international programs fail. Maybe that's why those programs
never thrived here in France, where different keyboards (qwerty AND
azerty) were used.

As you said, the disk was always accessed with the BIOS interface.
Yes, the standard library was "slow", and many C programmers wrote
directly to the screen video, but in THEIR programs. The C library
used BIOS access.

Anyway, this is off topic here, and what is important is to remind the
OP question in that thread:

Is the C library a wrapper for the windows API, and the answer is yes,
since TODAY there is no direct access to the keyboard, disk, or
video screen without a device driver.

See above.




DOS provided an API that matched CP/M's almost exactly because MS and
IBM assumed that the vast majority of programs would be ported from
CP/M. If you wanted _anything_ that performed better or did more
interesting things than CP/M offered, you _had_ to talk to the hardware
directly.

If everyone had used the DOS API, MS wouldn't have gone through a decade
of hell trying to get DOS programs to work under Windows; they had to
intercept all of those hardware accesses (for hundreds of different
types of hardware) and translate them into Win16 API calls, and a lot of
the Windows API today is still littered with functions that are
completely illogical but map to how some piece of hardware worked 20+
years ago and is still being emulated in-kernel today.

Maybe, but the OP question was about the C library and the OS. In this
case the answer is yes, the C library resolves (eventually) into
OS calls.

 

[Richard Heathfield]

jacob navia said:

Is the C library a wrapper for the windows API, and the answer is yes,

Clearly false. Consider, for example, implementations running under Linux,
MacOS, OS390, etc.

since TODAY there is no direct access to the keyboard, disk, or
video screen without a device driver.

Equally clearly false. My MS-DOS machine still provides such access, for
example. Today.

 

[jacob navia]

Richard Heathfield a écrit :

jacob navia said:




Clearly false. Consider, for example, implementations running under Linux,
MacOS, OS390, etc.

I said,

> Is the C library a wrapper for the windows API, and the answer is yes,
> since TODAY there is no direct access to the keyboard, disk, or
> video screen without a device driver.

"windows API" stays for OS in this case since the OP that was using
windows XP.

Equally clearly false. My MS-DOS machine still provides such access, for
example. Today.

Great. I stand corrected.

Under modern operating systems the C library resolves to calls to
said OS eventually and does not access direcly the hardware.

 

[Mark McIntyre]

As you said, the disk was always accessed with the BIOS interface.
Yes, the standard library was "slow", and many C programmers wrote
directly to the screen video, but in THEIR programs. The C library
used BIOS access.

Newsflash - BIOS is not part of DOS.

Is the C library a wrapper for the windows API, and the answer is yes,

No.

since TODAY there is no direct access to the keyboard, disk, or
video screen without a device driver.

Hm? Is there a device-driver and windows kernel on my fridge and in my
GPS ? I think not, I don't think Windows runs on a StrongARM.

Maybe, but the OP question was about the C library and the OS. In this
case the answer is yes, the C library resolves (eventually) into
OS calls.

This may be true on lcc-win32, but it need not be true generally, and
almost certainly isn't on many platforms. A library writer would be
perfectly a liberty to write a kernel-mode driver that chatted
directly to the hardware without using any OS features. I should
imagine that many library impementations on embedded and small-memory
systems do just that.

--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan