>>>There are a couple of others they probably missed too. Let's see: vbscript.dll, jscript.dll, and scrrun.dll are also part of the package.< g > Check out their property sheets.:-)
>>
>>Hmm...I don't know much about this, George, but I tried creating a little .VBS, which ran. Then I renamed wscript.exe & cscipt.exe, and the .VBS won't run, all I get is a dialog trying to locate a wscript.
>
>I'm not sure of all the dependencies, Bruce. In checking the wscript.exe, it doesn't reference any of the three files listed above nor wshom.ocx. Obviously, however, there's some purpose to these files. I'll take a SWAG, however...I'll guess that even without wscript.exe, you could still utilize the WSH from within another application like VFP. The wscript.exe would be used strictly for processing the VBScript and JScript files, while the others would handle the interface with the object from other programs.
>
>If this speculation is correct, it would mean that you could simply delete the wscript.exe and cscript.exe applications, yet maintain the use of the WSH from within VFP.

Except that the script execution .DLL, used to fire off COM components built with script, still is there, as is the MS Virtual Machine and the VBScript engine. Any of these will still leave you open to various forms of script-based attacks.