DECLARE DLL performance questions

I was writing a sample about DECLARE DLL to show some of its features which I implemented about 12 years ago, when I rediscovered an interesting performance issue.


The purpose of DECLARE DLL is to allow the user to call functions in a DLL directly. For example, most of the Win32 API  lives in DLLs and thus being able to call the API directly is very powerful.


In order to use the function in a DLL, you needed to know its name and its parameter signature. For example, the GetWindowText function of the Windows API will return the text associated with a Window handle. If the Window handle is a normal user Window, it’s the title of the window. If it’s the Window handle of a button, then it’s the text on the button. GetWindowText takes 3 parameters: the Window Handle, a string buffer to place the answer, and the size of that buffer. It returns the length of the result put in the string buffer.


In order to use this API from VB or VFP, you would need to know that it lives in User32.dll in your Windows System directory (typically c:\windows\system32\user32.dll). Also, there are actually 2 versions of this API, as the windows SDK header file for this API (win32sdk\include\winuser.h) shows:


#ifdef UNICODE

#define GetWindowText  GetWindowTextW


#define GetWindowText  GetWindowTextA

#endif // !UNICODE


In fact, there are 2 versions of most Win32 APIs that deal with strings: one for UNICODE (2 bytes per character) and one for non-UNICODE (double byte (1 or 2 bytes per character) and ANSI (1 byte per character). These header files are how the programmer (almost all were C/C++ developers in the old days) can use the Win32API.


To hide this Unicode complexity from the user, the header file has a conditional #define, so the user just has to write GetWindowText, and the #define macro expands it in the C compiler preprocessor

The UNICODE version appends a “W” and the non-UNICODE version appends a “A”.


That means the actual DLL does not export “GetWindowText”, but has 2 exports: “GetWindowTextA” and “GetWindowTextW”


You can see the two by typing this in a Visual Studio command prompt:

D:\>link /dump /exports c:\windows\system32\user32.dll | find /i "getwindowtext"

        376  177 0000F002 GetWindowTextA

        377  178 0001F1BE GetWindowTextLengthA

        378  179 0000DC5F GetWindowTextLengthW

        379  17A 0000BA08 GetWindowTextW

        402  191 0000C057 InternalGetWindowText


So the user would have to declare GetWindowTextA rather than GetWindowText.

To hide this complexity from the every day user, VFP will try to see if the specified function exists in the DLL. If it doesn’t, a “A” is appended to the function name and the DLL is queried again.

Because of this trial and error approach, one would think that appending the “A” before calling the API would make a difference in performance.


Another complexity arises for Win32 API calls (but not for other DLLs). The user is required to know in which particular DLL of Windows the function resides. Back in the old days, it wasn’t quite as clear. With MSDN online now, it’s pretty easy to see at the bottom of the MSDN topic for the API. The DECLARE DLL command allows the user to just type “Win32API” instead of the DLL name, which means User32.dll, Gdi32.dll, Kernel32.dll , Advapi32.dll and Mpr.dll are searched (in that order).


So the question is which would be faster: specifying the particular DLL name directly, or using “Win32API”?  How about specifying with or without the “A” ?


See also:


What happens if external code throws an exception?

Is there a way in VFP to pass a DWORD to an API function from VFP?

Will GetLastError ever work properly in VFP8.0?

Undocumented APIs and 16 bit DLLs

What external code does your EXE depend on?


Here’s some sample code to get you started. The answer may surprise you!



          DECLARE integer GetWindowText IN win32api integer hWnd, string @ lpString, integer nMaxCout






FOR i = 1 TO 10000


          IF .f.

                   DECLARE integer GetWindowText IN win32api integer hWnd, string @ lpString, integer nMaxCout



                   DECLARE integer GetWindowTextA IN c:\windows\system32\user32.dll integer hWnd, string @ lpString, integer nMaxCout







Comments (13)

  1. Martin Jindra says:

    The command DECLARE API… is slow if  specifying the particular DLL name directly, because VFP must load DLL into memory and locate function’s pointer by function’s name (…and user32.dll has many functions).

    If specify keyword WIN32API the VFP search loaded API functions into memory and because  GetWindowTextA/W() is system function is always loaded into memory.

  2. Timo says:

    Hi Calvin, nice time difference. Using the non-‘A’ version with win32api is 10 times faster.

    I noticed that appending the ‘A’ to the function is indeed faster (5%) than using the function as-is, but using a fully qualified path to the DLL slows it down.

    Might it be that VFP already loaded the win32api DLL’s, so that when we use ‘IN win32api’ VFP looks in it’s own set of loaded functions?


  3. Fabio Lunardon says:

    Calvin, you compare two independent things,

    – dll location

    – dll function


    #IF .T.

    #DEFINE LOOP  300000

    * this is optimized : uses VFP dlls

    #DEFINE DLLFILE win32api


    #DEFINE LOOP  300000/10

    * this open the file : 10x slower. Calvin, you can optimize it too !!!!!

    #DEFINE DLLFILE c:windowssystem32user32.dll



    FOR i = 1 TO LOOP

       #IF .T.


    DECLARE integer GetWindowText IN DLLFILE AS GWT integer hWnd, string @ lpString, integer nMaxCout


    * this is 10% faster

    DECLARE integer GetWindowTextA IN DLLFILE AS GWT integer hWnd, string @ lpString, integer nMaxCout




    ? SECONDS()-nStart


    ? GWT(_vfp.hWnd,@cStr,LEN(cStr)),cStr


    implement the C++ #define with dynamic code

    is a bug for me, because it can produce

    not deterministic calls.


    -the dll XDLL version NN have a function "namefunc" and "namefuncA"

    -the dll XDLL version NN+1 remove the function "namefunc"

    When VFP open XDLL version NN+1 every call

    to "namefunc" is mapped to "namefuncA" !


    – on VFP9 SP2 restrict this "A" feature to


    – because dll declarations are autocorrelated a lot, optimize the IN clause for every dllname

  4. SarekOfVulcan says:

    Calvin, have you looked at your blog in Firefox lately? The formatting is kind of wonky. I have the <a href="">Web Developer</a> extension installed, which lets you edit a page’s CSS on the fly. When I removed the body {line-height: 1.2em} directive, the page looked much better.

  5. In this post DECLARE DLL performance questions I asked whether using the WIN32API keyword or the particular…

  6. I received a comment on this post: Will GetLastError ever work properly in VFP8.0?. &amp;nbsp;I was consistently…

  7. Let’s log all the calls that Excel makes to open or create a file. Start Visual Studio (any version),

Skip to main content