Undocumented APIs and 16 bit DLLs

  • Article

As a long time software company, Microsoft has certain procedures to follow when releasing software to the public. A change to the policy was instituted at Microsoft last year. A brand new tool would scan all released software to see if any “undocumented” APIs were called.

Apparently as a result of all the legal wranglings this company has been through, if VFP used any API in the operating system that isn’t documented, then that’s an unfair competitive advantage: we’d be using features that other software companies are not privy to.

So I ran the tool: it takes as input all files that will be shipped and scans the binaries (EXEs, DLLs, etc) for all external calls that they make. Some of those calls can be to the OS, others can be to other VFP components. Apparently, if any of the external calls found are not documented in MSDN, then they are flagged as questionable.

Because it’s a new tool, there were some kinks to work out. Some of the results were quite interesting.

Customers Value Backwards Compatibility

The Intel Pentium can trace its roots evolved from: 80486->80386->80286->8086->8085->8080->8008->4004. My first experience with Intel was in 1979 with the 8080. The registers evolved too:

8 bit A,B,C,D ->

16 bit AX, BX, CX, DX ->

32 bit EAX->EBX->ECX->EDX

Thus programmers were somewhat familiar with the newer architectures when upgrading.

One of VFP’s main selling points is its backwards compatibility. You can run a DOS Fox 2.0 application that was written 15 years ago in VFP 9.0. It may look funny because of DOS light bar menus and monospaced fonts in a Windows world, but it still works. More importantly, our customers can run the new version and feel right at home, running their existing apps and using their existing data. We bend over backwards trying to enhance the product, yet maintain compatibility.

Fox has been shipping Foxtools.fll (which is really a DLL) for over 15 years. (Wow: try this link: https://www.foxtools.com ) It was written with the Fox Library Construction Kit, which allows VFP to call C/C++ code. It hasn’t been enhanced much since the early 90’s, since the DECLARE DLL command allowed easier access to calling DLLs and COM became a better way to call components.

That means there is some very old code shipping in VFP 9. In particular, there was code that I wrote that was part of Foxtools that allowed users to call 16 bit DLLs. Back a decade ago, many customers had a need to call into OS and other DLLs. If you recall, these were all 16 bit DLLs, which means the CPU had to switch to a different mode to run the code in them. I used 2 techniques to allow a 32 bit program like VFP 3.0 (circa 1995) to call 16 bit DLLs:

  • Dynamic Data Exchange, which is a message based technique for application communication
  • Universal Thunks. A web search turns up several references, including from KB articles

Foxools RegFN and CallFN called my thunking code called UTRegister and UTUnregister to do it’s work. These APIs aren’t in current versions of MSDN, but can still be found in Win XP: Kernel32 exports them:

 

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

        849 350 00070EE3 UTUnRegister

 

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

        848 34F 000592CA UTRegister

Here’re their function signatures

typedef BOOL (WINAPI *lpfnUTREGISTER)(

            HANDLE hModule,

            LPCTSTR lpsz16BITDLL,

            LPCTSTR lpszInitName,

            LPCTSTR lpszProcName,

            UT32PROC *ppfn32Thunk,

            FARPROC pfnUT32CallBack,

            LPVOID lpBuff

);

typedef BOOL (WINAPI *lpfnUTUNREGISTER)(HANDLE hModule);

(I remember writing the 32-16 bit communication code and testing it for all the different parameter types: float, double, string, etc. I was living in Honolulu at the time, working as a contractor to Microsoft.)

So I told the APIScan folks and they told me that the Windows folks didn’t want to document these. I don’t blame them: they’re probably not used anymore. But that means VFP is calling undocumented Windows APIs and thus has an unfair advantage over competitors<sigh>

In the end, I just removed these calls from Foxtools, which means you won’t be able to call 16 bit DLLs any more.

Does anybody remember using these foxtools functions to call 16 bit DLLs?