Introduction to the Win32API
  by Sreejath

Foreword
The API programming series is a set of articles dealing with a common theme: API programming in Visual Basic. Though there are no hard and fast rules regarding the content of these articles, generally one article can be expected to contain issues related to API programming, explanation of one or more API calls with generously commented code snippets or bug reports. Depending on the subject, these code samples may expand to become a full-fledged application. 
In this article we'll look at the concept of API as applied to Win32 programming.

Note: This particular article is meant for absolute newbies. If you are even slightly familiar with API programming you might find this a bit slow moving.


So what's API
If you have written programs for the Windows platform using Visual Basic (or Delphi or VC++ for that matter) then you have used the Win32 API, at least indirectly. Because, quite simply, any program you write for windows in VB, uses the Windows API. Each and every line of code you write is translated into corresponding API calls which the system uses to get the tasks done.
API (Application Programmers Interface) is a set of predefined Windows functions used to control the appearance and behaviour of every Windows element (from the outlook of the desktop window to the allocation of memory for a new process). Between them, these functions encapsulate the entire functionality of the Windows environment. So we can consider API as the native code of Windows. The other languages act as an attractive and often user-friendlier shell to the API promoting easier and automated access to it. An example is VB, which has replaced a sizeable portion of the API with its own functions. But every line of code written in VB is converted to its equivalent API calls.


Where does the API reside?
The bulk of the API functions are encapsulated in a set of DLLs - kernel32.dll, user32.dll, gdi32.dll, shell32.dll, etc. These DLLs form the core of the Windows OS and are present on all windows machines (At least the ones that are bootableJ). So unlike when you access a function from a third-party DLL, you don't have to ship anything with your product when you use an API function. The effect this has on the distribution size and speed of your application has to be seen to be believed.


How can we access API functions from VB?
Since these functions are encapsulated within external DLLs they are not available in VB by default. Before invoking (i.e. using) them, we must declare them. Usually this is done in the General | Declarations part of the module in which they are to be used. One important thing should be remembered while declaring API functions within a form module. VB does not allow public Declare statements within form modules. So the Declare statements should be explicitly specified as Private since all object module members are considered Public by default. But this makes them invisible outside the module in which they are defined. So the functions should be declared in every module that needs to use them. Declaring them in a separate .BAS module where they can be declared as Public and are therefore accessible to all the modules eliminates this duplication. This also permits easier maintenance.

Why use the API when I can achieve most of the things I want in VB?
First of all the features offered by (pure) VB are pretty limited when compared to what can be achieved in windows. The recent additions have alleviated this problem somewhat, but the functionality offered by VB is still woefully inadequate in many areas, especially systems programming. Using the API can help you to work around this and would be much simpler than learning a new language.
Secondly, due to its architecture, programs written in VB run slower than their C++ or Delphi counterparts. This is the price one has to pay for easier debugging, simpler coding and a fast development cycle. API being the native interface to Windows is much faster than VB when compared to VB code and since the support files are present in all Windows installations (more about this in the Where does the API reside section) the distribution size is smaller too. So using the API in VB allows one to have the best of both worlds.


What are the cons?
I guess I went a bit overboard in praising the API. Because, for all its advantages, API programming does have some critical disadvantages. 

· First of all there is the learning curve. An equivalent of our simple MsgBox function has parameters that would require the services of a qualified astrologer to make sense of, if you are a newbie.
· It is much less forgiving of programmer errors and it is child's play to crash your application or your system with a malformed API call. And certain API calls when (im) properly used can even render your system unbootable or worse.
· Then, true to Microsoft tradition some API calls do not work as advertised.

Scared? There is no need to be. Just try to understand what you're doing and how to do it properly, exercise mature prudence and lo! You've got yourself a slimmer, faster application doing things that'd make ordinary VB programmers go green with envy.

1 - 2 - 3 - 4 - 5
Back to Tutorials - Main