Portable Powershell - Part 2: Roll your own, plus a challenge

Todays Blog entry is going to cover the HOW of how I put together my demos of Portable PowerShell. Tomorrow I'll move back to clearly defining what I'd like to see from Microsoft. But before I get to the full details a little background:


So what's stopping PowerShell or practically anything from being portable? dependence on a particular file structure and the registry. Basically the technique I  "HOOK" apis so that whenever the process tries to call certain APIs (the filesystem and registry ones) the code in memory is changed to jump to custom code instead of the address of the DLL function export where DLL has been loaded. From there custom checks are done to see if its a file or registry setting to do with PowerShell, and if so the code delivers it up, as if it were there, even though its not.

This is a technique that as a programmer I have been doing for a long time. It involves a lot of assembler, historically being able to inject a DLL into a process and in memory rewrite the code, but it works great. The first time I worked out this technique as a programmer was back in the days of windows 95 which wasn't unicode. I made an application that could enable Chinese and Japanese characters on english windows. Effectively I hooked the TextOut API, and if it was a process that had been chosen to say display in Japanese, and the font chosen was one that was chosen for this purpose then I custom drew the Japanese or Chinese Glyph otherwise I just called the real TextOut API call. Another technique when working on VisualJockey many years ago, I wanted to be able to pipe the output on a standalone graphics program into VisualJockey so we could do some video processing on it. The problem is that app drew to fullscreen directX itself, so I had to "hook" the directX apis, so that when it created the surface it didn't make it fullscreen, and when it rendered it rendered to Texture instead of screen, and then some extra code to retrieve what it had rendered. Another Situation was changing a DB backend of an application without the Applications source, *simply* by hooking the ODBC apis (where we also could discover the password used). Another thing I used this technique for was to add some functionality to abandoned freeware that had no source code.

Fast forward to about 2002, Josua Honger , the main architect of VisualJockey, and also the Hippotiser (I could talk a week just about these amazing programs, the Hippotiser has gone on to become a huge sensation powering realtime effects for live T.V, large concerts, events like the nobel peace prize, broadway shows, and the worlds largest audiovisual setup- Love by Cirque de Soliel in Las Vegas)  were wanting to use the engine of VisualJockey to make a demoscene demo , without the copy protection , and in a portable manner (Demoscene demos aren't allowed to install anything), and on top of that not scare the Green Hippo (who recently purchased the VisualJockey engine and didn't want to risk it getting out and reused). We didn't have time to roll our own solution so we found a rather recent product called Thinstall. Thinstall used the techniques mentioned about, but it stored all the files you choose in its own encrypted virtual file system inside one file - Just what we were needing. Thinstall in those days also was cheap enough for us, even though it was a hobby project, but as a young product it didn't quite work fully with our VisualJockey because we used some interesting techniques anyhow, but I did gain a lot of respect for it, and for its author Jonathan Clark. Over the years I've played with it a few times for some hobby projects , but the cost went up and up and I couldn't justify using it.

Fast forward to 2008, the complexities and risks of deploying and configuring applications have become a real pain point for many corporations and an abundance of solutions have tried solving this. Thinstall evolved its PR to target this market - and named it Application Virtualization, and most recently got acquired by VMWARE. (and renamed ThinApp) So now that there was a great beta to try. the scary thing is HOW EASY THIS WAS. I expected that I would have to spend many hours manually tweaking what to include/exclude - setting up the behaviour of the registry virtualization, but I had something done in 20 minutes, pretty much just following a few instructions. and Click next / next /next


So I wanted to make 4 different versions of Portable Powershell

  • Powershell V1 (just powershell, don't include dotnet 2.0 - thus dotnet 2.0 is needed to be installed on a machine for it to work)
  • Powershell V2 CTP2 (just powershell, don't include dotnet 2.0 - thus dotnet 2.0 is needed to be installed on a machine for it to work)
  • PowerShell V1 (include the who dotnet 2.0 so it can run even where dotnet isn't)
  • PowerShell V1 (include the who dotnet 2.0 so it can run even where dotnet isn't)

The Key this is to have a Fresh OS to start from, so that you don't miss any important files , and don't get rubbish either, so the place to build this is most definately in a VM.

So what did i do?

  1. Predownloaded what was needed
    1. XP SP2 install CD
    2. VMWARE THINAPP BETA (plus free beta key)
    3. DOTNET 2.0 redistributable
    4. Powershell V1 for XP installer
    5. Powershell V2 CTP2 installer
  2. Setup the OS in a VM.
  3. Installed ThinAPP
  4. Made a snapshot of the VM
  5. started the thinapp process
  6. Installed dotnet 2.0
  7. Installed PowerShell V2CTP2
  8. Copied over PowerShell Analyzer
  9. Completed the thinapp process , and build the Portable EXE for my V2 with dotnet Portable Powershell
  10. Copied my portable powerShell off the VM
  11. Reverted the snapshot
  12. Repeated the process but for PowerShell V1
  13. Reverted the snapshot
  14. Installed dotnet 2.0
  15. Made a new snapshot
  16. repeated the process but just installing Powershell V1 (to make a smaller less heavy portable powershell that didn't contain dotnet 2.0)
  17. reverted and repeated the process for Powershell V2

There there you have it, 4 different flavors on a Portable Powershell made in just a few hours. I can't give them enough praise for how far Thinstall has come and how easy the process was.

Are there any other options?

Definately! Thinstall is not the sole player in this now "application virtualization" arena. The management , configuration and deployment has been bundled into apps and called "Application Streaming". Citrix added Application Streaming, Symantec has Altiris, and Microsoft bought out SoftGrid. The "streaming techniques aren't typically really portable since they have some sort of agent or client/server architecture but the interesting one in this mix is software, Which i think is now renamed Microsoft Application Virtualization or APP-V for short. You can read their blog here. Actually the release candidate was just released YESTERDAY.

With thinstall, I'm interesting what the pricing is going to be under VMWARE. When its in beta its definitely financially feasible for me to have my own personal portable powershell for personal use, but that's probably not the case post RTM.

I didn't have time to play with APP-V yet. SO MUCH CHALLENGE IS WILL SOMEBODY TRY TO VIRTUALIZE POWERSHELL WITH APP-V AND TELL US HOW IT GOES. I presume Microsoft will be more likely to allow redistribution of PowerShell through one of their own technologies ;)

Another cheap option I would challenge somebody is to try it in sandboxie , see if sandboxie is up to the job, as its very cheap, but i don't know if it does full "portable"

Finally there is another way, that I might implement, and that is roll my own. I wouldn't include the dotnet framework in this one (just too much work), but I can whip up a DLL in C++ and Assembler in no time to take care of powershell's filesystem and registry needs. Of course I couldn't redistribute portable PowerShell but I could make it into a small PORTABLEPOWERSHELLBUILDER.EXE app, that has a button that will build a portable PowerShell for you on any computer that has PowerShell installed in a similar manner to how BartPE or ReatogoXPE can build a bootable XP CD based on the files on a particular OS install.

Apart from the challenge of doing that, and doing some fun techniques that I've almost forgotten, and as a PowerShell tool vendor and partner of MS, I don't want to do that. I want MS to allow PowerShell to be redistributed, in a portable manner, and if they can fit it into their schedule, do some minor reachitecture of PowerShell V2 to be naturally portable, but more on that in my next blog post.

Over and Out,

Karl Prosser / ShellTools

Technorati Tags: ,,,,

Posted Jun 19 2008, 09:20 PM by Karl Prosser
Filed under: ,
Copyright 2012 PowerShell.com. All rights reserved.