is the C library a wrapper for windows API?

[mastermagrath]

Hi,

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.

Thanks in advance

 

[mastermagrath]

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.

Cheers

 

[Keith Thompson]

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.

Probably.

A C library may be implemented in any way that meets the standard's
specification. On Windows, the easiest way to do this is almost
certainly via the Windows API. On the other hand, some standard
library functions, such as the ones in <string.h>, can be implemented
in portable C -- but the implementation is free to use some
OS-provided service if there's an advantage in doing so.

For more details about your particular implementation, you'll need to
consult your system's documentation and/or ask in a system-specific
newsgroup.

 

[CBFalconer]

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.

Probably, but not necessarily. Whatever that library is, it has to
know things about the existing hardware, and probably the operating
system.

 

[jacob navia]

Hi,

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.

Thanks in advance

All C libraries in a multi tasking OS like windows, unixes
(solaris, linuxes, AIX, etc) use the OS to eventually talk to the
hardware.

Only in embedded systems without any OS, stand-alone C libraries
will talk directly to the hardware.

 

[Richard Bos]

All C libraries in a multi tasking OS like windows, unixes
(solaris, linuxes, AIX, etc) use the OS to eventually talk to the
hardware.

You do not know this. The vast majority obviously do, but you do not
know that _all_ do

Only in embedded systems without any OS, stand-alone C libraries
will talk directly to the hardware.

You do not know this, either. To begin with, there are more kinds of
computers in this world than are dreamt of in your philosophy, Horatio:
some systems are neither embedded nor multi-tasking "like windows,
unixes". And it should surprise nobody to find one that is both embedded
_and_ multi-tasking.

Richard

 

[jacob navia]

You do not know this. The vast majority obviously do, but you do not
know that _all_ do

Please show me a single example where in a multi-tasked
OS, fread/fwrite talk directly to the disk.

Or stdin reads directly from the keyboard

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

You do not know this, either. To begin with, there are more kinds of
computers in this world than are dreamt of in your philosophy, Horatio:

???

What are you talking about?

"My philosophy" ???

"Horatio" ???

I repeat:

Only in embedded systems without any OS, stand-alone C libraries
will talk directly to the hardware.

some systems are neither embedded nor multi-tasking "like windows,
unixes". And it should surprise nobody to find one that is both embedded
_and_ multi-tasking.

Who cares?

I said:

Only in embedded systems without any OS, stand-alone C libraries
will talk directly to the hardware.

*Without any OS*, I said. If there is an embedded multi tasking OS
that eliminates it from the sample.


I think you are just trying to find something wrong desperately and you
do not find it...

 

[Richard Tobin]

What are you talking about?

"My philosophy" ???

"Horatio" ???

It's a quotation. Try Google.

-- Richard

 

[Richard Heathfield]

jacob navia said:

???

What are you talking about?

"My philosophy" ???

"Horatio" ???

He is quoting from William Shakespeare's "Hamlet", Act I, scene V. His point
is that, just because you haven't personally encountered a stand-alone C
library talking directly to hardware on a machine that has an OS, that
doesn't mean such things don't exist.

I repeat:

Only in embedded systems without any OS, stand-alone C libraries
will talk directly to the hardware.

I distinctly remember writing a stand-alone C library for MS-DOS that talked
directly to hardware.

 

[Richard Bos]

???

What are you talking about?

"My philosophy" ???

"Horatio" ???

It means that you are in desperate need of some basic cultural
education.

I repeat:

Only in embedded systems without any OS, stand-alone C libraries
will talk directly to the hardware.

Repeated assertion does not make you right.

MS-DOS, 80s home computers, need I go on? You apparently need an
education in computer architectures, as well.

I think you are just trying to find something wrong desperately and you
do not find it...

If I were, you would certainly make it easy for me to get my fix.

Richard

 

[jacob navia]

It means that you are in desperate need of some basic cultural
education.




Repeated assertion does not make you right.

MS-DOS, 80s home computers, need I go on? You apparently need an
education in computer architectures, as well.




If I were, you would certainly make it easy for me to get my fix.

Richard

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.

Please remember the original question, we are speaking about
"the C library" not some library written in C.

The devices the standard assumes are stdin, stdout, and a clock.

Other devices like streams may be present, and some of the above absent.

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.

 

[jacob navia]

jacob navia said:




He is quoting from William Shakespeare's "Hamlet", Act I, scene V. His point
is that, just because you haven't personally encountered a stand-alone C
library talking directly to hardware on a machine that has an OS, that
doesn't mean such things don't exist.

You are confused. We are speaking about "the C library" not *some*
library written in C.

