...a highly questionable method that works... or at least worked once for me. 

I'm going to give smaller disclaimers a few times, but let me start out with a comprehensive one: I am not an expert in Windows, nor do I really do PC system administration for a living, nor did I hear from anyone else that this idea was OK.  Also, I did it just last night, and if I set myself up the [time]bomb, I won't know for a while.  Also, for all I know, it could only work this way on certain combinations of hardware.  Absolutely do a disk image backup before trying this, and absolutely do not try this with a machine that you need to have working tomorrow or your kid won't get his life-saving medication. In fact, it is my recommendation that you don't do this at all.  That said, I'll tell you what I did to move a fully functional Windows 7 system hard drive from a 2-year-old Dell Latitude laptop to a 1-month-old Dell Studio XPS desktop.

If you find yourself reading this, you probably already know that Windows 7 has no straightforward "Repair Install" option of the type you could use on Windows XP to move a hard drive to a system with completely different hardware.  According to what I've read, people often would do this when replacing motherboards.  You've probably also been annoyed to find out that the Windows 7 install disk, and the Vista and Windows 7 resources you find via Google search, tend to be obtuse about the reasons people would want to do such things: they assume you can successfully log into Windows at all on the relevant machine, but you still need to "repair" your installation.  You boot up the Windows installation disk, tell it you want to "Upgrade" your existing installation (the method of "Repair Install" that everybody recommends), and it tells you to remove the disk, shut down, boot up Windows, and stick the disk into the drive again after you're in Windows.  Well, when you've moved your system disk to a system that has a completely different motherboard, that's not really an option.  Usually, you get a fatal error and an infinite reboot cycle.  But by all means, if you can get into Windows on your relevant system, and you still need to do a Repair Install, follow the instructions at the sevenforums.com link; don't do what I did.

To make this work, you need to have access to the old, working system (the "source" system).  So this may not work for a lot of motherboard replacements, especially if the old one is burnt out or you didn't find out the system didn't boot until the whole rebuild was done, and you don't want to undo everything and start over. But if you're just trying to clone an existing system so you don't have to go through the weeks-long process of reinstalling all your software and redoing all your miscellaneous config settings, or if you're trying to move a system from any old (working) hardware to any new hardware, this might work for you.

So without any further ado, here's what you do: 

1. Boot up your working (old) system, using the hard drive that belongs in the new system as your system drive.

2. Begin the "Repair Install" process as described in the sevenforums.com link.  Go about the beginning of the Upgrade process as if you were Repair Installing to your old system.

3. When the Windows installer tries to reboot for the first time -- a few minutes after it has said "That's all the information we need right now" -- forcibly TURN OFF your computer* in the few seconds after the installer OS has unloaded and before the installer OS loads up again.  I believe the first reboot attempt happens after it's done with the "Expanding files" step, but I'm not 100% sure (please tell me if I'm wrong).  Just make sure the system is at least in your peripheral vision while the installation is happening, so that you'll see when the monitor goes blank.

4. Move your hard drive to the new system.  I also put the installation disk into the DVD drive, but I doubt that was necessary.

5. Boot up the new system, making sure that it boots to your hard drive, not the installation disk.  If you have a choice on your bootloader screen, choose the entry that says something like "Windows 7 Setup", not the one that says something about "Rollback".

6. Let the installer do its thing.  In my case, it seemed like the installer took a while longer than it has usually taken for me, but then, I usually am not running an Upgrade, but a new installation, so this could be normal.

The process itself is a lot simpler than explaining why you would want to do it.  Basically, it's the Repair Install process, but with the hard drive moved to the new system partway through, after the installation files have been prepared on the system drive.  My guess is that all of the assigning of low-level hardware drivers -- the stuff that makes it impossible to move the system hard drive without any hassles -- simply happens later in the installation process.

If you're still reading, be sure that you have a good reason for wanting to do this.  I did it because I had spent many hours installing development tools onto my new SSD drive.  I decided I wanted that drive in my new desktop, and I didn't want to reinstall everything.  And because this machine wasn't one of my two "main" computers, I didn't feel like I was risking much.  Even so, I made sure to take a Windows Home Server backup before beginning the process, just in case I wanted to get that experimental system back.

I cannot stress these things enough: 

1. Don't do this if you don't feel like you know what you're doing.  
2. Don't ever do this with a system drive that you're relying on for anything important, unless you're 100% confident you can restore it quickly.  Even so, I probably wouldn't do it.
3. I don't know whether this would work for other people's hardware.
4. I'm not really recommending you do this at all, and even if I were, you shouldn't think of me as an authority, as I'm just a guy on the internet.

For anyone who heard me telling everybody a couple weeks ago about how Windows 7 was awesome because it lets you just move a hard drive from one machine to another, and just figures it out: consider this a revision to that.  I had seen two cases where Windows 7 installations seamlessly figured out new hardware: 1) a VHD-based Windows 7 system had zero difficulty moving from running in VirtualPC to having that VHD file running on native hardware as a bootable VHD.  It may seem counterintuitive to some, but as far as the OS is concerned, this is one case of moving seamlessly between "hardware" setups.  2) When I moved a hard drive from a Latitude 820 to a Latitude 830 and back, Windows 7 had no problem with it.  If this sounds like nothing: I had tried to do the same thing, between the same two specific laptops, with XP system drives in the past, and they crashed hard.

* usually works by holding down the power button, but if you didn't already know how to force your PC to turn off, as opposed to turning it off via "shutdown", you shouldn't be doing this.

