Thanks for the comments.

After obfuscation your Varname becomes just symbols as i@y.x@1 and your code works as expected, so since that POV our implementation is independent of the var names.

The native code generation will be just a switch in our Developer Studio that will generate instead of a .NET Assembly, just a true x86 / arm EXE or DLL or if you want and OBJ (linkable object).

For us, as VFP Developers, that will be the preferred way to distribute our VFP apps to our customers. There are advantages to distributing EXE:

1. Not possibility of reverse engineering or at least so hard like to reverse engineer C++ or C code compiled to native.

2. Better (2x and up) performance than JITTED code. .NET uses JIT compilation to turn your IL code into native code, but the optimizations it performs are very limited. With an Ahead of Time compiler we can perform sophisticated optimizations like those available only in C++ and therefore the exe runs lot faster.

3. Better interoperability with native code. From the external world your functions look like C++ / C functions that can be easily consumed from C / C++ and of course because of that you can use directly external C++ / C code or any other native code with a conforming ABI (Application Binary Interface).


>Samuel, thanks for the response. I'd like to tell you how impressed I am with the concept and the progress of your product. Bravo!
>
>For obfuscation I was concerned more about variable names- eg SCATTER/GATHER MEMVAR, or SCATTER NAME returning an object with defined properties. If you're using those, obfuscation could be a disaster- unless your implementation is in fact independent of the variable/property names.
>
>Also I'm impressed by compilation to assembler. Can you tell people here how that would be used?