Why is the name of the Microsoft Wireless Notebook Presenter Mouse 8000 hard-coded into the Bluetooth drivers?
81 points by polywolf
81 points by polywolf
A developer’s maxim:
Live your life in such a way that you do not create material for a Raymond Chen blog post.
Last time I was at Build in-person, I made sure to go to the session that was basically just “Raymond Chen tells stories for half an hour”, and it was 100% worth it.
“That table currently has only one entry.”
I would have guessed there would be many other blunders.
The only thing worse than finding your mistake written up in a Raymond Chen blog post is finding yourself being the only example of such a mistake.
There likely are many other instances of this kind of blunder, but this one probably is the only one comitted by a team with enough influence at Microsoft to get the people responsible for the bluetooth driver to change their code.
I think there are other such devices, just not necessarily Bluetooth ones. ISTR that my Microsoft Laser Mouse has the same wrong registered trademark character, but it’s wired, and Mac OS X apparently didn’t care.
There probably were, but the authors of the driver didn’t prioritize adding then to the table.
Linux drivers also contain a staggering amount of code for handling hardware quirks. It’s like a huge database of hardware defects which must be worked around in software, neatly organized by device identifiers. The hardware world is really ugly.
I wonder if it’s been deliberate choice to make these hacks and fixes instead of having the device makers fix their bugs. The end result is that on Windows everything works thanks to the hacks, and on other OS:es it’s hit or miss if any given device will work or not (unless the OS developers spend a lot of time replicating Windows’ hacks and exceptions).
I mean, if the bug’s in hardware that’s already been mass-produced, there’s not much you can do.
In particular, while you could fix hardware manufactured after the bug is located, arguably you’ve now made things worse - at least before, the behavior exhibited by something with a given hardware ID was consistent. But if you fix in the middle of production, now some devices with that hardware ID are buggy, and some aren’t. (I guess you could change the ID? But I don’t know if that causes other issues…)