At one point, I changed the password for my bank, and then went in to update the corresponding password in Microsoft Money so I could continue to download statements. Unfortunately, upon entering the password, I was met with this error box.

Here is a product, which is charged with protecting my most important data, and it is telling me that it can't accept a password which any typical computer-savvy user would consider a normal "strong" password. After seeing this message, my brain stopped working. If anything, a product which deals with access to someone's money should favor the uber-paranoid side of the security fence. But here was a product that actually limits a password's complexity and forced users to a weak one.

I can understand reasonable limits on length as there may be storage or processing concerns (I've run into web sites where an eight-character password was too long, and no, that is not a reasonable limit). But if you are working on the password-processing feature of your software, gimping a password's strength is something that should be avoided at all costs.

As an aside, you can use this utility to help gauge whether or not your password is strong.

The magic part is where we OR in the original attributes with a bit mask of 0x00F0 which just keeps the BACKGROUND_* values intact. The un-obvious (and extremely useful) thing to note, is that the original background will be kept intact even if it can't be expressed in the provided 4 bits of information (i.e. the user has defined a custom color using a 24-bit RGB value).

When looking at your automation ask yourself these questions:

• Are my tests focused on the functionality which users care the most about? Figure out what matters the most to users. If users spend 80% of their time in one area of your product, that is where 80% of your testing should be as well.
• How much time (both development-time and execution-time) is invested in edge/corner cases versus actual user scenarios? A finely-tuned unit-test suite is a great thing to have, but is not a substitute for actually testing the software. It is just too easy to spend more time adding variations and more test cases that don't offer any additional benefit.
• Does the automation correctly hit all the same code paths under the same environmental situations? If your automation is relying too heavily on internal hooks at lower levels, it might not be exercising the software the way a user will be. Any deviation will reduce the effectiveness of the tests.
• Are test cases executing in a "pristine" state? Often tests are run on a clean system, after a fresh install, utilizing perfectly scripted steps over clean data. Users don't work like that. Run tests under a heavily loaded system. Intermix test scenarios to mimic the user moving chaotically through the software. Use real-world data sets. Then on top of all that, throw in some task-switches, network fluctuations, etc.

To make customers happy, you need a way to quantify how Customerized your tests are. If the "how testers test the product" circle fully overlaps the "how a customer uses the product" circle, then your tests are highly Customerized, and you will have a better chance at satisfying your customers.

Below is some batch code which will take a two's-compliment value, and print it out as an unsigned hexadecimal value. The basic algorithm is not very difficult (see 'hexloop' below): take the "ones place" digit off (by mod 16) and stick it in the result, then divide the input down by 16 and repeat. The tricky part comes when we have a negative value and thus need to deal with unsigned values that go beyond the range of a positively signed 32-bit value.

To deal with this we first figure out how far past the MAX_INT value we are (stored in _offset). We then break the number into two parts so that we can operate on them in the positive side of a signed variable. Into each part, we then need to add in the equivalent (also broken apart) MAX_INT pieces. The first part (the first digit) is handled immediately; for the remaining digits, we just fall down into the normal processing loop. Note that we are using the ! syntax for variables inside the 'if' statement as that helps keep the processor from getting confused.

The 0xC… values are NTSTATUS codes, so if you happen to see other values in that range you know where to look them up.

In the above sample, the quotes around the filename are removed (the search pattern is located between the colon and the equal sign, and the replacement pattern is located after the equal and before the ending percent sign – which is empty in this case).

I recently had a need to replace the beginning portion of a path name, with a different directory. But, unfortunately, I wasn't able to use hard-coded pattern strings as the both the initial directory and the replacement were unknown beforehand. This meant that I was left with the unfortunate task of trying to use an environment variable inside of the replacement syntax. Needless to say, nesting % signs didn't go very well for me.

Luckily, there is a mode of cmd.exe which support delayed environment evaluation, and offers a new syntax for evaluating the environment variable.

When /v is passed into cmd.exe, it allows you to expand environment variables using ! instead of %:

Using both forms of expansion, I can nest one inside of the other, allowing me to use a variable for both the search string as well as the replacement:

As an aside, here is a little test which will let you determine if /v is enabled or not:

Given this, you can imagine the distaste in my mouth when I encountered a DB_E_ERRORSOCCURRED (0x80040E21) error while just trying to open an Access database using OLE (via CDataSource/CSession). I get this error back with no fanfare about what the actual problem is. The connection string used looked something like this:

After blindly fishing around, I narrowed it down to the actual password that was the issue. If I disable the password protection on the database, I could connect just fine.

After hacking around some more I discovered that it is the length of the password (and not the any specific characters) which cause the open operation to fail. My life could have been so much happier if I had received a specific error message, or even an overloaded one which would help point to the length of the password as an issue. Looking through the standard windows headers, there are a handful of existing errors that would have been much nicer to see than an "errors occurred" message.

So, if you happen to run into this error code yourself, you may need to shorten the password to fewer than 20 characters.

You need to link with the VC8's libs.

Ok, great, now what does that mean? Is that version 8.0 (as reported by the binary)? Is it "Visual C++ 2008"? One could go mad trying to understand that each version has three different ways to identify and name it. To simplify my own life, I've created a chart with the last handful of versions and their equivalent names, hopefully this will be useful to others as well.