Utility: PScript - Portable Software Script Host

Title

PScript Portable Script Host for Windows, Version 1.0


Description

PScript was developed for use in running "portable" software in conjunction with a launcher utility such as my own PockeTop Portable Desktop. Such software is typically carried from computer to computer on a removeable medium such as a CD-ROM, USB drive, or floppy disk.

Normally for software to run "portably" it should be written and packaged such that it does not need to modify system state on the host computer in order to run. For example such programs should not require COM registration or otherwise alter the system registry.

Often however it can be useful to perform pre- or post-processing around a program run. For example the program and its data might be stored on a USB flash memory drive but you may wish to minimize wear on the device. You could copy work files to the host hard drive before running against them, then optionally copy the altered work files back to the flash drive after ending the program, and finally clean up the host hard drive by deleting the work files.

Using .CMD or .BAT files for this purpose works, but can be clunky leaving console windows open on the desktop. Windows Script could be an answer, but sadly in many portable software usage scenarios such as libraries, cybercafes, and corporate settings Windows Script Host (WSH) is disabled or locked down for system safety reasons.


Features

PScript is a portable script host you can use instead of WSH's CScript and WScript hosts.

It adds a few useful properties and methods to the bare bones of the VBScript and JScript engines already present on the host machine. However PScript does not use any tricks to provide any system access the running user would not already have, and doesn't even offer HKCU registry manipulation.

It should run just fine even when "scripting has been locked down" on the host, as long as the Microsoft script engines are available. They normally would be in order for Internet Explorer pages to host script.

PScript should provide enough tools to suit its intended purposes without even using the WShell and FileSystemObject objects, which are also sometimes locked down along with CScript.exe and WScript.exe.


Author

Bob Riemersma


System Requirements

A host must be running Windows 98 or later with IE 5.x or later in order to ensure that the VB6 runtime libraries and compatible Windows Script engines are available.

Those prerequisites can be installed into Windows 95 as well, but you can't count on them in the wild.

The binaries require under 200KB on any portable media you install PScript to, and installation requires only copying the files and folders involved.

Tested On:

• Windows XP 32-bit SP 3
• Windows Vista 32-bit SP 2
• Windows Vista 64-bit SP 2
• Windows 7 32-bit RC

License Info

The PScript program and it documentation are copyrighted by the author. Permission is granted to anyone to reproduce, distribute, or use these items as long as the Copyright notice is not removed. Permssion is further granted to anyone to create derivative works as long as the original author is credited.

No warranty of fitness and safety, or offer of support should be inferred. This is "as is" software to be used at your own risk.

As always, you should run a virus scan before using this software after downloading it.


Additional Comments

Scripting

Writing scripts for PScript is done using standard VBScript or JScript. Since this isn't WSH, and you may also not be able to rely on the Microsoft Scripting Runtime (FSO, Dictionary) or Windows Script Host Object Model (WshShell), PScript provides an object model of its own.

Most of the object model concerns itself with copying and deleting directories and files and running an application "wrapped" by the script.

This object model is documented in the enclosed PScript.rtf writeup.

PScript is not meant as a general purpose WSH (CScript, WScript) replacement. But if you need additional tools for your portable app scripts you can always extend PScript.

Programmers

The PScript source may prove useful to programmers who want to produce their own specialized script hosts.

Note that LinkCDRun.vbs modifies PE header of EXE/DLL/OCX which renders PDB debug-info files checksum mismatching. WinDbg compains about "mismatched symbols" which can be fixed with simple .reload /f /i (last option meaning ignore). If using dbghelp.dll at run-time SymSetOptions should be called with SYMOPT_LOAD_ANYTHING (&H40) bit set.

Wish PScript's dependence on msscript.ocx could be removed in future versions.

cheers,
</wqw>

I'm not sure why shipped software would have debugging symbols anyway. An alternative might be to use one of the IDE add-ins that hooks the running of C2.EXE and LINK.EXE to supply the SWAPRUN option though.

I don't think the underlying script engines can be used by a VB6 program without msscript.ocx as an intermediary. But the Reg-Free COM manifest makes it a moot point. Unless you're trying to emplace a virus having your program consist of more than one file isn't an issue. After all, distribution is usually done using zip, cab, msi, or similar files.