Plagued by constant trouble with my Logitech mice I recently decided to check for a new version of the infamous SetPoint (infamousness is inheritable). Having been using SetPoint 4.8 I was pleasantly surprised at the double major version jump - despite longstanding experience that new versions hardly ever deliver a net benefit. Maybe it's the profession of software engineering where "this bug is fixed in the latest version" is not only an illusion but the safeguard of your paycheck. But I digress ... Let's just say I was enthusiastically optimistic.

Both my enthusiasm and my optimism were reinforced when my Cordless Optical TrackMan, for which I was already applying for a South European citizenship (you know, because of how often they strike ...), suddenly started working again. The setup program promising to do away with the annoying-to-death and premature battery warnings, and the user interface looking cleaner and feeling less sluggish was just the icing on the cake.

Understandably enthusiastic (and optimistic) I started redoing my settings and soon started noticed that an elementary feature had died the feared death through ominous marketing decisions; the little check box to switch the left and right mouse buttons on a device-by-device basis. The only way to swap the buttons now was Windows' own control panel dialog, which, just as ominously, affects all the mice connected to the system.

"What's the big deal? How many mice do you need for one computer?" you say? The answer is at least two if you're ambidextrous or suffer from mouse overuse syndrome (and at least three if you count the one on the sofa for when you hook up your PC to the TV).

Slightly less enthusiastic (but still optimistic) I decided to e-mail Logitech customer support. I had heard lots of good things about them, plus it's educational to use your own company's customer support, so you can see it the way ordinary customers do.

It only took a few hours to get a response. The friendly support guy told me that he had also failed to accomplish what I was trying to do and that the only solution was to downgrade to SetPoint 4.8; not exactly what I had in mind.

I don't give up easily though. I was already contemplating writing an HID filter driver when I thought of uberOptions, a very dedicated and inspiring project that is the rescue of all people who feel that after buying an expensive input device they deserve to do with its buttons what they want.

Even though SetPoint 6 is not officially supported yet it worked great. After a quick installation I finally got my 'Swap buttons' check box back:

And I clicked happily ever after ...

There's a side story to this one, which is that my MX Revolution mouse recently started refusing to charge, which seems to be a common problem. Luckily, for now, I haven't had to use the soldering iron. Instead, cleaning all the charging contacts and taking out and replacing the very same battery (easy to do; the four screws are under the little rubber pads) seems to have helped.

So, in just a few days I went from having two expensive designer paper weights on my desk back to my proven "2 Logitech mice + 1 Microsoft keyboard" sandwich.

PS: I was trying to find some statistics to confirm my conviction that the French, Italian, Spain, and Greek without a doubt must lead the strike statistics only to be heavily disappointed by the real numbers. But, as one of my friends likes to say, don't let the truth get in the way of a good story. :-)

I have ranted previously about people not being able to read attentively when they're trying to solve problems. Here's another one:

A few years ago I helped teach a class on information systems, namely I was in charge of the fun part - a project where students had to write their own web application.

