Software Sleuthing : Scripting

Running 32bit dependent scripts in a 64bit world

joshpoley — Thu, 18 Sep 2008 20:44:00 GMT

As seen earlier, it can be problematic to run scripts which rely on 32bit COM objects on a 64bit platform. To make things easier, I wrote basic some script code to detect that the wrong scripting host was run and fork out to the correct one. This just uses a variation of the "detect cscript vs. wscript" pattern, but instead we look at the current processor and do a check to see if we are running the wrong flavor of the script host.

// this script code relies on 32bit COM objects, if we are running on

// a 64bit system we will want to run under WOW64 (the x86 emulator).

var shell = WScript.CreateObject("WScript.Shell");

var cpu = shell.ExpandEnvironmentStrings("%PROCESSOR_ARCHITECTURE%").toLowerCase();

var host = WScript.FullName.toLowerCase();

// check to see if we are on an AMD64 processor and running the

// wrong version of the scripting host.

if(host.indexOf("system32") != -1 && cpu == "amd64")

{

var syswow64Host = host.replace(/system32/g, "syswow64");

var newCmd = syswow64Host + " \"" +

WScript.ScriptFullName + "\" //Nologo";

// ATTEMPT to pass all the same command

// line args to the new process

var args = WScript.Arguments;

for(i=0; i<args.length; i++)

newCmd += " " + args(i);

WScript.Echo("Running the syswow64 bit version instead...\n " +

newCmd + "\n");

// launch the new script and echo all the output

var exec = shell.Exec(newCmd);

while(exec.Status == 0)

{

if(!exec.StdOut.AtEndOfStream)

WScript.Echo(exec.StdOut.ReadAll());

WScript.Sleep(100);

}

if(!exec.StdOut.AtEndOfStream)

WScript.Echo(exec.StdOut.ReadAll());

WScript.Quit(exec.ExitCode);

}

// the real script code goes here ...

WScript.Echo("done");

In this sample we are just checking for AMD64, so you may want to add logic for Itanium or other platforms as well.

Be sure to notice the "ATTEMPT" comment when transposing the command line options from the current process into the new one. The way that the command shell handles double quotes makes it hard to reproduce the exact command line from the support we have in script. For example, if you pass /abc="hello world" as an argument, the quotes will get stripped out and you will actually see /abc=hello world from your script code. If we pass this raw argument (as shown above) into the new process then the one argument will be interpreted as two because of the missing quotes. It is left as a reader exercise to detect spaces and reconstruct the exact arguments if needed.

Automating Large Image Conversion with Photoshop

joshpoley — Mon, 12 May 2008 20:28:00 GMT

So fairly recently, I've merged my fascination with extremely large images with my fascination of fractals. The output of which was a handful of BMP files, some of which happen to be 18000 by 18000 pixels. To give you some perspective, that’s a 324 megapixels image (or ~309 megapixels for those of us who still subscribe to the fact that mega means 1048576 and not 1000000). I've been using uncompressed BMP files just because they are extremely easy to stream out, this means that the memory and processing requirements at generation time are very light (which is good because fractal generation can be a very CPU intensive process). The downside is that afterwards I'm left with a 927 megabyte file. So now I just need an easy way to convert these to something a little more manageable...

Photoshop offers a huge automation infrastructure, which allows you to run script files within the application. But you can also use COM and external scripts (or apps) to drive it as well. This gives me an avenue to automate the task of converting my bitmap files into smaller PNG files from the command line.

toPNG.js

var ps = WScript.CreateObject("Photoshop.Application");

var doc = ps.Open("C:\\sample.bmp");

var pngOptions = WScript.CreateObject("Photoshop.PNGSaveOptions");

doc.SaveAs("C:\\sample.png", pngOptions, true);

doc.Close(2); // don't save the file

ps.Quit();

For those that want to browse the entire object model, you can open up "C:\Program Files\Adobe\Photoshop CS\Plug-Ins\Adobe Photoshop Only\Automate\ScriptingSupport.8li" (at least that is the file in version 8) in a viewer like Visual Studio's oleview.exe (you may need to temporarily rename the ScriptingSupport file to give it a .dll or .exe extension).

Documentation on the object model can be found on the Adobe devnet site, or in your installation directory.

Validating a company email alias with Outlook

joshpoley — Mon, 21 Apr 2008 20:36:00 GMT

Most of the process related tools we use (bug databases, work items, test cases, etc), will keep track of owners by their email alias. Unfortunately, if someone's alias changes (such as transitioning from contractor to Full Time) or they leave the company, then items assigned to them become orphaned. Using the Outlook COM interface, we can check an email account to ensure it exists in our address book. This information could then be used to generate a report of which items need to be re-assigned. Looking at the below JavaScript, we show how to do a sample lookup:

checkAlias.js

var outlook = WScript.CreateObject("Outlook.Application");

function CheckAlias(alias)

