Nynaeve

Everybody hates spam, the scourge of the Internet. One of the common ways to reduce the amount of spam one gets to use throw-away email accounts or aliases when signing up for compulsory registration services (another scourge of the Internet in my mind, but that’s just my opinion).

Google even makes this easy with Gmail, as you can append a + sign followed by text to create a throw-away alias for your Gmail account (with the disadvantage that spammers could trivially strip + signs and determine your real email address if they were so inclined).

One way to take this a bit further and figure out just who is spamming you, however, is to use unique aliases for every compulsory registration service you sign up for, and then take note of which ones actually start getting spammed. Provided you really don’t reuse those aliases, if one starts getting spammed, it’s a pretty good indicator that the person you gave it to is either compromised or selling your email address out.

For example, I used a unique alias to sign up for some VMware Server serial numbers some time ago (they’re freely available), and recently (to my surprise) it started getting spams (of the type that I would imagine would be emitted by spam bots on compromised home systems). Now, either VMware is selling out my email to spammers of the more shady sort (which I would consider unlikely for a reputable company), or someone with access to VMware’s marketing mailing lists got compromised with some sort of malware at some point and the contents of the mailing list got inadvertently leaked out (oops!). I’d consider the latter more likely in this case, at least unless VMware has some sort of underhanded interest in herbal medication and the like that they’ve been keeping under the table…

I think this is a good time to point out that even reputable companies make mistakes, and it only takes one person’s compromised Outlook to spill the goods on a mailing list. As a result, even with more trusted companies, I am more inclined to use throw-away aliases rather than my main alias, so that I can cut off the throw-away aliases when they start getting spam some time down the road.

It seems that every sort of electronic device you get nowadays has to have some sort of ridiculously annoying blinky light.

The set of Bluetooth stereo headphones that I recently bought have an annoying blue light on the “M” button on each earpiece. While you’re playing stereo audio through them, the two lights slowly fade in and out. It’s really quite annoying to walk into a dark room with the headphones on and have a weird blue glow playing off the walls because of it. (It seems that there must be a rule out that somewhere that every Bluetooth device has to have a blue LED somewhere, or it’s not really Bluetooth(tm).)

Then there’s the V740 ExpressCard that I got recently for EVDO Rev.A Internet access. The improved upstream and latency on it is great, but I wish that someone would have written on the box: “Warning, this product includes a blinky LED whose sole purpose is to annoy the operator.”

Specifically, there’s bright LED (low quality camera – sorry) on the card that blinks several times per second while in use. The LED doesn’t provide any sort of indication of data rate, what type of service you are using; just that you’re connected (in other words, nothing useful). Apparently, Novatel thought it important enough to remind you that you’re still online with an annoying bright light right by your laptop keyboard (where most ExpressCard ports are) that strobes a couple times per second. Great idea, there, Novatel…

Then, there’s a PNY USB flash memory stick I bought recently that also blinks many times per second while it’s in use (bright red, this time). This, of course, really sucks if you use it for ReadyBoost, pretty much forcing you to plug it into the back of your computer (to the eternal annoyance of anyone sitting across from you at a table).

Even my laptop (an XPS M1710) is adorned with flashy LEDs, though at least these are programmable (and can be disabled if desired), making them at least somewhat redeemable.

Ironically, my cell phone is about the least intrusive gadget I use in terms of annoying blinky lights. I think that is saying something about the unfortunate state of affairs with modern electronic gadgets and the obsession with blinky lights nowadays…

Yesterday, I decided to install Visual Studio 2005 SP1 on two of my systems that I do major development work on. This turned out to be a painful mess that ate several hours of my time that day. If you ever decide to install VS 2005 SP1, plan to have an hour or two of time to waste ahead of you… (at least in my case, I learned from my mistakes of expecting a reasonable setup user experience the first time around and was better prepared for the second system that I had to install SP1 on).

Specifically, I ran into several different issues during setup. First of all, it was slow, and by slow, I mean slow. It took something on the order of 15-20 minutes just to get through the Windows Installer initialization dialog, during this time it was pegging CPU and I/O for my box, thus making it fairly unusable. The computer that I was installing VS 2005 SP1 on may not be the latest and greatest, but I should hope that it should be possible for one to design a setup package that won’t totally destroy the performance of a 1.5-year-old top-of-the-line laptop for 15 minutes during setup initialization. (It’s worth noting that the original installer for VS 2005 didn’t have this problem, nor did the installer for the Vista Platform SDK, the Vista WDK, Office 2007, or any of the other programs I’ve ever installed on my box.)

As if making my system unusable for 15 minutes wasn’t bad enough, there is a nice little confirmation dialog box that asks if you really want to install VS 2005 SP1 which occurs after you just had to spend 15+ minutes staring at a dialog that doesn’t update with progress information in any meaningful fashion. (Or more likely, after you have given up waiting and went to do something else while setup finished doing its thing. This is particularly frustrating, since given a setup program that is just sitting there grinding away without any UI feedback, as an end user you are very likely to just go read a book, strike up a conversation, or do something else besides just stare at your screen for minutes on end with nothing visibly happening. It would be okay if setup prompted you to continue before it decided to just waste 15+ minutes of your time. As it stands, resist the temptation to leave your computer completely unattended, or you’ll just come back to a dialog box that was preventing the bulk of setup from completing, meaning you’ll have even more wasted time waiting for setup to finish ahead of you.)

