Windows Application Programming Interface (API) or simply Windows API, formerly called Win32. It provides services used by all Windows-based applications (32 bit and 64 bit). C/C++ developers can develop apps that run succesfully on all versions of Windows while taking advantage of the unique features in newer version.If you installed Windows SDK, you can find complete documentation of the newest version of Windows API, consists of a lot of stuffs that has been categorized into administration and managemement, graphics and multimedia, networking, security, system services etc. Yes, I will agree with you that is a lot of reusable APIs. No one can master it in short period.
As the most popular kernel deployed in our planet, you must believe the creator of Windows designed it to be used by other people. It must adopts some patterns, styles, conventions, etc. Thats true, Windows has a very consistent API convention that you can master in short period once you know C/C++ language. Let say, if you really understand the mechanism of simple file management APIs (CreateFile, WriteFile, ReadFile) like below,
HANDLE CreateFile(
LPCTSTR lpFileName,
DWORD dwDesiredAccess,
DWORD dwShareMode,
LPSECURITY_ATTRIBUTES lpSecurityAttributes,
DWORD dwCreationDisposition,
DWORD dwFlagsAndAttributes,
HANDLE hTemplateFile );
BOOL WriteFile(
HANDLE hFile,
LPCVOID lpBuffer,
DWORD nNumberOfBytesToWrite,
LPDWORD lpNumberOfBytesWritten,
LPOVERLAPPED lpOverlapped);
BOOL ReadFile(
HANDLE hFile,
LPVOID lpBuffer,
DWORD nNumberOfBytesToRead,
LPDWORD lpNumberOfBytesRead,
LPOVERLAPPED lpOverlapped);
Later, you can simple understand other APIs for memory management. It just about calling another APIs, to manage Windows virtual memory (VirtualAlloc, VirtualFree, VirtualLock, etc) or heap (HeapCreate, HeapDestroy, HeapAlloc, HeapFree, etc). Let the Windows SDK documentation remembers all details of the functions or how to call them. Standard API always has well pre-defined structures for return value and parameters. Its function name has functional convention and easy to remember. Dont worry about that. No one can remember all the contents (even I can, I wont do that) of pre-define header files like windef.h, windows.h, winbase.h, winnt.h, etc. You will become familiar once you use it every day. What we need to remember is its concepts.
As Vista shipped this year, I found that complexities in the n-th layer of abstraction become increased. Starting with simple C function call to Windows API, to wrapper framework like MFC, or VES like WinForm library and WPF. We have a lot of additional namespaces, programming models, paradigms, etc. But again, there must be some patterns that still exists and can not be changed forever because product makers always put compatibility as critical requirement. MessageBox function is still there in Windows API, in such a way we should be able to correlate it with our high level knowledge. Let say I can write a procedure in Assembly language to invoke MessageBox function (dont try at home).
.data
@def_caption BYTE " ",0
.code
pushad
.IF ebx == 0
mov ebx,OFFSET @def_caption
.ENDIF
INVOKE MessageBox, 0, edx, ebx, 0
popad
ret
MsgBox ENDP
In high level language like C/C++, you can also call it.
#include <windows.h>
// change the int to PASCAL, WINAPI, WINAPIV
int WINAPI WinMain (HINSTANCE hInstance, HINSTANCE hPrevInstance, PSTR szCmdLine, int iCmdShow)
{
MessageBox (NULL, TEXT ("Compile me in Windows 95, 98, 2000, XP and Vista !"), TEXT ("WinMainTest"), 0) ;
return 0 ;
}
But when you are in VES (virtual environtment system), will it still the same MessageBox function called by the following IL codes (I hope you can imagine its C# codes) ?
.method private hidebysig static void Main() cil managed
{
.entrypoint
.custom instance void [mscorlib]System.STAThreadAttribute::.ctor() = ( 01 00 00 00 )
// Code size 13 (0xd)
.maxstack 8
IL_0000: nop
IL_0001: ldstr "Compile me in with ILASM !"
IL_0006: call valuetype [System.Windows.Forms]System.Windows.Forms.DialogResult [System.Windows.Forms]System.Windows.Forms.MessageBox::Show(string)
IL_000b: pop
IL_000c: ret
} // end of method Program::Main
Can you correlate it back to the native Windows API MessageBox? Or just claim that codes calls another API :). Take a look at the following IL codes that I took from MessageBox::Show implementation:
int32 System.Windows.Forms.SafeNativeMethods::MessageBox(valuetype [mscorlib]System.Runtime.InteropServices.HandleRef,string,string,int32)
And when you go to SafeNativeMethods::MessageBox, you will find:
.method public hidebysig static pinvokeimpl("user32.dll" autochar winapi)
int32 MessageBox(valuetype [mscorlib]System.Runtime.InteropServices.HandleRef hWnd,string text,string caption,int32 'type')
Can you guys find the correlation with the following Windows API syntax ??
int MessageBox(
HWND hWnd,
LPCTSTR lpText,
LPCTSTR lpCaption,
UINT uType
);
I know you know that too. One of the biggest problem we have now (and tomorrow) is about correlating our knowledge. This is just a very simple case to show you such kind of problem. I have many other problem around correlating my own knowledge. I love the way Petzold explained it in his book, CODE, The hidden language of computer hardware and software.
Thx - RAM