I distinctly remember writing a stand-alone C library for MS-DOS that talked
directly to hardware.

We are speaking about "the C library", not *some* library written in C.

 

[jacob navia]

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.

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

 

[Richard Bos]

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

*Shrug* It is not my problem that you remember wrong. That _was_ an
option, but only one of them.

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.

Even if we discount writing to screen memory directly (which _was_ used,
regardless of what you may remember), do not confuse the OS with the
BIOS. It was quite possible - rare, but possible - to replace the OS
with another, but keep the BIOS, which was in hardware. I've personally
used a Unix variety, SCO IIRC, which ran on an IBM clone. BIOS would
have been that of a normal International Business Machines PC, but the
OS certainly wasn't Microsoft DOS. (And do note the two different
companies involved in the only setup you remember.)

Richard

 

[Ancient_Hacker]

I distinctly remember writing a stand-alone C library for MS-DOS that talked
directly to hardware.

Richard is correct, if a bit terse.

On the IBM PC it is generally a good idea to use the highest level of
access feasible.

The levels would something like:

(1) Standard C library functions.
(2) Compiler-supplied extended functions.
(3) Third-party libraries.
(4) MSDOS int 21h calls.
(5) BIOS calls (int 10h for video, int 13h for disk, ... )
(6) Direct port or memory I/O.

I've ordered them roughly by portability and cleanliness.

But some aspects of the hardware were not very well supported by 1 to
5, so *many* applications:

(a) wrote directly to video memory, as the standard BIOS or MSDOS calls
were either inflexible, slow, totally bollixed, or a combination of the
above.

(b) Directly controlled the serial port, as there was no support in
MSDOS or the BIOS for high speeds, using hardware buffering, or using
interrupts.

(c) Many apps also wrote directly to the printer port, as the BIOS had
weird timeout and error lockout settings.

(d) Many apps twiddled the speaker control registers to generate odd
sounds.

-----

The disk, however, had pretty adequate BIOS and MSDOS support, so very
few apps talked directly to the disk, except maybe for copy-protection
checks.

---

This continued on into the Windows 3.1/95/98/Me days, as many apps and
tools still had to go directly to the hardware.

With the coming of WIndows NT/2000/XP and the various Unixes, direct
hardware access was made very difficult to impossioble, without having
admin rights to add device drivers or access the kernel.

 

[Richard Heathfield]

jacob navia said:

We are speaking about "the C library", not *some* library written in C.

That's how the discussion started out, but it isn't the claim you made in
the text quoted above.

 

[Michal Nazarewicz]

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

You could talk to disk directly w/o involving DOS.

Please remember the original question, we are speaking about
"the C library" not some library written in C.

There's no such thing as "the C library" as you use it. "The
C library" is only a list of functions and definition what they do.
How they are implemented is up to the compiler (or something) and they
*can* (and *are* in, I believe, many cases) implemented in C.

So now, a C library *can* be implemented in such a way taht it talk to
hard drive directly instead of depending on OS's calls.

Even in MSDOS, no program talked directly to the hardware.

You don't know that. What was said: the fact that you haven't seen
such an application does not mean such app does not exist.

 

[Richard Heathfield]

jacob navia said:

Even in MSDOS, no program talked directly to the hardware.

....except for the ones that did. I wrote a few myself, so I know such
programs exist.

You are just confused.

No, Jacob, you are confused.

When you call the OS with an interrupt that is still an OS call.

Sure. But who said anything about calling the OS with an interrupt? Ever
heard of BIOS? Ever heard of memory-mapped hardware?

 

[Ancient_Hacker]

Most any program that had quick screen output *had* to talk to the
hardware.

The BIOS and MSDOS calls for screen output were, hmm, how to say,
*lousy*.
There was no fast and efficient call to do the obvious thing-- print a
string at a certain location on the screen. If you tried to print to
col 80, you got an automatic scrollup and line feed. If you tried to
print character 7, a fat round dot, the BIOS would map that into a
lousy "BEEEP"!.

So any program that tried to be fast at screen updates *had* to write
directly to the screen. Lesse, just off the top of my head: Microsoft
Word, Microsoft MultiPlan, Lotus 1-2-3, Wordstar, WordPerfect, Turbo
Pascal, IDE and with the runtime CRT unit. Visi-calc. 98% of
applications and games that wanted to do any graphics.

 

[Al Balmer]

You are confused. We are speaking about "the C library" not *some*
library written in C.

Then there's nothing to talk about, since any implementation is "some"
C library, and "the" C library is an abstraction, not associated with
hardware.