Share via

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?

Comments

  • Anonymous
    January 26, 2005
    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.

  • Anonymous
    January 27, 2005
    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"?

  • Anonymous
    January 27, 2005
    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.

  • Anonymous
    January 27, 2005
    The comment has been removed

  • Anonymous
    January 31, 2005
    Is there any DOS version?
    I would like MKDIR & RKDIR since FoxPro 2.x DOS (not VFP nor Windows).
    Thanks.

  • Anonymous
    March 15, 2006
    You have excellent and very informative site.

  • Anonymous
    March 17, 2006
    Great information for us users. Keep up.

  • Anonymous
    March 17, 2006
    You have very curious information site.

  • Anonymous
    April 20, 2006
    Congratulations on your site i like the design very much

  • Anonymous
    April 24, 2006
    I was writing a sample about DECLARE DLL to show some of its features which I implemented about 12 years...

  • Anonymous
    January 16, 2007
    > 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>...

  • Anonymous
    February 26, 2007
    The information I found here was rather helpful. Thank you for this.

  • Anonymous
    March 19, 2007
    <a href="http://moviesdvd.jedo.info/avi-movies-downloads.html">avi movies downloads</a>

  • Anonymous
    March 20, 2007
    <a href='http://tvinternet.jedo.info/canada-internet-tv.html'>canada internet tv</a>

  • Anonymous
    August 14, 2007
    thoughts from a professional developer I do not agree. Go to http://apartments.waw.pl/

  • Anonymous
    January 01, 2008
    PingBack from http://movies.247blogging.info/?p=4760

  • Anonymous
    June 30, 2008
    <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>

  • Anonymous
    June 02, 2009
    PingBack from http://woodtvstand.info/story.php?id=84246