How long to write 1 line of code? The registry gets complex!

So I want to stick a simple value into the registry such as "FolderLocation" at HKLM\Software\Company.

Then I want to have developers able to read that *EASILY* using powershell, c#/vb.net or vbscript.

This is simple to configure and very simple to code. In most of these languages it's one line of code (with maybe a little object instantiation beforehand).

Except if we are running on Vista, or Win 7 where we now have this new thing called "Registry Virtualisation" to contend with - for a while, but not forever...

"This form of virtualization is an interim application compatibility technology; Microsoft intends to remove it from future versions of the Windows operating system as more applications are made compatible with Windows Vista. Therefore, it is important that your application does not become dependent on the behavior of registry virtualization in the system." http://msdn.microsoft.com/en-us/library/aa965884(VS.85).aspx

This joyous bit of technology redirects registry writes/reads on the fly if they involve locations no longer deemed usable by "applications" (which I'm taking to mean "anything non-Microsoft").

For example, if my C# application reads the key mentioned at the top, it will, apparently, be redirected on the fly to read HKEY_CURRENT_USER\Software\Classes\VirtualStore\Machine\Software\Company.

Sure enough, this key is there. But the Company key I created above using regedit isn't. When I read HKLM\software\company with reg.exe (the command line tool), it's there. If I read it with my C# application, it's not.

Better still, this behaviour isn't consistent.
Registry Virtualisation will occur for:
32 bit interactive processes.
Keys in HKEY_LOCAL_MACHINE \Software.
Keys that an administrator can write to.

But it's disabled for:
64 bit processes
Non-interactive processes (e.g. services)
Processes that impersonate a user
and a few others

My dilema is that I will eventually create these keys using a 32 bit or 64 bit service (so no virtualisation), but they will be read by 32 bit or 64 bit interactive processes. The service will be running under a service account and the scripts under a user account - hence the need to use the shared HKLM space.

How on earth do you communicate to a developer where he's suppose to go read and how much code is this going to require to figure out the platform, x86 or x64 etc etc?

So much for someone's idea of making things better. One line of code that would've taken me seconds to write has now turned into a 2 hour slogathon just to uncover the issue. I've still to figure out a solution :-(

For people using batch files, I also store the folder value in an environment variable. I really don't want to go creating loads of environment variables, but it's sorely tempting.

Oldest Trick in the Book

Remember the Anna Kournikova virus - that was the one that arrived as an e-mail inviting the recipient (presumably mostly males) to click to see pictures of the famous tennis star? That was back in February 2001.

The latest trick, while on a technology level is totally different, it uses the same old tried and tested social engineering trick to pull the target in.

This one uses MSN. The target gets a chat from what appears to be a "hot girl". They start chatting and very quickly this girl is suggesting the target go take a look at her web site where there's all sorts of interesting things to see.

Unfortunately, the web site is nothing more than a payload delivery mechanism for some sort of malware.

The really clever bit (and you have to give these people some little degree of credit for how easily they socially manipulate people) is that this "hot girl" on MSN is little more than a computer program designed to hoodwink people into visiting the site.

Mind you - it probably doesn't need to be that sophisticated.
MSN: "Hi handsome - what's your name?"
Target: Fred
MSN: "Wanna see some pictures on my web site?"
Target: absolutely