Windows API Tutorial - Part One, Page 2
So what exactly is this 'Windows API' thing everybody's talking about?
Well, imagine a truck load of ice-cream. Let's pretend this ice-cream is available in many different flavours -- chocolate, mint and strawberry to name just a few. Then imagine consuming it all.
Sounds nice doesn't it? However, err, it has absolutely nothing to do with the API. Apologies to those who were expecting a rather tasty analogy -- and if I do enter dream mode again, feel free to send a digital <slap> this way.
Now, imagine a truck load of mint-chocolate-chip code. This code allows you to do many different things on a computer. One piece of code allows you to find out the attributes of a file. Another lets you to display a colour selection dialog box. Yet another enables you draw pretty circles on the screen.
Sound interesting? Well, that truck load of mint-choc-chip code is the Windows Application Programming Interface (API).
It's basically a mass of coded Windows features hidden inside a few DLL files. These files are split into three distinct flavours, depending on what the code inside them does:
- User32.dll -- handles user interface stuff
- Kernel32.dll -- file operations, memory management
- Gdi32.dll -- involved in graphical whatnots
These three files are collectively known as the 'Win32 API' -- in other words, the main collection of accessible Windows 95/98 code.
But there are a few other DLL files available too, including:
- Comdlg32.dll -- holds all regular dialog boxes, etc
- Winmm.dll -- does all the groovy multimedia thingies
There are plenty more -- boy, are there plenty more - but that will do for now.
So when someone talks about programming with the Windows API, they mean they're "plugging into" these DLL files and using some of their neat functions.
But why bother? Well, much of the time, these files do stuff that Visual Basic can't even think about. They perform low-level operations you never usually hear about. So when you need special stuff that Visual Basic just can't handle, it's probably time to turn to the API.
And another point -- I've seen continents move faster than certain Visual Basic functions. So although you may be able to perform particular operations within VB, you may find running code through the Windows API a lot faster. Sure, it's a little more work -- but it'll pay off in the long run.
Also, let's say you wanted to add a 'File Open' dialog box to your application. You can either distribute the hefty Microsoft Common Dialog OCX -- or directly access the dialogs via the API. The latter option requires no extra controls and hence reduces the final size of your application! Another advantage!
So you see, taking a geek peek at the API can be a jolly groovy move.
In the next section, we'll discover exactly how long your computer has been turned on via an API 'call' -- something you can't simply do in pure non-API Visual Basic code. After that, we'll move onto more complicated (yet infinitely more exciting!) API wizzy whatnots. And after that? Who knows - maybe THE WORLD!
Muhaha! Muhahahaha! MUHAHAHAAAHAAAA! <ahem>
So what are we waiting for? Let's get those hands dirty!
Page 2 of 6