>>We have hundreds of customers, so I can't trust VFP C++ compiler at this time.I just wait for others to test... :)

We've been deploying VFP-Compiled apps since 2010-2011. Works well- we have high volume systems processing millions of HL7 messages without a hitch and complex VFPX user interfaces, ditto. Installation consists of copying a handful of files, though also Chen offers a "Green" option that packs the runtimes and dependencies into a single exe. This is not recommended because it can be tripped up by UAC. OCX needing to be registered is a different issue. What OCX do you need, btw?

>>Maybe Defox + another .EXE, DLL wrapper would be a better solution. What about Refox on Defox protected files?

Honestly: I'd forget wrapper protections for VFP. The issue is that the VFP pcode needs to be in memory in order for the VFP app to run. Once it's in memory, it's easy to hook the app and then to use Refox to deliver project contents. To prevent this, you need to alter the internal app structure. VFP Compiler and Defox both do this. Defox encrypts individual pcode lines that are decrypted briefly on the fly, so you can't just hook out the pcode. VFP Compiler obfuscates and decomposes aggressively and then moves most of the content to a C++ dll, leaving a useless exe for a hacker to hook. Defox has stronger encryption but it is visibly slower, especially in tight loops. VFP Compiler is very quick despite the decomposition/obfuscation, but the aggressive decompilation can require additional STACKSIZE setting.

>>I add dll files too into Molebox wrapper. Isn't that a good protection?

Nope- because you can hook or breakpoint the call to the dll, at which point the VFP app and variable contents can be scooped out of memory.