By this point, I was already thinking that this setup experience was downright terrible, but the worst was yet to come in this setup story of sorrow. It turns out that setup (undocumentedly) likes to use ~2.5GB or so on your system partition (even if all of your Visual Studio / Platform SDK products are installed on a different partition). Unfortunately, nobody bothered to mention this anywhere in the release notes at the time when I started my installation, and setup doesn’t even bother to check for the amount of free space ahead of time. To make matters even worse, you are most likely to run into this problem after the 15+ minute initialization period, which makes it all the more painful if it causes your setup instance to completely fail, as described below. It turns out that if setup runs out of space at a particular moment in time, you may get stuck at a abort/retry dialog asking you to free more space. However, in at least one instance of running out of space (which I hit several times in the course of trying to free up enough space on the partition that setup shouldn’t have even been touching), setup gets broken and will just refuse to continue to copy files. If you click “retry”, you’ll simply get the same out of space dialog again (regardless of whether you have actually freed up the necessary space), and your only option from that point forward is to cancel setup (which takes another 10 minutes to finish rolling back) and restart it (which will, again, involve at least 15+ minutes of waiting before a confirmation dialog). It should be noted that the second time setup failed due to out of space, it did properly recover after I told it to retry, so it seems that only certain parts of setup get into this non-recoverable state where an out of space error is really fatal.

After repeatedly hitting the out of space error, I was rather interested to find out just why setup needed 2.5GB of space on my system partition despite the fact that VS 2005 was installed on a different partition. It turns out that most of the space requirement comes from the fact that the ~450MB installer makes no less than three copies of itself in your %TEMP% directory during setup (look for 450MB .msp files in %TEMP% while it’s running), even if the original .msi was present on a local hard drive and not a removable storage medium. Furthermore, setup will then need to make a fourth copy of the .msi in your %SystemRoot%\Installer directory for permanent storage in case you need to make modifications to your VS 2005 SP1 install without having the original .msi present. Now, I am certainly no expert in MSI-based installers, but it seems to me that making four copies of a 450MB installer file in your system partition is just ever so slightly excessive…

There are certainly some cool features and bug fixes (especially relating to PGO) in VS 2005 SP1, such as an ASLR-aware linker that make it a compelling upgrade, but I give the setup experience a failing grade. It’s by far the worst that I have ever seen out of any shipping Microsoft product to date.

I found this little gem in the VS2005 documentation for /W4:

Level 4 displays all level 3 warnings plus informational warnings, which in most cases can be safely ignored. This option should be used only to provide “lint” level warnings and is not recommended as your usual warning level setting.

For a new project, it may be best to use /W4 in all compilations. This will ensure the fewest possible hard-to-find code defects.

Whoops. Time to file a documentation bug.

It is the little inconsistencies like this that really contribute to the perception that MSDN is difficult to understand and use, I think.

While trying to identify just what kind of device Steve’s Mac appears when plugged into my laptop over a 1394 cable, I ran into this charming result from Google:

“Performance of 1394 devices may decrease after you install Windows …” [support.microsoft.com]

I don’t think that is what they really meant to say. I suppose Google summaries can be bad at times…

This is but one of many strange or poorly designed things I’ve encountered in the past few days…

I’m going out to Redmond for this coming week for a Vista compatibility lab focused on helping ISVs with getting their applications running well on Vista. I’ll try to keep the blog updated with anything interesting that I find out on the way. Besides the standard stuff about UAC and non-admin users, I’m hoping to get some more obscure and difficult things cleared up that I have thus far never really got an answer to, such as how some of the UAC changes to how tokens work will affect the ability to alter network credentials of running processes.

Finally done moving stuff to my new place, as of yesterday. What a pain. Moving mattresses without a truck is certainly fun stuff . . .

In any case, I should now have some time to get back to the regularly scheduled blog posts – sorry for the gap in content there.

Here’s an index of all of the x64 debugging topics I have covered thus far. This series takes you through the experience of doing user mode debugging on x64, including native x64 debugging, Wow64 debugging, and the various different combinations of 32-bit and 64-bit debuggers that you’ll find available to you on a 64-bit machine (and when to use which one).

1. Introduction to x64 debugging, part 1
2. Introduction to x64 debugging, part 2
3. Introduction to x64 debugging, part 3
4. Introduction to x64 debugging, part 4
5. Introduction to x64 debugging, part 5

Ed: This was back-posted to appear after the last x64 debugging posting for sorting purposes.

It’s official – I’m a Microsoft SDK MVP!

This is a pretty cool experience, and I’m really looking forward to expanding my knowledge with the resources that being an MVP makes available to you.

Besides the blog, you can often find me on the Microsoft public newsgroups (e.g. microsoft.public.development.device.drivers) and the OSR mailinglists (e.g. NTDEV), where I’m a frequent poster.