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]

"mastermagrath" <po*********@virgin.netwrites:

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.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[CBFalconer]

mastermagrath wrote:

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

--
Chuck F (cb********@yahoo.com) (cb********@maineline.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.netUSE maineline address!

[jacob navia]

mastermagrath wrote:

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]

jacob navia <ja***@jacob.remcomp.frwrote:

mastermagrath wrote:

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.

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]

Richard Bos wrote:

jacob navia <ja***@jacob.remcomp.frwrote:

>>mastermagrath wrote:

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

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

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

>

>>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:

???

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]

In article <44***********************@news.orange.fr>,
jacob navia <ja***@jacob.remcomp.frwrote:

>What are you talking about?

"My philosophy" ???

"Horatio" ???

It's a quotation. Try Google.

-- Richard

[Richard Heathfield]

jacob navia said:

Richard Bos wrote:

>jacob navia <ja***@jacob.remcomp.frwrote:

<snip>

>>>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:

???

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 Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Richard Bos]

jacob navia <ja***@jacob.remcomp.frwrote:

Richard Bos wrote:

jacob navia <ja***@jacob.remcomp.frwrote:

>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:

???

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]

Richard Bos wrote:

jacob navia <ja***@jacob.remcomp.frwrote:

>>Richard Bos wrote:

>>>jacob navia <ja***@jacob.remcomp.frwrote:
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:

???

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

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]

Richard Heathfield wrote:

jacob navia said:

>>Richard Bos wrote:

>>>jacob navia <ja***@jacob.remcomp.frwrote:

<snip>

>>>>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:

???

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.

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

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

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

[jacob navia]

jacob navia wrote:

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]

jacob navia <ja***@jacob.remcomp.frwrote:

Richard Bos wrote:

jacob navia <ja***@jacob.remcomp.frwrote:

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

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]

Richard Heathfield wrote:

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.

----

So if the poor OP was referring to running C on a modern OS, the C
library has no choice but to make system API calls, as the raw hardware
is not reachable from typical user programs.

[Richard Heathfield]

jacob navia said:

<snip>

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

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.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Michal Nazarewicz]

jacob navia <ja***@jacob.remcomp.frwrites:

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.

--
Best regards, _ _
.o. | Liege of Serenly Enlightened Majesty of o' \,=./ `o
..o | Computer Science, Michal "mina86" Nazarewicz (o o)
ooo +--<mina86*tlen.pl>--<jid:mina86*jabber.org>--ooO--(_)--Ooo--

[Richard Heathfield]

jacob navia said:

<snip>

>
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?

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[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]

On Wed, 30 Aug 2006 15:40:24 +0200, jacob navia
<ja***@jacob.remcomp.frwrote:

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

--
Al Balmer
Sun City, AZ

[Keith Thompson]

jacob navia <ja***@jacob.remcomp.frwrites:
[...]

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 (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Keith Thompson]

jacob navia <ja***@jacob.remcomp.frwrites:

jacob navia wrote:

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

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.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Mark McIntyre]

On Wed, 30 Aug 2006 15:38:15 +0200, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:

>Richard Bos wrote:

>jacob navia <ja***@jacob.remcomp.frwrote:

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

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

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]

mastermagrath wrote:

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]

mastermagrath wrote:

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]

"jacob navia" <ja***@jacob.remcomp.frwrote in message
news:44***********************@news.orange.fr...

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

--
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking

--
Posted via a free Usenet account from http://www.teranews.com

[jacob navia]

Stephen Sprunk a écrit :

"jacob navia" <ja***@jacob.remcomp.frwrote in message
news:44***********************@news.orange.fr...

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

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.

>

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

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:

<snip>

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

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[jacob navia]

Richard Heathfield a écrit :

jacob navia said:

<snip>

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

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.

>

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

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]

On Mon, 04 Sep 2006 14:13:34 +0200, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:

>
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