I've been using the fabulous XrX PortableApps Menu Mod (I hope the additional features will eventually make it to the official version). I have been using the startup/exit functionality as well as the ability to execute VBScripts. I have some custom programs that require writing to the registry, so I wrote a bit of VBScript code to handle this. I created a directory in the PortableApps folder called Scripts
and placed two .vbs files: start.vbs
and exit.vbs
. Using the XrX PortableApps Menu Mod I can execute them when the menu starts/exits. My startup script looks something like this:
Function launch(program) Set objShell = CreateObject("WScript.Shell") objShell.Run program set objShell = Nothing End Function Function reg(regpath) launch "regedit /s " & regpath End Function 'Cycle through all of the PortableApps and search for install.reg files Set fso = CreateObject("Scripting.FileSystemObject") Set AppsFolders = fso.GetFolder("..") For Each App In AppsFolders.Subfolders For Each File in App.Files If File.Name = "install.reg" Then reg File.Path Next Next Set AppsFolders = Nothing Set fso = Nothing 'Start any stuff that needs to be launched launch "..\MyEntunnel\myentunnel.exe" launch "..\PidginPortable\PidginPortable.exe"
The launch function can be used to launch any custom programs (on start up I run MyEntunnel and Pidgin). There is a loop that goes through all of the app folders and looks for a file called install.reg
. If it finds it, it will merge it with the registry. My exit script looks something like this:
Function kill(taskname) Set objWMIService = GetObject("winmgmts:{impersonationLevel=impersonate}!\\.\root\cimv2") Set colProcessList = objWMIService.ExecQuery ("SELECT * FROM Win32_Process WHERE Name = '" & taskname & "'") For Each objProcess in colProcessList objProcess.Terminate() Next Set objWMIService = Nothing Set colProcessList = Nothing End Function Function launch(program) Set objShell = CreateObject("WScript.Shell") objShell.Run program set objShell = Nothing End Function Function reg(regpath) launch "regedit /s " & regpath End Function 'Kill any stuff that probably needs to die kill "myentunnel.exe" kill "plink.exe" kill "pidgin.exe" 'Cycle through all of the PortableApps and search for uninstall.reg files Set fso = CreateObject("Scripting.FileSystemObject") Set AppsFolders = fso.GetFolder("..") For Each App In AppsFolders.Subfolders For Each File in App.Files If File.Name = "uninstall.reg" Then reg File.Path Next Next Set AppsFolders = Nothing Set fso = Nothing
First the script kills some processes that may still be running. Then, similar to the start.vbs, it cycles through all of the app folders searching for .reg
files. However, it searches for files named uninstall.reg
and merges them with the registry. Another thing I was thinking of doing to automate things a bit further for the exit script, is to scan all of the app folders for exe
files and kill them if they are running. Please feel free to use the code and if you have any improvements to make, please share them here. Enjoy!
Since this is designed to change the host machine how is it portable? And if not portable, why is it here?
Ed
The scripts change the registry on startup then change it back when you're done.
Cancer Survivors -- Remember the fight, celebrate the victory!
Help control the rugrat population -- have yourself spayed or neutered!
If you look at the source code for the portable apps here, you'll see that most make changes to the host machine. One purpose of the launcher is to put things back to the way they were, when the app is done.
Admittedly this isn't the same as not making any changes to the host machine, but for most purposes it is "good enough".
The "reg" vbs function above, though, merges a registry file into the registry; I don't see where it is checking first to make sure the .reg file it is merging is actually putting things back the way they were, rather than erasing things or putting things back into some generic state. There is a difference. John's launcher programs do about the same thing, on an app-by-app basis, but they try to record the state of the registry when things start up, and put them back that way when they are finished.
Another problem with vbs scripts is that while the WSH is installed by default on newer machines, it is still not present on a lot of older ones.
MC
Some people have Visual Basic Scripts blocked by default
Things have got to get better, they can't get worse, or can they?
That's why one should do it in JS.
cowsay Moo
cowthink 'Dude, why are you staring at me.'
Are you saying that VB scripts are frequently blocked, but the JS scripts run by WSH are not? That's weird.
MC
Yeah, the code I wrote doesn't do anything to check the registry to put things back the way they were. It is a rather "quick and dirty" way to "install/uninstall" custom apps that are not part of the suite. I looked at ways of manipulating the registry directly with VBScript. I decided that it would be much easier just to merge .reg files. I would have to do things like read an install data file to determine what reg keys will be installed, read the registry to see what keys already exist, determine what type of values they are, save them somewhere, write the new entries, blah blah blah, lots of work. I was too lazy to do that much coding. It is true that a lot of older machines do not have WSH installed by default, but these machines probably wouldn't have the capability to handle USB mass storage devices anyway.