Because lack of documentation was always the part that bugged me most about projects when I was a student myself I spent a great amount of time writing the project material and how-to guides for the software we were using. After the class I mirrored the material on my own website. (Yes, I'm proud of the project being a success.)

Now, for some reason one of the how-tos shows up quite high if you search Google for words like "postgres fuzzy string matching". At one point it tells students:

[...] if you want to use these functions in your database please send a quick e-mail to Martin so we can activate it for your databases.

And they do! Today is the second time I got an e-mail from some random person (this time a student, last time a post-graduate!) asking me to please enable fuzzy string matching in their database. It looks something like this:

Dear Mr Martin Rubli,
I want to use fuzzy string matching in my database. Can you activate it for my database ?.
I hope to hear from you soon. Thank you.

There are several things that strike me here. The first one is that it should be pretty clear from both the URL and some of the text that this is class material, not some generic tutorial. Then, why do those people think I'm running a charitable Postgres fuzzy string matching activation service instead of just posting the simple instructions on my website? And finally, let's assume I had such a magic service, am I supposed to guess the server addresses and the access data?

I think the message is clear here: If you want me to enable fuzzy string matching in your Postgres database, for god's sake include some IP addresses and credentials, so that I can have some fun with them! :-)

If you thought buying a new computer and installing a fresh copy of the latest and greatest (only in terms of disk space usage, obviously) Windows Vista is a good start for productive computing then you obviously haven't reckoned with Microsoft's talent to break the simplest of features.

While setting up my system I eventually noticed some strange behavior: The startup programs that I had placed into the start menu were not executed. On the other hand, some startup programs seemed to be executed twice; in my case I ended up with two OneNote icons in the tray bar.

I didn't make the connection at first but a closer analysis showed that the links in

C:\Users\martin\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup

were not executed on log in whereas the ones in

C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup

were executed twice.

A quick scan of the registry (which brought up a whole new bug, but more about that in the next article) quickly found the reason of this strange behavior.

In the

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders

path there is an entry called Start Menu, which, in my case, contained the following, erroneous path:

%ALLUSERSPROFILE%\Microsoft\Windows\Start Menu\Programs\Startup

This obviously makes no sense because, as the registry path already indicates, these are the User Shell Folders. All the other entries in the same registry location were correct though.

The fix was trivial, I simply just replaced it with the following:

%USERPROFILE%\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup

Sidenote: There's a second registry location that also contained the wrong folder, though as a REG_SZ instead REG_EXPAND_SZ string and therefore without the environment variables:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders

Changing that one alone didn't have any immediately visible effect but to be on the safe side I would recommend changing that too.

It's also funny to see that when you right click the Startup folder in the start menu and choose 'Open' or 'Open All Users' Explorer doesn't seem to retrieve the path from any of the above registry locations.

How the wrong path had gotten there in the first place is beyond me. But when I started thinking about it I suddenly remembered that I had fixed the exact same problem at one point during my very first Vista experiment. Apparently more than a year and one service pack later things haven't changed. Let's wait for Service Pack 2, maybe that will ... Nah ... Put a lid on that hope's coffin and nail it shut. Six (6.0?) feet under is where Vista hopes are at home.

"ASUS Networks - Built to connect ..." Well, temporarily.

When I buy a network card there's one thing, above all, that I want it to do: connect and stay connected. Is that too much to ask for? Apparently it is when you buy an ASUS NX1101 and try to run it on a 64-bit Windows Vista.

It all started so well. After being scared off by the prices of PCIe network cards I decided to go with a good old PCI one. I bought it and headed home. After a quick search on Windows Update Vista automatically downloaded and installed the drivers. That's how it should be.

The next time I my computer wakes up from hibernation the first surprise. No network. Been there, done that, so I restart the Corega wireless/Ethernet router (necessary about two to three times per week even with the latest firmware) and try again. Nothing. Even pinging the router doesn't work. Only disabling the network and reenabling it brings the connection back to life.

Unfortunately it's not a one time thing, it's reproducible every single time, but not on XP 32-bit. So I start looking for an updated driver and, of course, I find one on their website. Actually, I find two of them - only ASUS knows why, - so I take the newer one because the older one is identical to the one that Windows downloaded automatically.

In an optimistic mood I start installing it but after a while Windows complains the driver is not intended for my platform. I double check that I have the right driver but the folder name says 64-bit and the INF file looks okay. Awesome.

More or less by accident I notice something:

That's right. The driver binary is 0 bytes in size. Either this is just the slimmest driver ever or somebody at ASUS' quality assurance lab must have a very sound sleep. And some other people too given that the "driver" has been online for about four months.

Being a driver developer myself I'm pretty understanding when it comes to power management bugs, but putting up a zero byte driver is far from excusable. Especially if the support form and live chats don't work.

Today I brought my card back to the store and got a new D-Link one (DGE-530T). So far it works like a charm, even after hibernating.

There's an upside to the story though: Apparently my Chinese, limited as it is, is now good enough to get a broken network card exchanged and buy a new one. By the amount my confidence in ASUS has shrunk my self-conficence has grown. That's not half bad. :-)

The syntax of the INF files controlling Windows driver installation can be a little tricky at times. In this particular case I was trying to add a registry key whose value contains some quoted paths. It took me several attempts to get it right and the help on INF strings sections was also rather cryptic and not very helpful with its lack of examples.

