>>>In several places in our application executable we have hooks that call custom, external, encrypted programs whose names are stored in a table.
>>>
>>>Recently, a new custom program needed to USE a confidential free table that is included in the executable, and VFP couldn't find it.
>>>
>>>Is there any way that we can force the external program to look for the table inside the exe file?
>>>
>>>TIA,
>>>
>>>Alex
>>
>>Yes, create a function like DoCmd in your exe, preferably in the main procedure file which is startup at runtime..
>>
>>

>>FUNCTION DoCmd(cCommand)
>>
>>&cCommand
>>ENDFUNC

>>
>>Then you can call the following from an outside PRG
>>
>>

>>DoCmd("USE MyInternalTable")
>>

>
>In terms of security, this approach is a problem. You can do almost anything from that point.
>

>DoCmd("DO my.prg") 
>

>will work too. Instantiate classes? Open forms? Mimic existing stuff into something new? You have full control from that point. See what you can do in terms of compiling and creating at run time. That's huge.
>
>Never ever do that.
>And don't argue nobody knows your structure. This is named security through obscurity.

Hello Lutz,

I agree that macros can open a big hole. For protection, we compile and encrypt all external custom programs (fxp) before storing them in disk to make it more difficult to take control by simply replacing one fxp with another.

We actually have an internal function that does exactly what Walter suggests, but the called macro still does not see the internal table. I expected it would see the internal table, but perhaps

Alex


MyComando("USE xxxx IN 0")

FUNCTION MyComando
PARAMETERS tcComando 
tcComando = TRIM(tcComando)
&tcComando
RETURN

Alex