The Windows Perl Blog

Along with Vista’s UAC security infrastructure Microsoft implemented something very clever, but has caused administrators and Perl coders frustration: User File and Registry Virtualization.

The concept of UAC (http://www.roth.net/blog/index.php/2007/04/02/vista-and-user-account-control-uac/)  is useful since it places finer control over what non-administrators can and cannot do. One of the core tenets of UAC is that a non-administrator should not be able to make changes that impact other users. For example if I make changes to an application’s settings they should only impact me, not other users of the computer. To accommodate this non-administrative access Vista virtualizes access by creating an alternate location for files and registry keys. The OS tries very hard to make this seamless so when an application tries to access a file or registry key it is redirected to the user’s virtual storage area.

In general this virtualization works, however for technical folk who want to access files directly they may be surprised to find the files are “missing”. Let say, for example, you want to manually edit an application’s configuration file. If the application was installed in the “Program Files” directory you may expect to find the file at C:\Program Files\MyApp\MyApp.cfg. But the file is really located in the path C:\Users\userID\AppData\Local\VirtualStore\Program Files\MyApp\MyApp.cfg.

Say what you will about Windows Vista but don’t think that it isn’t a big deal. Regardless of how you may feel about Microsoft, they put a lot of work into the Vista operating system. Sure the UI may not be as snazzy as Apple’s OS X and it is barren of some features from the promised land like WinFS. But there is an awful lot under the hood. Yes it is true that a Vista box really should have a recently upgraded machine to afford the resource costs the OS takes. But if you can afford the machine that runs the OS well rest assured that there are changes worth having. The problem that Microsoft faces is that these changes are not easy to quantify for the average consumer. How would you explain to your Mother about the benefits of the new media APIs? Or try convincing your boss to upgrade the entire IT department so that your machines could leverage PnP-X and Function Discovery. No, the innovations that underline the OS are not obvious to the layman. However there is one exception: security. 

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.

Over in the RC forums (http://www.roth.net/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 SQLServerCentral.com. 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:

http://blogs.sqlservercentral.com/blogs/brian_kelley/archive/2005/12/16/376.aspx

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.

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 (http://www.roth.net/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: http://www.roth.net/conference/perl/2000/Perl2000.ppt

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 FindInPath.pl which does traverse the PATH looking for files: http://www.roth.net/perl/scripts/scripts.asp?FindInPath.pl

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:
http://www.roth.net/forums/

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.