API basics

Basically, an API(Application Programming Interface) is a set of routines that allows an application to interface with a low-level system. That system could be the operating system, but it could be a database system for instance. For example, the Win32 API is made of kernel32,user32 and gdi32(to access the routines you have to link with the corresponding dlls). Kernel32 is used for basic operations, like memory,file,thread or processes management. User32 holds other system routines(like creating and handling windows) and Gdi32 is a graphics API. I'm not sure I understand your second question, yes the applications are "fed" to the CPU, but how are you going to write to a file for example if you don't have access to the API?

There are other APIs as well, for example OpenGL(for 3D graphics) or DirectX(3D graphics,sound,networks,generally everything you need to make games). OpenGL is cross-platform, Win32(obviously) and DirectX work only with Windows.

As for the GUI, of course you can create your own. It's fairly complex to get into details, but you can override the message handlers to alter the behaviour of controls, or even create your own custom controls. There are API calls that allow you to do that.

As for writing an API, first of all the most proper word is "designing" it. The implementation is another thing. Anyway, it does requires skills because you must be able to know how things work under the hood.

You're on the right track. An API isn't really a tangible entity, though. No language out there rigidly defines an 'API' construct. The term itself is simply a concept: it's something that provides an interface to some (potentionally complex) piece of functionality. Which is why it's called an Application Programming Interface: an interface that an application can be programmed to.

APIs typically wrap complex libraries in an application-programming friendly way. It hides all the icky details of how something works, which leaves the application programmer to only worry about how he's going to use that functionality. For example:

Most graphics libraries provide a DrawCircle function of some sort. To use it, all the app programmer does is write 'DrawCircle(x,y,radius)', and he gets a circle on the screen. He doesn't have to worry about the math behind drawing circles, or even how to draw to the screen.

Getting a little more concrete, an API is just the collection of functions that a library makes available to the users of that library (sometimes referred to as the 'exposed' functions). The library probably has many times more functions that it uses internally, but the app programmer need not worry about them. So basically any time you make a library of code, you're creating an API. Making that API *good* (read: useful) is another story altogether.

Now in general each library has it's own API. There are some APIs, however, that are designed to be implementation-independant. OpenGL is an example of this: when I'm using the OpenGL API, I may be running on an NVidia card, or ATI, or even on a card that doesn't have any 3D support. As an app programmer I don't care: OpenGL says that when I call this function, the video driver will make it happen. I don't care how it gets done, as long as it gets done right.

In summary: an API is simply a set of functions that a programmer uses to access the functionality provided by some library. It's hide the implementation details , freeing the programmer to think about usage instead.

Now to your questions:
1) As I said before, you're on the right track.
2) APIs hide the nity-gritty details from the programmer, and the OS API is just one instance of an API. How the compiler/runtime details with it is just another detail the programmer doesn't have to think about (most of the time).
3) I mentioned that some APIs are designed to be implementation-independant. It's all a matter of whether or not there's a need for a generic API for a common set of functionality. Being able to design a good API is a whole seperate skill-set from programming, but like more programming is just a matter of practice and study.
4) A GUI is just a library, and as a library it needs an API so programmers can use it. There are implementation-indepedent GUIs out there, but the Windows API is not one of them.
5) The Windows API is technically referred to as Win32, and is a horrible mess of various OS and non-OS functionality cobbled together over the years of Windows evolution. Win32 is a set a functions to interact with the OS, which includes a event-based message system (the message loop).

I'll stop here for now and see if this helps you any.

well i'm not really an expert on this but let me try to answer you in a way i understand Graphics API's like Direct and OpenGL works...

1. Different GPUs (like nVidia FX and ATI Radeon) have their own instruction codes for performing rendering activities such as pushing pixels into screen, managing graphics data stored into its video memory, performing advance graphics features such as lighting and shading, etc...For your application to be able to run and use the power of all those GPUs, your application must have instruction codes written specifically for each of those GPUs. As game programmers, it will be very difficult to learn and handle all kinds of GPU instruction codes and write rendering routines of different versions to cater all of them. worse, every time there's a new video card out in the market, you will need to update your source code to be able to run your application using the new video card.
this is where Graphics API comes in. It serves as an "interface" between your application codes and different GPU instruction codes, thereby making it transparent for your application to handle communication with different GPUs.
Say a function in API called Blt() actually pushes graphics data stored in video memory into video screen. Each GPUs handles this process differently, but you don't have to worry about that because specific instruction codes needed to perform Blt() function on different GPUs is already managed by the API.

2. The CPU performs all mathematical functions and processes called by your application. But the GPU handles "all" rendering routines called by your application. The presence of GPU is to be able to perform rendering much faster. if you let CPU do all the things then your system's gonna get choked.
** note that when you call a rendering routine that the GPU cannot handle, the API will then let the CPU perform that routine. this can be very slow **

3. DirectX API is platform-dependent. OpenGL is much more flexible. a basi knowledge in C/C++ is needed to be able to use the above mentioned APIs.

4. you can write your own GUI library using any of the above mentioned APIs.

