Crazy is as crazy does
When I was an undergraduate at CalTech, my student residence- Ricketts House- had a tradition where we relieved some of the tedium and stress of the annual election for house officers [President, Vice-President, Social Vice-President, Secretary and Treasurer was the lineup if memory serves me well] by nominating and electing people to “Minor Offices”. [Looking at the Wikipedia link, I see I probably fit the Scurve profile more than I had realized- I’ve had many problems since with holding controversial and unpopular opinions- now that I’m old I just keep them to myself more than I used to].
This process was largely temporized on the spot, and usually fueled with socializing, various recreational substances and a great deal of levity. Some offices had “duties”- for instance, the RLPL (Resident Lecturer on Pornographic Literature) was in charge of the acquired collection of said “literature”- and in self-defense I’ll add that this had been an all-male school until a year or two before I arrived. Others (such as the “House Christian”) were largely symbolic- often made up and discarded as seemed appropriate to the assembled wits at the time. [To put the RLPL in context, I remember utilizing the service to read a Playboy interview from the mid-60’s, of Jerry Garcia, so it wasn’t always the porn that was the draw].
My purpose for the aside and the title of this post combine. During my tenure, while I never held an elected office, I was elected several times to one particular office- “House Crazy <a word I cannot use on MSDN, or email, or say on public broadcast- I suppose “F-bomb” comes close enough>”.
I’ve always had a quirky sense of humor, and I displayed it a lot during those years, so I suppose I deserved the title- things like taking a philistine swipe at some of the campus art being acquired by building a “sculpture garden” that included discarded urinals I dragged up from the basements [I swear you could find anything down there, if you looked long enough], stacks of chairs, umbrellas, discarded lumber- all tastefully arranged for display of course- and I really liked building things off-the-cuff with precarious and eccentric balance to them, so there was some “art” involved, in at least one sense of the word. The darbs sort of liked it- I doubt the Master of Student Housing liked it, since we titled the display with his name. Never can tell, though- some people actually can take a joke [I usually try to]…
Another factor was being a pyromaniac- I can remember holding a drinking glass with some burning gasoline in it [not a lot- maybe a few millimeters, before it ignited] at one point [only because I had to find a place to toss it, to avoid injury to myself- with a bunch of people crowded around it took a while to find one- even at that somebody insisted I was throwing it at them- not the case- at that distance I wouldn’t have missed…], and at another being asked to detonate an explosive mixture someone had painted on an exterior window and then decided they didn’t feel safe either leaving or igniting- in normal form, I used a long rolled up piece of newspaper, ignited one end, set the other against the frame, and then ran, barefoot as always, across the roof tiles, which were often littered with shards of gritty nasty stuff, but my feet were long since tougher than that [of course this wasn’t on the ground floor] to get out of range. But it was a bit of a letdown, that time- not sure it even shattered the window- where’s the fun in that?
I suppose I did earn the title [and I believe I paid for most of the damages, as well, but that would be even more off-topic stories]…
So today I find other outlets, and wanting to write something before I go on vacation without having posted anything in almost two months, I’ll pick one at random and see if it’s worth talking about.
Endless Dogfood
“Dog Food” is what we refer to new and unreleased software as, here at Microsoft. Using it means you are helping those who are developing the software as an adjunct tester, and being a helpful sort [as are most of the other ‘softies I know], I participate when I can. But it brings its issues, particularly if you are using it for real work- and if you’re not using it for real work, then just how is it you are helping?
To test KMDF and UMDF, we use a lot of tools- many of which you know. But to maximize the potential return of our test effort, I want to “dog food” as much of it as possible. That’s not as simple as it sounds- these are just a few of the issues experience has shown me:
- most products under development are built frequently, with multiple versions shared out from their “release shares”.
- The form in which those shares are presented [in terms of paths to specific processor architectures, for instance] has some variations.
- Sometimes when a product goes bad, you have to get it from somewhere else, such as a private build.
- Or you may have to stick with a previous fixed version for a while.
- But most of the time you want to get as much as possible from the same place, because some people won’t even talk to you if they see you doing much mixing and matching.
- If that mixing and matching includes things that go into driver packages [and it does for us], then cataloging and signing becomes an issue.
- Worse yet, since we do our own servicing, we sometimes have to run signed content used to test our older products whose signatures have expired and are no longer valid.
We used to make horrid ad-hoc changes to handle these things- breaking paths down into “parameters” banged together in explicit paths to form a full path, for instance. Done differently for each automated test, of course. To get a test run by someone else, you had to communicate a complicated list of these “parameters” to whomever was running it, and they had to get all of them right.
One day I decided I’d had enough, and out of that was born one of those custom designed solutions that is probably as quirky as the problem it solves. Not the global sort of solution Microsoft sells to people, but the kind of stuff a lot of people in IT or support roles have to build just to survive.
In the amalgam that is my work life, this became part and parcel of a task I was doing at the same time, which was to bring some commonality to all of our test setups, so it was easier to look at a machine on which a problem had been reported and know what you were actually looking at.
Simple Mind, Simple solution
So I started with some basic rules:
- One setup job goes out, finds all the tools we use, copies them to the test machine, and sets them up.
- Individual tests never go to the network for anything- if someone needs something, we add procurement of that to the setup job.
- The setup job will own making sure that everything is signed.
- The setup job is going to be very smart- no more complicated instructions. Our most common test requirements should be its defaults, and if we need something run outside our group, all that should be needed is one reasonably mnemonic string value, used as a parameter, to identify the machine configuration we are testing.
- The setup job is going to log where everything that is pulled off the network came from in easily accessible form, including a history of such locations from previous runs of that same job if it gets run more than once after a new OS is installed.
- It will be easy to tell it to get the most recent version of anything we use- but it will also be possible to tell it to get a specific version. Our team will own making sure that knowledge is there in a fashion that we can meet bullet #4 above. Bet you thought I’d forgotten I’d mentioned dog food earlier, didn’t you?
- Everything we use is to come from a supported source- not some file someone stuck on a share somewhere that had no clear ownership [or symbol files, usually…].
- Experience says there will always be some need for temporary exceptions to that last one- so put all those eggs in one basket and watch that basket closely.
Well, WTT does provide some facilities aiding in what we wanted, but it was not at all close to everything we needed. So it was time to invent.
First, I broke the job into phases:
- An Analysis phase where it takes that single parameter, along with some database of recorded setup knowledge, and determines for itself [by checking the appropriate shares] if all the pieces needed are available, and if they are, which specific places to get them from. The results of this phase are “cast in concrete”, and the subsequent phases will use this information and only this information- not go looking again [which causes problems when things change between the analysis and when they get around to looking, for instance].
- A “staging” phase where anything that isn’t already on the machine is copied to the machine. The places copied from are determined by the preceding analysis. If it starts out on the network, and you need it on two places on the machine- this phase has to copy it to the machine first, and then from one place on the machine to the other. It is also not a problem if later jobs also do such copying- as long as they never go to the network again.
- Finally, a “configuration” phase where tools are installed [from MSI or such already copied in the staging process], registries tweaked, and the machine is made ready for testing. At this point, any of our jobs should be able to be run in any order [and one benefit here was we can now test either KMDF or UMDF where we had previously been one or the other].
That done, it was time to make it a reality…
Maybe not so simple, after all
First of all I needed that way to record values so they were usable both by WTT and by scripts and command line apps and whatever else without too much intervention. Some research and experience aforethought turned up the answer, and it was almost as old as I am- the machine’s global environment is accessible to all of them, it can be updated with simple registry operations, and you can even make the changes immediately recognizable to all the pieces that really count by broadcasting a Windows message when you finish the updating [Wei indirectly clued me in on the last part- he observed that if he used the control panel the changes were immediate, even on open command prompts, but not after using one of the early versions of this code].
Then there perhaps would have been the signing issue, except that we had been working on that one- we had found that we could catalog and self-sign everything and that seemed to cover everything [eventually this has had some holes, on pre-Vista OS, but I’m working on them when I can]. But we were using a copy from some WDK stuck on a share- see rule #7 above!
So, I now needed some way to encode directions about where to find things how those directions changed under various circumstances, and how they differed under certain test requirements, and something that would take that information and create those environment variables. It also had to meet my logging and reporting requirements.
I wound up with another ancient solution- Windows private profiles [aka INI files]. As I’ve already taken up too much time composing this, I’ll have to continue the story at a later date…
