Christof,

>Hi Doug,
>
>>Isn't the simple explanation here that p-code is always going to provide a way to uncompile, given its nature?
>
>It's part of it. There are tools that prevent exactly this, and they do work. You can't take an encrypted EXE and decompile it, if it is encrypted with ReFox level 2, KonXise, etc. But what does encryption help you if anyone could execute code in the context of your application? Code injection is nothing new, but for VB, VC++, etc. it requires that you use DLLs that are loaded into the application's process. And even then you only get access to the process space, but finding all necessary information is still a tough job. Only experienced system developers can do this.

Interesting. I'm thinking that one should make sure that whenever you expose these kinds of potential problem areas you should always wrap them in a security context that is as absolute as possible. I, for one, don't like the idea of someone running code on my machine via macro substitution! <g>


>
>In VFP this is much easier. Just think back to Gerry's and my article about the Report Designer in 1997. The Report Designer lets a user open any table to which your application has access. Working around that requires an FLL, a lot of code and adds a less friendly user interface to the Report Designer.

Right..