I wanted to create a key with the following value (of course the actual example was slightly different but this will do to illustrate the problem):

"C:\Program Files\MyTool\Run.exe" -datadir"C:\Program Files\MyTool\data\" -debug -title"MyTool" -verbose

Here's the solution (or should I say: the closest I got):

[MyTool.Addreg]
HKLM,Software\Me\MyTool,Command,0x00000000,"""C:\Program Files\MyTool\Run.exe""" -debug -datadir"""C:\Program Files\MyTool\data\""" -title"""MyTool""" -verbose""

The documentation states:

[...] any string [...] that is itself a quoted string, must be enclosed in a pair of double quotation marks characters [...]

The INF parser not only discards the outermost pair of enclosing double quotation marks for any "quoted string" in this section, but also condenses each subsequent sequential pair of double quotation marks into a single double quotation marks character. That is, """some string""" also becomes "some string" when it has been parsed.

The second paragraph is slightly beyond my understanding, in particular considering some of my intermediary test results that you can find at the bottom.

The first paragraph at least explains the double quotes at the end. Inside the string all quotes also need to be tripled.

The beginning of the remains somewhat of a mystery to me. The triple quote at the beginning of the string is converted into a single quote in the registry.

To make matters worse, Microsoft's own ChkInf, which comes with the DDK, doesn't like any of the working solutions. It doesn't accept any less than four quotes at the end of the string. However, with more than two quotes at the end of the string, the resulting registry ends up containing a trailing quote. Anything with two or fewer (one and zero also work but at least seem syntactically incorrect to me) works fine with regard to the end result.

As I promised, here are some of my intermediary results. The slightly simplified AddReg commands and the corresponding result behind the semicolon:

HKLM,,TestA,0x00000000,"""Some string"""              ; "Some string"
HKLM,,TestB,0x00000000,""Some ""quoted"" string""     ; Some string
HKLM,,TestC,0x00000000,""Some "quoted" string""       ; Some string
HKLM,,TestD,0x00000000,""Some \"quoted\" string""     ; Some \quoted\ string
HKLM,,TestE,0x00000000,""Some """quoted""" string""   ; Some "quoted" string

Is anyone wondering why Microsoft didn't just adopt the syntax of one of the many programming languages out there where similar problems are unheard of? The developers could have just copied the code from MSVC (or any of the other hundreds of MS implementations of the same algorithm) and users wouldn't have to even read the documentation. But heaven forbid a win-win situation!

There seem to be many ways to detect the Windows version (e.g. XP vs. Vista) from a batch file, some of them fairly complicated. It's not exactly as easy as it should be because there's no decent environment variable and the output of ver is difficult to parse.

However, I found the following to work just fine:

: OS detection
for /f "tokens=3" %%i in ('reg query "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion" /v CurrentVersion') do (
	set WindowsVersion=%%i
)
if "%WindowsVersion%"=="5.1" set IsWindowsXP=1
if "%WindowsVersion%"=="6.0" set IsWindowsVista=1

: Show some debug information
echo Windows version: %WindowsVersion%
if defined IsWindowsXP echo IsWindowsXP = true
if defined IsWindowsVista echo IsWindowsVista = true

There's a pretty good tutorial from Microsoft (what do you know, they do like open source ;-) about how to integrate Flex and Bison into Visual Studio:

Understanding Custom Build Rules in Visual C++ 2005: Building Flex and Bison Files from the IDE

Unfortunately I ran into a problem after integrating it into my project. Flex kept crashing with the following output:

1>------ Build started: Project: MyProject, Configuration: Debug Win32 ------
1>Generating lexical analyser...
1>flex: fatal internal error, exec failed
1>Project : error PRJ0002 : Error result 1 returned from 'C:\WINDOWS\system32\cmd.exe'.
1>Build log was saved at "file://C:\MyProject\Debug\BuildLog.htm"
1>MyProject - 1 error(s), 0 warning(s)
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

Some experiments showed that Flex was unable to find M4 (i.e. m4.exe) and then crashed with the above not-so-helpful error message.

The workaround is easy: Make sure that either m4.exe is in the path or set the M4 environment variable. Since I use a somewhat special directory structure for Flex, Bison, and some other tools I already had a wrapper script in place, so integration was easy:

: Wrapper script for Flex
:
: This script sets some environment variables that are required for Flex to
: find all its libraries and helper files/tools.

@echo off

: Determine the path of the wrapper script
set GNU_PATH=%~d0%~ps0

: Set PATH for cygwin1.dll and M4 for the M4 tool itself.
: If we don't define M4 Flex fails with the following error message:
: "flex: fatal internal error, exec failed"
set PATH=%GNU_PATH%\lib;%PATH%
set M4=%GNU_PATH%\bin\m4.exe

: Launch the real Flex executable with the same arguments
%GNU_PATH%\bin\flex.exe %*

In case you're wondering, the directory structure I'm using looks something like this:

%GNU_PATH%
¦   bison.cmd
¦   flex.cmd
¦
+---bin
¦       bison.exe
¦       flex.exe
¦       m4.exe
¦
+---lib
¦       cygwin1.dll
¦
+---share
    +---bison
        ¦
        +---m4sugar
                m4sugar.m4

You can see the two wrapper scripts at the top level.

For completeness' sake the wrapper script for Bison, which defines one additional variable, so that Bison can find its M4 helper files:

: Wrapper script for Bison
:
: This script sets some environment variables that are required for Bison to
: find all its libraries and helper files/tools.

@echo off

: Determine the path of the wrapper script
set GNU_PATH=%~d0%~ps0

: Set PATH for cygwin1.dll, BISON_PKGDATADIR for the M4 meta files
: and M4 for the M4 tool itself.
set PATH=%GNU_PATH%\lib;%PATH%
set BISON_PKGDATADIR=%GNU_PATH%\share\bison
set M4=%GNU_PATH%\bin\m4.exe

: Launch the real Bison executable with the same arguments
%GNU_PATH%\bin\bison.exe %*

By the way, if you use Lex in your Visual Studio project, you may also want to check out this article which documents a bug in Microsoft's original FlexBison.rules file.

Not only is the new user interface in Office 2007 one of the biggest usability steps backwards I've ever seen in a Microsoft program, the implementation of the new look seems to have a few interesting "features" like this one:

That's right. This is my Excel window the way it shows up about 70% of the times I launch it. The "feature" auto-enabled itself a few weeks ago and hasn't gone away since. The only solution? Restart Excel a few times and trust the law of probability--praised be my beloved keyboard shortcuts.

Creating a community website is not only quite satisfying because you get to see how customers actually use your products, sometimes it's also quite funny. A few weeks ago Logitech launched the QuickCam Team website which targets developers and users of webcams on alternative platforms and just by looking at it it should be pretty obvious that we don't do product support. (And if it's not obvious enough there's a big fat note on the contact page.) Nevertheless, some people try their luck by reporting random, completely unrelated issues that are poorly phrased and impossible to understand. Here's a funny example:

Subject: Logitech QuickCam 4000

Can you please give me detailed instructions on how to make it impossible for anyone to change my password or otherwise get around it? This is urgent. Thank you.

Somewhat confused by the subject I assumed that the person was referring to her newly created account for the QuickCam Team forums:

I neither understand the subject of your e-mail nor the idea behind your request. What are you trying to achieve? What do you mean by "get around it"?

And once again, the response was no less confusing than the original e-mail:

I created a password for access to the camera images. Now the password box will not recognize my password.
This problem is preventing me from shutting down the computer. I cannot close the image studio, nor shut down the computer.
How can I permanently erase the password?

Part of me wants to help a confused user but a much bigger part of me wants to actually see the live stream from her webcam showing her sitting in front of her computer that apparently doesn't shut down because she forgot the password to a long obsolete piece of software. Not because I like seeing desperate users or because I hate technically challenged people, but because people need to learn to read. If your butcher has a sign outside that says "I don't bake bread" you don't go inside and ask for croissants. Using a computer is not like watching TV. It needs many skills, and reading is the most important one.

Read carefully and think about it for a while:

There are so many aspects of this dialog box that I don't understand, it's not even funny. How about freeing up some space by uninstalling the very cause of this dialog box?