Too lazy to check up on my SWAG ;-)
There was some 16-bit functionality kept in Foxtools from at least FPW2.6, probably FPD as well, and I believe RegFN / CallFN were among those.
If that is true, perhaps they snipped more 16-bit backwards compatibility. Or You could try under a 32-bit version.
Did you set compatibility with XP (dunno if that is still around in Win10)

>This is a notice of a VFP incompatibility I recently found when run on Windows 10.
>
>Some code required calling Win32API functions to get the user's current Screen DPI settings. One way to declare and call the required functions is via the DECLARE - DLL command. One code sample of how to do this is at http://www.spacefold.com/colin/posts/2005/12-01FONTMETRICandScreenD.html .
>
>It is also possible to register, then call Windows API functions using the RegFN() (Register) and CallFN() (Call) functions of FoxTools.FLL. I inherited some code that used this technique. The following code works on Windows prior to version 10, but fails on Win10:
>

>LOCAL lnRelease
>
>* Register the Win32API ReleaseDC() function
>* i.e. release the Device Context when finished with it:
>m.lnRelease = RegFN( "ReleaseDC", "II", "I" )
>
>* Call the function:
>=CallFN( m.lnRelease, 0, m.lnHDC )  && fails on Win10 with "DdeReq failed C 4006"
>

>The equivalent code using DECLARE - DLL is a bit simpler and easier to understand, and when declared and used that way the ReleaseDC() call does not fail on Win10.
>
>I'm not sure when DECLARE - DLL was added to the language, before then it may have been necessary to use the FoxTools functions. In any case the solution seems to be to convert to DECLARE - DLL, at least for Windows 10 compatibility.