>>One thing first I feel the need a durable solution and would discard any unsupported stuff at the moment. Price is not really an issue here. Time yep! The code I am delivering is of course based on VFP and, because of this, subject to obsolescence but all other components are fully supported third parties. And I wish to keep it that way until the time I move the all core glue from VFP to python.. Yes I feel entirely at home in python. Not exactly so in, say, C derived-compilers or java. Cannot explain, just a fact.

Then 7z is a reliable choice. Regular updates, codeset constantly reviewed by inquisitive competent people. 7z also can open heavily compressed files that sometimes cause Windows grief.

As for obsolescence- VFP Compiler allows you to use more recent C++ versions than the default VC7 or even to do away with the runtimes altogether. Even 64 bit versions if that really matters. He also fixed most of the known bugs in VFP9. ;-)

>>As I mentioned, I have stopped using C compilers around 1992-1994 (for fll at that time by the way, no durable use...). My understanding of compilers is C by K&R full stop... and have little intention to get back to C (C++) even less now. Kudos for the VFP compiler! But my tests with it stopped when the thing locked up.

For clarity, you don't need to MAKE yourself or any of that stuff from the old days. Sure there's a command line interface but many people just use the GUI to set your options and then hit the compile button.

>> I prefer to invest into moving the current code base to python (where most of my lib requirements are cared for by the community) than invest in C++ compiler message understanding. That's really one BIG step too far now from my app dev perspective with an already massive (pseudo-code like) code base.

Fair enough- but actually you don't need to invest in C++ day to day. VFP Compiler moves most of your VFP code into the dll where it's harder to hack and if you want to embed additional C++, all you need to do is encapsulate the C++ (or assembly) in a prg. Worth checking out how Chen embeds AES in a VFP prg. He also provides some ASM antihack routines you can embed at will in your sensitive code to give Mr Hacker and his OLLYDBG more of a headache. ;-)

>>You said that any attempt to secure encrypted resources at runtime via external dlls in VFP was at risk to say the least. That's interesting. I do not see how the whole thing could happen outside a full hostile control taken by a third party virus on the machine... But well, that's interesting, and worrying, to hear.

Tools like OLLYDBG even have add-ins for common dlls so neophytes can hook sensitive calls and nose through memory without any preparation. But if you're using VFP there are easier techniques that allow you to recreate the source, including the project file, even if the VFP exe and runtimes are protected inside one of the supposedly excellent walling commercial protection systems. A while back I horrified a certain luminary on Foxite by peeling his VFP code out of a "nanoprotected" exe he was convinced would thwart a hacker. Took less than 5 minutes.

>>Do you feel that the same risk applies to all MS- COM-based communication as well? Meaning that any VFP (or VB) app that would use, say, chilkap zip+AES via COM with a view to bring some AES encryption into the loop would be utterly simple to crack?

If the hacker knows where you're calling, it can be as easy as injecting a debug at that location and simply waiting. That's the joy and hurt of using something popular that's more likely to have its vectors published or even in a hacker plugin. Otherwise you don't need to know much about dll structure to isolate the calls you want to hook.

>>At this stage does a monolithic virtual-machine-free executable, à la say Ms-Excel, really help?

Obfuscation or large volume certainly pushes it towards the "not worth it" end! As you know, if you grant physical access to your exe it can be hacked- so our job is to make the cost of hacking greater than the benefit to be derived. For example, inlining your zip C++ means the hacker has no identifiable hook and has to decompile and review your codebase or step through it. So now your hacker needs to be one of the decreasing pool who can read compiled C++. Usually that's enough for the "too hard" basket. Insert some debugger traps or antihacks and there needs to be a very good reason to persist. But intercepting COM or dll calls? There are "how to" advisories in some of the Chinese BBS and if a password or decrypted string is passed to the call- then it's easily visible to the hacker who has intercepted your call.