Undocumented APIs and 16 bit DLLs

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: http://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



            HANDLE hModule,

            LPCTSTR lpsz16BITDLL,

            LPCTSTR    lpszInitName,

            LPCTSTR    lpszProcName,

            UT32PROC *ppfn32Thunk,

            FARPROC    pfnUT32CallBack,

            LPVOID        lpBuff





(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?


Comments (18)
  1. Gabe says:

    Hmmm, it seems like you could just reference those APIs as legacy/unsupported in MSDN rather than remove the documentation all together.

    While I agree that this will probably not affect many, if any, users…I do think that potentially breaking backward compatibility because someone in another department doesn’t want to document a valid (but old API) is a poor decision. If there is one thing we know for sure, FoxPro apps will be around forever. They’re kind of link the cobol/fortran apps of the PC world.

    Legacy APIs will only increase in the future (especially with Longhorn). I suggest that the "Windows" folks address this by creating a legacy/unsupported documentation category.

  2. Raymond Chen says:

    Universal thunks came with Win32s (wow, remember Win32s?). Here’s some sample code from the KB: http://support.microsoft.com/kb/q125212/

    I think all the docs on 16-bit Windows have also been trimmed from MSDN – does this mean all of 16-bit Windows is now "undocumented"?

  3. Calvin Hsia says:

    Thanks for the link, Raymond.

    Yep: I remember Win32s. It was a subset of the Win32API that allowed 32 bit apps to run on 16 bit Windows 3.11.

    I think Visual Foxpro 3.0 and Microsoft Golf were the first two released products using Win32s.

  4. Rick Strahl says:

    I used RegFn and CallFn quite a bit in Fox 2.x days. I had a whole library of API wrappers for it actually… At the time it was the only way to make API calls. Of course that all got dumped with VFP and DECLARE DLL.

    I’m sure there are a few people out there that have some ancient legacy DLLs they need to call, but hey I figure if you really need it dig out an old copy of VFP and use FoxTools from there <g>…

  5. HCano says:

    Is there any DOS version?

    I would like MKDIR & RKDIR since FoxPro 2.x DOS (not VFP nor Windows).


  6. debt loan says:

    You have excellent and very informative site.

  7. Great information for us users. Keep up.

  8. Bad Debt says:

    You have very curious information site.

  9. Miranda says:

    Congratulations on your site i like the design very much

  10. I was writing a sample about DECLARE DLL to show some of its features which I implemented about 12 years…

  11. Ted Roche says:

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

    You betcha. I had an application that used 16-bit DLLs for faxing and had to do the thunk-thing. I doubt they are still in use and further doubt any remaining client would be updating the app to VFP 9. I’ll let you know, though <g>…

  12. ... says:

    The information I found here was rather helpful. Thank you for this.

  13. thoughts from a professional developer

    I do not agree. Go to http://apartments.waw.pl/

  14. matar_nv says:

    <a href= http://index7.goliok.com >voice lessons cumberland md</a> <a href= http://index4.goliok.com >biracial sex</a> <a href= http://index6.goliok.com >boys teasing calling pretty girls ugly dog bullying</a> <a href= http://index9.goliok.com >universal cheer association</a> <a href= http://index3.goliok.com >show case cinemas in milford ohio</a>

Comments are closed.

Skip to main content