Hi Daniel,


> Why speed? Because everytime I tested alternatives in the past, the performance as always weak against plain-vanilla VFP. Last time I ran such tests, that was for Lianja. And, well, the interpreter was ok (as compared to other current interpreters). But the local db-engine is certainly not in the same league as good ol' VFP. Well that always make me a bit nervous when testing alternatives to fox!

Perhaps Lianja and other products access (read and write, insert, delete and update) the dbf files via ODBC functions,
but VFP accesses (read and write, insert, delete and update) the dbf files directly, with the rushmore technology,
so VFP is faster.


> My real concerns - that could have me switch to alternatives such the brilliant work you made - are:
> - speed,

VFP Advanced 64-bit version = VFP 9.0.0.7423 (SP2) + VFP 9.0 Fixes, it is an unofficial 64-bit service package.
VFP Advanced 64-bit is 100% compatible with VFP 9.0.
so I think it will run as fast as VFP 9, perhaps faster a little.


> - protection against decompilation, sure but this is not essential,
> - 64 bits support of course, since it may matter in the long run.

We have another product VFP C++ compiler, it can convert VFP code to C/C++ code, and then compile the C/C++ code to a FLL file with the Visual C++ Compiler.
Now VFP C++ Compiler is a stable product, and it can compile and generate the Win32/Win64 executable files.


> At this stage I have not fully tested the product. I have not run a C/C++ compiler since 1993 (and that was plain WATCOM for a couple of fll-s). I dislike C. But sure I'd be glad to run a test. What would be wonderful is a documented community-driven review of:
> 1) performance relative TO VFP on a couple of VFP code samples,
> 2) some documented feedback on a significantly complex app that works.

Some friends use VFP C++ compiler to compile their big project, it can run fine.

Best regards.

Chen
2018.5.20