Hi John,

Thanks for your long thought-out contrib. It is bring a lot of light into the matters of this thread.

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.

>Just one gotcha for any of these techniques that call external fll, dll or exe: they're prime hack vectors since it is trivially easy to hook the called function and pluck any passwords or encrypted items directly out of memory.

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.

I take it that you have a much more robust background in these matters and of course other needs in this respect. But, at the present junction, I cannot invest in compiler understanding and wll rely on third parties for executable codes via executable libraries. 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.

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.

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? That's worrying. At this stage does a monolithic virtual-machine-free executable, à la say Ms-Excel, really help? Should that be the case I'll just discard any security functionality in the package I deliver. This application can certainly live without it.


Daniel