[C]How are library functions implemented?

Avichal

There are several useful library functions that I use while I write C programs. Are these functions also C programs?
Since I use stdio.h library for printf and scanf, how are these functions implemented?

Borek

You should be able to find stdio sources just by googling them. Yes, they are implemented in C.

Avichal

To implement printing and scanning functions you need some commands to communicate with the graphics part of the computer right? Are those commands not taught to a beginner in programming because I never encountered any commands like that yet.

I did try to see the source codes but didn't understand them

Borek

I think you are trying to squeeze several different things into one box.

printf and scanf don't need to access anything else but a stream from which they read/write data. This can be all done in simple C.

At some lower level writing data on the screen or to the disk requires interacting with the hardware itself. This is done through the memory dedicated to the hardware (like video memory) and/or I/O space. Dedicated memory can be accessed from C through pointers, but as far as I know C doesn't define a standard way of accessing I/O space (I can be wrong here) and I/O ports access is done through functions written in assembler (and called from C just like every other function).

20+ years ago I would show you some simple examples that you could run from the DOS command line to see how it works, but these times are long gone.

jim mcnamara

Borek -

If you mean calling BIOS interrupts you can do that on 32 bit x86 Linux using LRMI

http://sourceforge.net/projects/lrmi/

With the advent of UEFI (BIOS) and Windows 8 blocking Linux boot without a MS approved key, some Linux desktop folks are rethinking BIOS.

http://www.zdnet.com/blog/open-sourc...d-fedora/11187

rbj

printf() and scanf() are in C, but they call putc() and getc(). the latter two functions talk to the hardware and may or may not be in C. C is pretty low-level, but i imagine the code that transfers dot patterns to the screen for a particular character are in assembly.

long ago when i programmed my 68K-based Mac, i drilled down to the Mac Toolbox calls, it was called DrawChar(c) which transferred the bits of the ASCII character c (whereas the font and font size and style were already defined) to the bitmap of the screen and moved the "pen" over to the right to the position for the next char, and that was in assembly. i think putc() for a carriage return moved the "pen" to the left margin and down one line of text. if the stream was to a file or serial port, then other routines were called.

justsomeguy

VMware player is free, as is (now defunct) Server/GSX, and so is FreeDOS. If you're feeling nostalgic, there's your playground. :)

Borek

On VGA (CGA, EGA, Hercules) card in text mode you don't have to care about dots, you just put the ASCII code into the card memory (I think starting at 0xB800:0000, but there were some minor diffrerences between cards & modes) and it is displayed using card font. Every character is described by two bytes - one is character itself, the other its attributes (colors of the letter and the background, brightness, blinking). So in the text mode there was no need to draw the points.

Things got more complicated in the graphics modes. If memory serves me well, it was still possible to call BIOS to make it draw a letter using the standard font, but I am not sure if it was guaranteed to work, and BIOS calls for graphic modes were notoriously slow, so it was much better to do all the work by yourself. That was not easy due to the way VGA memory is organized (EGA was similar, and I never worked with CGA). To draw a single pixel in 16 color mode you had to switch between memory planes, as the information about a pixel was stored in 4 different places. On the one hand that meant a programming nightmare in 16 colors, on the other - people were getting creative and half of the PC demoscene was using these modes to get effects that IBM engineers never dreamed about

In 0x13 mode - 320*200*256 colors - things were pretty easy, one memory plane and linear addressing of the pixels, as they all fit in one 64k bank. That was favorite mode for many applications. But there was also another 256 colors mode, so called x-mode, that used memory planes. Addressing was much more tricky, but it was possible to use other resolutions, double or even triple buffering, and in some cases x-mode was faster, as it allowed writing to all four planes with one instruction.

All these things required direct access to the memory and I/O ports. I was doing it in Turbo Pascal at the time. Sadly, when my favorite piece of code made its way to SWAG it didn't bear my name on it (http://webtweakers.com/swag/GRAPHICS/0155.PAS.html ). Perhaps this one: http://webtweakers.com/swag/GRAPHICS/0174.PAS.html shows better the combination of memory and I/O ports access we used at the time.

rcgldr

Even in text mode, there are functions to upload a font (a moderate amount of binary data for all 256 characters) to the screen, and in text mode, you can toggle between 25 line, 43 line, and 50 line modes, each of which uses a different font.

Borek

Yes, but they are displayed automatically, so there is no need to play with pixels to display them. We used that quite extensively here, as Polish contains several characters (ĄĆĘŁŃÓŚŻŹ) that are not present in the standard ASCII.

I think in the case of VGA these were just the most common text modes. Technically hardware specification allowed more, although if memory serves me well early VGA cards not always were able to display them. They were tested/optimized for the common modes. That often meant when you set (using ports) for some timing constants different values than the standard ones, hardware was failing. Later VGA models were much more reliable.

I can't check details now. 20 years ago I had a thick book about EGA/VGA programming, but it is either somewhere in the cardboard boxes or was just thrown out, as VGA was first replaced by VESA standard, and later Windows and 3d accelerators rendered my knowledge useless.

AlephZero

If you want to see the complete source code of a library plus a good description of how it works, get the book "The Standard C Library" by Plauger. It's old, and probably quite expensive, but you get nearly 500 pages of text, not just the code and a few lines of comments.