Thanks to the "Seattle Drivers Suck" blog (link) I am finally seeing those of us Seattle drivers (both Perl and non Perl drivers) vent and rant about what they loathe about the average Seattle driver. This is good reading for anyone considering visiting this town, and manditory for everyone moving here.

A buddy of mine runs the Windows Incident Response blog over at He is always digging up something interesting and pertinent to all your Win32 system administrators; regardless of whether you use Perl or not.

And if this stuff interests (or scares the Hell out of) you then you should have a look at his books, Windows Forensics and Incident Recovery (; it received a great review on Slashdot (

Over in the RC forums ( someone posted about having problems with Crypt::SSLeay on a Windows server. Of course I was curious so I started digging and uncovered an interesting blog entry from Brian Kelly over at He explains why ActiveState does not offer the standard encryption extensions either by default or in their online repositories. It is worth a quick read:

My tech editor recently pointed out something that I found quite astonishing about the Win32::TieRegistry. If you are not familiar with this extension, it is quite useful: by tie-ing a hash to the Windows registry it is quite simple and easy to access registry hives, keys, values and data–as easy as using a simple Perl hash.

This extension is a Godsend for everyone who has have never programmed to the Win32 registry APIs or used Perl’s Win32::Registry (which pretty much mirrors the Win32 registry APIs). The registry APIs are not the most intuitive, even though they are logical (once you bother to learn them).

But what amazed me was that Win32::TieRegistry makes some pretty vast assumptions about permissions. As he explained to me, when you load the extension in your script it attempts to open the registry with read and write privileges. This is fine if you are running a script as an administrator or only accessing keys that you have been granted such permissions. But if you are not an elevated user then attempts to only read keys, values and data will fail — without tripping a fault or some kind of noticeable error.

We are back after a 5 day outage. We apologize for any inconvenience that the outage may have caused, but this was an unplanned and unexpected outage. Apparently Verizon dropped an entire trunk of DSL connections on Friday (28 July 2006) morning. To rebuild the connections took 5 entire days. Rumor has it, however, no one was working on this over the weekend.

It is nice to know that Verizon’s utility monopoly is looking out for their customers.

Some time ago a friend introduced me to precompiled regular expressions. Now, I have always been an absolute fan of regex–it is one of the cornerstones of Perl. I have written scripts that consisted of hundreds of regexes. But since my introduction to the precompiled regex I am a full time advocate!

The beauty of a precompiled regex is that it is fast. Every time that a regular expression is evaluated it has to be compiled from its text representation into a block of byte code. This byte code is then run and it produces the regex output that we all know and love. The downside is that compiling into byte code takes time. So if you have a script that loops for a long time you will be wasting time compiling the regex over and over again. Depending on the code and the complexity of the regex this time could be significant.

In a precompiled regex you compile the regex and assign it to a scalar just once. Then when you go to use it you will simply execute the precompiled byte code–there is no need to spend time compiling it.

For example:


Over in the Forums ( a question was asked about converting VBScript into Perl. This reminded me of a question that I am still frequently asked about: how do you use COM objects in Perl? It just so happens that we have a PowerPoint presentation that I gave at the 2000 Perl Conference on this very subject:

In brief, a Perl script can interact with most COM objects. This is done using the Win32::OLE extension which comes as part of Activestate’s Win32 Perl. There is experimental support for COM eventing but it has unfortunately been experimental for several versions now.

One of the annoyances that Win32 Perl bothers me with is the lack of traversing the PATH. There are some Win32 specific functions built in such as Win32::GetFullPathName() and Win32::ExpandEnvironmentStrings() which are very useful when dealing with Windows’ paths, but suck when dealing with a PATH relative file.
For example, if you have a path like "rundll32.exe" there is no way for Perl to easily determine that this represents c:\Windows\System32\RunnDll32.exe. This should be pretty simple to do since "%SystemRoot%\System32" listed in the PATH variable by default. The closest Win32 Perl comes to solving this is to use Win32::GetFullPathName(), but this would prefix the file with a path based on the current working directory (from Win32::GetCWD()), not traverse the PATH looking for a file match.
It is too bad that there isn’t a simple solution to this. However, until the day when such functionality is added to Win32 Perl you can use the script in our Perl Script Repository called which does traverse the PATH looking for files:

We have redesigned our site a tad bit by adding forums. It is a place for open conversation and discussions. You can post thoughts, start threads, expose conspiracies, float new ideas…do what comes naturally in a forum! :)

Unfortunately registering for the Blog does not register you for the Forums–you’ll need to register twice. Once things settle we may try to resolve that. Give it a try and let us know what you think:

Dave’s latest Windows Scripting Solutions article (link) demonstrates how a Perl script can use UPnP to query Internet Gateway Devices (IGD) to see what ports have been mapped.

It is unfortunate that UPnP support is haphazardly implemented on most vendor’s IGDs (such as broadband routers). This means that even the best written UPnP client code can only view the mapped ports that the IGD allows it to view. The promise of IGD falls quite short in this regard since not only are many of the features in the various DCPs optional but how they are implemented are up a vendor’s interpretation. Hopefully newer technologies such as Web Services on Devices (WSD) based on the Devices Profile for Web Services (DPWS) can change that.

To read this article requires a subscription to Windows Scripting Solutions.

« Previous PageNext Page »