(file under: interesting info that's difficult to Google)

If you're like me*†, you download a huge amount of open-source and free utilities that don't have installers, write a bunch of batch files and scripts to automate common tasks, and use cmd.exe constantly‡.  So, you're setting up a new VirtualPC image, and you know you want to have the Sysinternals utilities on your new machine €, but you don't want to re-download them and you don't know where the heck you unzipped them to.  Where oh where could pslist.exe be?  Wait, you're an old Unix guy.  When you want to know where in your path an executable file is, you say "which".

Gladly, the great Raymond Chen solved your problem years ago, though you didn't know it till now:

Paste this line into a file in your Windows directory (or elsewhere in your path; c:\scripts or something like that), save as "which.bat" (or "whereis.bat" if you're not really an old Unix guy and you've just been pretending up till now).  Use like so: "which pslist".  To which it replies "c:\Program Files\Sysinternals\pslist.exe".  Simple as that.

Talk to you next season! 

And I am WAYYYY too cool for math.

I tried Chrome.  It was OK.  Just didn't have that many features.  I'm kind of a nut, I suppose.  I use Opera, IE6, and Firefox, almost every day.   Opera for low-friction general browsing, IE6 for "compatibility", and Firefox for its insane plugins (there will be a post about this, soon, I guess).  I'm typing this very post in IE, because this very BlogEngine refuses to let me create new links with Opera.  (As someone who has done the "make it work in IE" thing more times that I can count, I don't think this is a problem with Opera, per se, but then, I really don't care.)

But yeah, I tried Chrome, and it was fine.  But that's the thing.  I was just trying it.  Like most people.  I wasn't looking to change my life.  Which makes the fact that Chrome has lost market share the most surprising news since my shoe fell all the way to the floor when I dropped it.  Chrome has a couple very interesting innovations -- its JavaScript VM and its process/threading model -- but the version that's out today feels a lot like the time I rode in the early prototype hybrid car my friend was working on in college in 1996.  Cool, very promising, but just not done.  I'll see if I can dig up the breathless newspaper clippings from the next day, about how 100% of the friends of the Future Car team members who had ridden around in the hybrid had gone back to driving their regular cars.

(hint: á a vi keystroke sequence)

 Just a sort of random thought that's been brewing in the back of my mind for a while, and exacerbated by playing with the editor built into this blog: it's a bad thing that we need to sanitize user inputs to make sure they're not malicious HTML or script.  It's a bad thing that thousands of projects and millions of web developers have to even think about this.  It's an unconscionable drag on productivity.

Possible solutions:

1)  create a post-spammer, post-troll utopia where no one even wants to enter malicious text into the entry boxes.

2)  differentiate markup and code from content.

Considering the amount of work that's gone into the Web as we know it, #2's not a likely option, so we're stuck with #1.

Seriously,  I'm sure somebody could come up with a reason why this wouldn't work, or would be counterproductive -- it literally is something I just thought of -- but it seems to me there ought to be a better way. If it wasn't clear from the title, my model is vi. (For the uninitiated) it centers on a very basic idea: different modes for commands and content.  Typing "G" in text mode gives you the letter "G".  Hitting "G" in command mode brings you to the bottom of the file/buffer.  "4x" in command mode will delete the next 4 characters after your current cursor location.  There are many keystrokes that will put you into text mode, but only one (AFAIK) that will put you into command mode (ESC).

So, wouldn't it be nice if you could count on a "<script>SendInfoToEvilPerson(document.cookie)</script>" rendering as text content, and not executing as a script?  Should this really be so hard?  Discuss.

 Update: Ugh.  Tags: "Vi" and "Xss"?  (I typed in "vi,XSS")  Ugh.  I mean, I like case-insensitivity as much as the next guy, but saying that searching for "VI" should return a match with "vi" isn't the same as saying that any rendering of these terms is as good as any other (if you click the tags, you'll see that the URL has them in all lower case, which would honestly be much better than "proper case" for both of these terms).  Kind of weird, coming from a blogging tool by programmers, and probably mostly for programmers.

I excised a succession of dated hip-hop references, considered admitting I'd been involved in letting some dogs out a while back, then finally decided that what the world really, really needed from the title of my first post was the answer to the 1984 Musical Question of the Year.  Which says little about me, per se, but maybe much about my priorities.

I go by many names -- programmer, technical lead, developer, systems analyst, architect (<-- this one only when AJ's not looking).  I work for a small professional services company (to be very vague) in Minneapolis.  Over the last ten years, I've worked on designing, building, and maintaining a wide variety of systems for data collection, reporting, and facilitating certain types of communications between employees.  We use mostly Microsoft technologies, but use free/OSS tools extensively.  Lately -- basically the whole last year and a half -- I've been going back and forth on the right balance between Fire-and-Motion and learning the new technologies that are starting to make life easier.

Besides the stuff that AJ said on the "Who Are You?" post, my main reason for wanting to do this blog is to pass on some of my more obscure programming knowledge.  I often find myself doing things that no one else seems to be doing, at least as far as Google can tell me.  And I figure that the next time somebody needs to implement an AJAX driver for your pile or your bus, using the Eviscerator pattern in OBrainfsck, they could probably use the benefit of my experience.  Because it was very, very difficult.  The bus driver especially.

So, welcome, glad you're here, glad we're here, enough with the formalities, let's get down to whatever will pass as "business" around here.