XMLRPC-C 1.0 for Win32

If anyone is using (or trying to use) the XMLRPC-C library on Win32 and having issues with getting the examples (or anything) to compile and/or work with the WinInet transport, I have created an archive of changes to the 1.0 distribution that will probably solve your problems.

A few of the changes are likely not "clean" (but good enough for me to start on a quick prototype of something else). If/when I have some time later I will fix them up, confirm it doesn't break *NIX distributions, and send them in. In the meantime, if anyone would like the archive email me and I'll send it on - normal caveats apply.

Kudos to Bryan Henderson for recently resurrecting this library from an over 3 year grave. And thanks to Eric Kidd for the initial work!

Abstractions in Design

Peter Torr from Microsoft blogged that Changing Abstractions in an Object Model is Hard. I think of system design as the "art" portion of software development. I consider a "programmer" as a person who is familiar with the technical (both normal and arcane) details of an operating system, language, or framework. The "software developer" needs to know the former, and branch out from there, thinking of object models, end-user usability, threat models, abstraction, and extensibility.

The italicized font portions below are quoted from the blog entry (some liberty with snipping was taken for readability out of context). If you are interested in learning more about solid design, this essay is a good high level overview. These are (IMHO) the salient points of the essay:

But to make a[n] object model easy to use, you want to simplify (abstract away) many of the details so that the developer has less concepts to understand and so that they can "discover" and use the features of the object model in a natural way.

...you don't want to make your system more complicated than it needs to be. Complications lead to bugs, and unnecessary complications lead to unnecessary bugs. Having lots of "pluggable" components (interfaces, abstract classes) makes it hard to reason about the system (and to threat model it!) because you can't be sure what any given extension will do.

Or, if she is just getting started with the object and starts to read the conceptual overview, there will be far too many things obscuring the basic design that she won't be able to see the forest for all the trees. This is a real concern, since documentation is incredibly hard to write and minimizing the number of concepts a developer must grasp to use an object model is crucial to making it usable.

Active Setup Registry Keys and their Purpose

I’ve been very busy lately, and I’m sorry about the blog being so quiet. I haven’t gotten around to completing the Custom Action DLL tutorial, but I’m pretty close. I need to find a server that would let me store some zip files. Any ideas?

Back in September, Aaron Stebner blogged about detecting what .NET 1.0 Service Pack is installed. One of the keys he mentions checking has the word "Active Setup" in it. Just what is that key for?

The Active Setup key in Local Machine is read when a user logs in to the system. Keys in the Local Machine registry hive are compared against keys in the Current User hive. If a key that exists in Local Machine does not exist in the Current User hive, the program the key points to is run. Effectively, this is one way to customize (or completely remove) an installation on a per-user basis, assuring that a program is executed exactly once per user.

There are several installations that use this key. Microsoft Net Meeting and Internet Explorer are a few examples. Lets say you update Internet Explorer to a new version – like IE 5 to IE 6 – and you have two active user profiles. When the computer is restarted and the user logs in, you see a dialog that shows IE is being configured. When the other user logs in, they see the same dialog. This is Active Setup at work! Net Meeting uses this mechanism to cleanup user profiles after Net Meeting is uninstalled. Sadly, virus and spyware packages also use this mechanism (changing the Local Machine key after each reboot), forcing the vigilant advanced user to check yet another key for items that run at startup. This is yet another reason to run as a restricted user!

The limitations of this mechanism are simple: The program that is run from Active Setup runs in the current user space. Therefore, to be completely safe, any Active Setup program should require read/write access of the most restricted user type – only modifying files and registry keys owned by an individual user. Additionally, this is run BEFORE the shell and other run keys.

There is no "official" documentation on these keys or this behavior, so the normal caveats apply to using this mechanism – it may not be present in newer versions of the OS or Service Packs.

Here is some detailed descriptions of the keys and their contents. A registry key called "HKEY_LOCAL_MACHINE\Software\Microsoft\Active Setup\Installed Components" has a bunch of subkeys under it that are GUIDs. Values contained under the GUID key that we are talking about are "Version" (string), and "StubPath" (Expand String).

Every time a user logs in, the contents of this key is compared against the SAME key in HKCU. If the HKCU key does not exist and/or the "version" value is less than that in HLKM, the appropriate "StubPath" command is run and the key copied to HKCU so it is not run again.

To see how this works for yourself, you can create a key in HKLM…Installed Components and call it "test". Then, add to it a String Value "StubPath" and set it to "notepad". Reboot. See that when you log in, notepad starts. Log in as a different user. See that notepad starts. Log in again with the first ID – notice notepad does not start – as now the "test" key has been copied into the HKCU branch after it ran the first time. Note that version is not necessary.

Since I am not sure what the other values of these keys mean and/or do, I’m going to end the discussion here. If anyone has more information on these keys, please add it to the comments for this post!