Bob,

You can decompile dotNET apps as well, though they use Obfuscation to make that less useful.

It is worth looking at the latest versions of Refox that encrypt and compress your exe. However, for the simple reason that the resulting exe needs to be able to decompress and deencrypt itself in order to run your app, a determined hacker can do it too.

You could apply obfuscation techniques in your app. For a start you can use #INCLUDE to create a set of #DEFINEs that obfuscate variable names - e.g.

#DEFINE lnDiscount c112211221122111212211222221121212212122112211212
#DEFINE lnTotal c112211221112111212211222221121212212122112211212
#DEFINE lcUsername c112211221122111212211222221221212212122112211212

When a prog that #INCLUDEs these #DEFINES is compiled in VFP, every use of lnDiscount, lnTotal etc gets converted to a useless and very difficult to distinguish variable that cannot be decompiled back to your descriptive variable labels.

dotNET obfuscation also typically uses overloading so that multiple methods are renamed as something meaningless like "a" that makes it hellishly difficult to track what "a" is being run... you can achieve something similar in VFP using gofish or similar to rename method and proc names to meaningless similar labels before compiling your distributable. For example - if you have various functions inside procs that call still more procs with embedded functions, renaming as many as possible of the functions to "a" before compiling your distributable means the hacker needs to track the execution hierarchy in detail to see which particular "a" will be executed at any point in code.

Anyway: eventually it gets too difficult for the hacker and simply not worth it. That point is obviously determined by the value of your intellectual property and/or the benefit/kudos/satisfaction a hacker can achieve by succeeding.