5. Windows API is a set of libraries that stores functions you can use to write programs in windows. say for example, rendering a window frame. during DOS days, writing a simple routine to store graphics data into memory and push them into screen takes hundreds of codes (can be thousands). On windows API, all you need is a single function to do the thing, and this is available in the library (GDI library to e exact).

I hope this help you. My answers my not be entirely accurate, so anyone who knows better please feel free to correct me.

mikeman,

Thank you for your response! I think I'm widdling away what my bottleneck is. You see I'm trying to understand something (APIs) as a concept without having much (any) hands-on experience with low-level programming.

Quote:

mikeman : Basically, an API(Application Programming Interface) is a set of routines that allows an application to interface with a low-level system....yes the applications are "fed" to the CPU, but how are you going to write to a file for example if you don't have access to the API?

(1) I'm not understanding exactly what an API is. Is it a design/blueprint? Or is it an actual set of low-level routines? How does .NET automatically attach my program in with the API during a compile?
(2) I guess this is my main problem: there is the source code I write in my .cpp file in .NET. There is the OS that manages my exectuable after compilation. Where and how does the API fit in between them (specifically). It has to exist as some set of functions or source code...but where? And what is so special about its implementation that allows it to interact with the OS? Is it written in asm?

thanks, helmslar

Quote:

Getting a little more concrete, an API is just the collection of functions that a library makes available to the users of that library (sometimes referred to as the 'exposed' functions). The library probably has many times more functions that it uses internally, but the app programmer need not worry about them. So basically any time you make a library of code, you're creating an API. Making that API *good* (read: useful) is another story altogether.

I think you're confusing a little the notion of an API and a library. An API is a set of routines that allow an application to interface with low-level functionality, but definately not the same as a library, although libraries(and drivers) are used of course to make the interaction possible. And certainly it is not the case that any time you make a library, you're creating an API. If I make a library with math routines, for example, that is definately not a "math" API, because you're not providing access to any existing functionality.

morbo and harmless - thank you so much. you both finally helped fill in the 'missing link' in what I wasn't understanding. I have to run to work, but just for reiteration:

Any library that has exposed functions therefor has an API. It may have a multitude of other functions but they are for internal purposes only, and are almost guaranteed to be written in asm or some other low-level method.

One final question remains in this conceptual mystery: if I wanted to make my own set of "low-level" routines to communicate directly with, say, my OS or even a hardware device such as a drive or graphics card:

(1) What skills would I have to learn to accomplish this?
(2) Would the concept be such that: I would design my low-level routines to make calls ("invocations") to the OS's or device's API functions?

thanks for all your help

Quote:

(1) I'm not understanding exactly what an API is. Is it a design/blueprint? Or is it an actual set of low-level routines? How does .NET automatically attach my program in with the API during a compile? (2) I guess this is my main problem: there is the source code I write in my .cpp file in .NET. There is the OS that manages my exectuable after compilation. Where and how does the API fit in between them (specifically). It has to exist as some set of functions or source code...but where? And what is so special about its implementation that allows it to interact with the OS? Is it written in asm?

1)API is just that: a set of routines. You can view it as a "system" that handles system resources. For example, memory management in Windows. You can't have direct access to memory, so the guys in Microsoft designed a set of routines that allows you to do that. One routine is GlobalAlloc(). When you call that, Windows create an object in memory and returns you a "handle" to this object. When you don't need that object, you call GlobalFree(), passing as parameter that "handle", and Windows deletes that object. You see, you can view this system as a working mechanism totally indendently from its implementation. Of course, in order to actually work, an implementation is necessary, but you don't need to know how it's done.

2)That's not so hard to understand. Let's take again the previous example. In your source file, you #include , right? That's were the declaration for GlobalAlloc() is. Note, only the declaration, not the actual code. That is, lets the compiler know the name of the function, and the number and types of parameters it uses. So, the code of this function is not in your code, so where is it?

Well, if you check your projects settings, you'll see that your program links to "kernel32.lib". When your program runs, a dynamic library named "kernel32.dll" is loaded into memory(actually, because it's a system dll, it is already loaded). The code for GlobalAlloc() is there, let's say in address 0x4FFFFFFF. "Kernel32.lib" helps your linker to define exactly that, the address of this function. Since the linker knows all that, it is capable to create the executable and access this function.

As what is so special about it... Without getting into details, the memory exceeds from 0-4GB. Note, we're talking about a virtual address space, not your physical memory(in case you say "but I don't have 4GB of RAM!"). Anyway, the first 2GB are reserved for use by applications,and that's where your application gets loaded. The last 2GB are reserved for use by the system, and that's where kernel32 gets loaded. Kernel32(and other system dlls) runs in "kernel mode"(ring 0 code), that means it can use "privileged" assembly instructions that allows it to interact with the hardware.

Your application runs in "user mode", that means you can't directly access hardware. You could write assembly code that has those "privileged" instructions, but the processor would just ignore it, because your application runs in user mode. That's why you need the API.

And:

Quote:

Any library that has exposed functions therefor has an API. It may have a multitude of other functions but they are for internal purposes only, and are almost guaranteed to be written in asm or some other low-level method.

No. A library is not an API, it it doesn't have to be written in assembly.