{

var recipient = outlook.Session.CreateRecipient(alias);

// attempt to look up the entry in the address book

if(!recipient.Resolve())

return false;

var user = recipient.AddressEntry();

// if the entry did not resolve to a real user,

// then we just get back exactly what we passed in,

// otherwise we get back the user's name

if(user.Name() == alias)

return false;

return true;

}

outlook.Quit();

Note that invoking Outlook through the COM interface may bring up a security dialog, giving the physical user the option to allow or disallow the script execution.

To take this tool a step further, you could look at some of the other available methods and properties off of the recipient's AddressEntry to identify users who still work at the company but have moved to a different group or project. Unfortunately, some of the interesting properties are marked "hidden", so they aren't as obvious as would be helpful, such as the .Manager property which returns another AddressEntry object. All the hidden entries can be discovered using a Type Library viewer. And if you want to browse the entire Outlook Type Library, look in MSOUTL.OLB (it may need to be renamed to .dll or .exe for some tools to fully appreciate the goodness).

MSDN References

Outlook.Application

Outlook.Recipient

Automating DOC to PDF Conversion

joshpoley — Mon, 14 Apr 2008 20:16:00 GMT

The COM object model exposed by Microsoft Word gives us the power to save any document which Word can recognize into a PDF file (as long as you've downloaded and installed the XPS and PDF exporter first). And it turns out that programmatically converting between a document and a PDF file is a pretty simple task. Given 5 lines of script code, we can open a document and save it as something else. And below is a JavaScript sample that does just that:

toPdf.js

var msword = WScript.CreateObject("Word.Application");

msword.Visible = false;

var doc = msword.Documents.Open("C:\\sample.docx");

doc.SaveAs("C:\\sample.pdf", 17); // WdSaveFormat::wdFormatPDF

msword.quit();

If you want to browse the entire COM object model exposed by Word, you can open up MSWORD.OLB (which is where the type library exists in Office 2007) in a COM object viewer. Though note that if you are using oleview.exe that comes with Visual Studio, you will need to give the OLB file an EXE extension; apparently oleview has issues with oddly named files.

MSDN References

Word.Application

Word.Document

WdSaveFormat enumeration

Automating GIF charts from Excel

joshpoley — Wed, 09 Apr 2008 21:33:00 GMT

Using the COM object model exposed by Excel, we can programmatically open files, generate graphs, and save them as stand-alone image files.

Handily, the functionality provided by Excel gives us a simple way to generate charts and graphs when you need something easy and automatable. This is great for creating visualizations for automated reports, web pages, and the like (especially when "offline" or when you have limited access to various other utilities). Unfortunately, the main drawback to using the COM interface is that documentation is often limited and hard to find (especially now that everything has been .NETized), to help remedy this I've linked some references from MSDN below.

This JavaScript sample shows how to create a typical line chart given a simple comma-delimited file, and save it out as a .gif file in two different sizes.

chart.js

var excel = WScript.CreateObject("Excel.Application");

// no we don't want to show the Excel window

excel.Visible = false;

// open the file

excel.Workbooks.Open("C:\\sample.csv");

var sheet = excel.Workbooks(1).Worksheets(1);

// select both rows of data

excel.Range("A1:B9").Select();

// create the chart and setup some options

var chart = excel.Charts.Add(sheet);

chart.ChartType = 4; // 2D line (XlChartType::xlLine)

chart.HasLegend = true;

chart.Axes(1).HasTitle = false;

chart.Axes(2).HasTitle = false;

// save the large chart

chart.Export("C:\\sample.gif", "GIF");

// move the chart onto the main sheet

var ptr = chart.Location(2, sheet.Name);

// save the smaller chart

ptr.Export("C:\\sample_small.gif", "GIF");

// close out the Excel spreadsheet and application

excel.ActiveWorkbook.Saved = true; // suppress the "save" dialog

excel.Quit();

sample.csv

ABC,DEF

1,2

2,2

3,2

4,3

5,3

6,3

7,2

8,2

MSDN References

Excel.Application

Excel.Chart

XlChartType enumeration

And FYI, the type library information is located in excel.exe (in Office 2007) so you can open that file in a viewer (such as oleview.exe) to see all the COM interfaces, enumerations, etc.

Running JScript in a CMD File

joshpoley — Tue, 15 Jan 2008 19:32:00 GMT

I do a lot of work from a command shell and this is a little hack that I threw together to avoid having to type out "cscript" every time I wanted to run some specific JScript (aka JavaScript) file. Using some arcane aspects of the two languages, it is possible to embed the JScript code in a .cmd file which the command shell can initially execute and then pass off to cscript.exe for the heavy lifting. Below is a sample file, if it all makes sense you can stop reading now, otherwise continue on to see what is happening.

test.cmd

1 @set @cmdinterop=1 /*

2 @echo off

3 set @cmdinterop=

4 cscript //E:JSCRIPT "%~dpnx0" %*

5 goto :eof

6 */

8 var today = new Date();

10 WScript.Echo(today);

The main thing to remember is that the whole file is parsed by both cmd.exe and then cscript.exe. With that key piece of information let's step through the file.

CMD.EXE

1 @set @cmdinterop=1 /*

CMD sees the @ symbols which means "no echo", and then creates a new environment variable named "@cmdinterop" and sets its value to "1 /*". "@cmdinterop" is just a random name we've picked which has no special meaning in and of itself, though the 'at' symbol is important; more information on this will come later.

2 @echo off

Turn off future echoing of commands.

3 set @cmdinterop=

Nuke the environment variable we just set. Someone looking at this might be thinking: not the most efficient CMD script. If we don't need or use the environment variable, why do we create it? The reason is because the first line needs to be a benign statement in both languages: CMD and JScript. It just so happens that "@set" has meaning in both languages and so we make use of that fact to do our dirty work. This line will just clean up what we had to do on line 1, with regard to CMD's processing.

4 cscript //E:JSCRIPT "%~dpnx0" %*

We now have the CMD script invoke cscript.exe and pass in the name of the current file. The "%~…0" syntax is the cryptic way to get at the file-system properties for the current executing script: "d" for drive letter, "p" for path, "n" for the filename, and "x" for the file's extension. We also attempt to pass in any additional parameters by using the "%*" syntax.

At this point, CMD sits and waits for cscript.exe to finish executing, but we will just continue on since we are almost done with CMD's processing:

5 goto :eof

CMD now jumps to the end of the file, thus bypassing all of our JScript code (lines 6+).

CSCRIPT.EXE

1 @set @cmdinterop=1 /*

In JScript, "@set @" creates a variable which can be used for conditional compilation. We don’t really care about the variable which gets created as we will never use it, but what we do care about is being able inject the start of the block comment, which will allow us to ignore all the CMD code (lines 2 through 5):

2 @echo off

3 set @cmdinterop=

4 cscript //E:JSCRIPT "%~dpnx0" %*

5 goto :eof

6 */

Once we skip past all the CMD code we are free to use whatever JScript code we want:

8 var today = new Date();

10 WScript.Echo(today);

@set

From the JScript parser, things are easy as long as you can get the start of a comment block going. The tricky part is getting that "/*" to parse in CMD without causing an error. Luckily for us, "@set" is the magic code which gives us the avenue to do just that because it can be parsed by both languages.

Going forward, you may want to be nice to future readers of your code and sprinkle in a few extra comments:

@set @cmdinterop=1 /* this line interpreted by both CMD and JSCRIPT

@REM Start of the CMD code

@echo off

set @cmdinterop=

cscript //E:JSCRIPT "%~dpnx0" %*

goto :eof

REM end of the CMD code

// Start of the JScript Code:

Standard Disclaimer: As mentioned earlier, this is a hack. I've tested and used this on XP SP2, but changes to the languages and parsers may cause this script to break.

Leak Tracking with PowerShell

joshpoley — Fri, 04 Jan 2008 19:11:00 GMT

One of my holiday tasks was to learn some PowerShell. While reading/skimming through a book on the subject, I decided to create a quick script which would track memory utilization for a given application. In the past I've used a stand-alone application which would take a snapshot of all the processes and dump out the memory utilization, number of handles, etc. I would then call this application from a batch file periodically to generate a trend of the resource usage. This was an indispensible tool for tracking memory leaks etc., but required some post processing to filter out only the application I cared about. Using PowerShell I was able to whip up a quick script which gave me much the same information without having multiple processing stages.

memsnap.ps1

# MemSnapGetHeader - returns the header string.

function MemSnapGetHeader([string] $procName = "*")

{

$time = get-date

$header = "MemSnap Report`n"

$header += "`nStart Time: "

$header += $time.DateTime

$header += "`nProcess: "

$header += $procName

$header += "`n`nTime (s), Threads, Handles, Working Set, Total CPU (s)"

return $header

}

# MemSnapGetLine - returns the current comma delimited stats for the

# given application name.

function MemSnapGetLine([string] $procName)

{

$procInfo = get-process $procName

# if we get back more than one, just grab the first one

if($procInfo.length -ge 2)

{

$procInfo = $procInfo[0]

}

# build the stats string

$ret = "" + $procInfo.Threads.Count

$ret += ", " + $procInfo.Handles

$ret += ", " + $procInfo.WS

$ret += ", " + $procInfo.CPU

return $ret

}

# MemSnap - this function is the main processing loop which will gather

# the application stats.

# hit Ctrl-C to break out of the loop

function MemSnap([string] $procName = "*", [int] $delay = 10)

{

$time = 0

$header = MemSnapGetHeader $procName

$header

while($true)

{

$line = "" + $time + ", "

$line += MemSnapGetLine $procName

# echo out the current stats

$line

sleep $delay

$time += $delay

}

To run it, first we load the script file, and then we call the monitoring function with the application to track:

> . C:\memsnap.ps1

> MemSnap "explorer"

You may need to set script execution permissions if you haven't already:

> Set-ExecutionPolicy RemoteSigned

As this was my very first PowerShell script, comments about inefficiencies, best practices, etc. are more than welcome...