You need to read this out loud for it to make sense.

- Do you remember that young lady that used to work here? What was her name, miss.. miss…?

- Understood, Miss Understood. She’s married now, by the way.

- Oh really? So it’s Mrs. Understood now, is it?

- No, she took her husband’s name, Mrs. De’Point.

)

PowerShell has two registry ‘drives’ defined:

HKLM for HKEY_LOCAL_MACHINE

HKCU for HKEY_CURRENT_USER

The other registry roots are not defined.

A few days ago, a friend of mine was trying to find and remove some entries from HKEY_CLASSES_ROOT and was having a hard time using RegEdit.

So, I offered my help, while promoting my latest obsession – PowerShell.

Imagine my embarrassment when I found out a minute later that there is no HKCR drive defined in PowerShell.

Fear not, my friends, for the HKLM and HKCU are merely there for convenience. 

You can define by yourself, with a simple command, any registry drive you want.

So, before working on the HKCR drive, we simply define it like this:

New-PSDrive -Name HKCR -PSProvider Registry -Root HKEY_CLASSES_ROOT

Now, you have full access to HKEY_CLASSES_ROOT via HKCR.

Have fun.

P.S.

While on this subject, Ever noticed how you can’t use ‘-filter’ with the ‘dir’ command on registry drives?

Well, you can pipe the results through the question mark filter to do the same job, though I’m quite sure there’s some performance penalty. Still, better than the old RegEdit.exe, right?

Here’s an example:

cd HKLM:\SOFTWARE\

dir | ?{$_.Name -like “*Int*“}

Man, you’ve gotta love PowerShell.

Although I’m mostly into GUI and user experience, I just love console applications.

They’re super fast, powerful, concise, and if written correctly they are also easy to use (there’s that user experience theme again).

If I had to sum up the benefits of PowerShell in one sentence it would be this:

“Object oriented, interpreted, .net enabled , well structured shell and scripting environment.”

To install Windows PowerShell, just go here.

Now have a look at this cool little script I wrote last night.

It uses Yahoo! weather web service to get the local weather (in this example, local means Israel’s international airport, which happens to be close to where I live).

Click on the image above to open it full-size and let’s go over the lines real quick.

Line 2: creates a new .NET WebClient object.

Line 3: calls Yahoo’s WebService by downloading the result xml, converting it to a .NET XmlDocument object on the fly.

Lines 5,6,12,13,21-25: get a string value out of an xml node or attribute.

Some other interesting things to consider:

• Lines 8,14 and 26 use the -f formatter, which works basically like C#’s String.Format().
• Also note the pipeline (|) used to manipulate the text color in these lines.
• To get the weather someplace else, all you need to do is modify the url, see their instruction page for more info.

And this is how it looks when I run it:

function weather {
$a = New-Object net.webclient
[xml]$x = $a.DownloadString(“http://weather.yahooapis.com/forecastrss?p=ISXX0011&u=c“)

$loc = $x.GetElementsByTagName(“yweather:location“).item(0)
$current = $x.GetElementsByTagName(“yweather:condition“).item(0)
“”
“Location: {0}“ -f $loc.getattribute(“city“) | Write-Host -ForegroundColor gray
“”
“Current weather $([datetime]::Now)“
“———————————–“
$text = $current.getattribute(“text“)
$temp = $current.getattribute(“temp“)
“`t{0}, {1}°C“ -f $text, $temp | Write-Host -ForegroundColor yellow

$forecasts = $x.GetElementsByTagName(“yweather:forecast“)
“”
“Forecasts“
“———“
foreach ($f in $forecasts) {
$day = $f.getattribute(“day“)
$date = $f.getattribute(“date“)
$text = $f.getattribute(“text“)
$low = $f.getattribute(“low“)
$high = $f.getattribute(“high“)
“`t{0}, {1}: {2}, {3}-{4}°C“ -f $day, $date, $text, $low, $high | Write-Host -ForegroundColor green
}
“”

}

Try to find me in this group photo…  )

New York Times

Information Week

Preface

Editing binary resources when you have the source code is pretty easy. Just change the original file and maybe change some properties in the project to re-embed the modified resource. Piece of cake.

But what if you don’t have the source code? Or maybe you do but the build process is too lengthy/fragile/complicated/error-prone/etc. ? Another good reason is obfuscation with a changing/random map file, which means you can’t rebuild a single assembly and expect it to interact with the previously built assemblies.

Here’s how to modify a binary resource in 3 easy steps.

Step #1: Disassemble the assembly.

Use the following command to disassemble your .net exe or dll:

ildasm /out=assembly_name.il assembly_name.dll

(replace assembly_name.dll with your dll or exe name).

This will output plenty of data files. We are interested in these:

1. *.resources - The binary resource files.
2. assembly_name.res - The resources manifest.
3. assembly_name.il - The actual MSIL code.

Step #2: Edit the resources file(s).

Prepare the modified/new resource, it doesn’t matter what name it is but the format should be the same as the one originally included in the assembly (e.g. replacing bitmap for bitmap, icon for icon).

Use a resource editor to edit the resource file. I use Resourcer for DotNet by Lutz Roeder, it’s freeware. By the way, the same author also wrote Reflector.NET, an awesome tool for .NET developers.

If you’re using the Resourcer, here are the steps required:

1. Open the .resources file you want to change and rename the original resource item.
2. Hit Ctrl-F to insert file and select the modified version from you file system.
3. Rename the new item to have the same original name as the previous one (you can’t you copy/paste for that, for some reason it just copies the entire item instead of just the text).

Step #3: Reassemble the assembly.

Use the following command to disassemble your .net exe or dll:

Important: This will overwrite the original dll/exe !

ilasm /resource=assembly_name.res /dll /output=assembly_name.dll /key=signing_key.snk assembly_name.il

(replace assembly_name.dll with your dll or exe name and of course change the /dll to /exe if needed).

The signing key parameter is optional and is only needed if the original assembly was signed.

Of course, if it was signed by someone else to prevent tempering, you won’t be able to use the modified assembly unless you provide the original signing key, which I assume you won’t have. But that’s just how .NET works.

If you know how much is 2⁸ without getting a calculator out, this day is for you.

Well, if you’re reading this blog this day is for you.

It’s programmers day! The 256^th day of the year.

Now go fix some bugs!

(source)

— Albert Einstein