This is a most excellent place for technology news and articles.
Raymond's book is an amazing read and full of stories very much like this one.
The answer:
The device local name string is specified to be encoded in UTF-8. However, the Microsoft Wireless Notebook Presenter Mouse 8000 reports its name as Microsoft⟪AE⟫ Wireless Notebook Presenter Mouse 8000, encoding the registered trademark symbol ® not as UTF-8 as required by the specification but in code page 1252. What’s even worse is that a bare ⟪AE⟫ is not a legal UTF-8 sequence, so the string wouldn’t even show up as corrupted; it would get rejected as invalid.
Thanks, Legal Department, for sticking a ® in the descriptor and messing up the whole thing.
There is a special table inside the Bluetooth drivers of “Devices that report their names wrong (and the correct name to use)”. If the Bluetooth stack sees one of these devices, and it presents the wrong name, then the correct name is substituted.
That table currently has only one entry.
I mean, I don't get how it's legal's fault when they're not the one's creating the firmware/programming, but sure let's blame them. It's the dev who verbatim copied and pasted the name from legal for whatever reason (even though a normal person wasn't going to check the firmware to see it).
While I don’t know this is the case, I can say from experience that in large enterprise organizations compliance departments will and do actively prevent the release of features and even commits if they don’t comply.
While that’s not an excuse for challenging them, I could definitely see a stressed out mid level just trying to make there manager happy and move on with life.
Good explanation. Thank you.
"the Microsoft Wireless Notebook Presenter Mouse 8000 reports its name as Microsoft⟪AE⟫ Wireless Notebook Presenter Mouse 8000, encoding the registered trademark symbol ® not as UTF-8 as required by the specification but in code page 1252" is a sentence that seems to have come straight from unix_surrealism
Well, there's plenty of standards-noncompliance out there, but breaking the firmware of a peripheral you manufacture so that it can't be properly supported by the OS driver you wrote and needs a workaround requires a special type of corporate boneheadedness.
The stupid, old, irritating cycle of: You implement against a standard, and then you implement exceptions for third party users of the standard. 😔
But in this case it's first-party, and they still had to make an exception
Leave it up to microsoft to screw up even something that simple.
This sounds like someone said, I only changed some text, we don't even need another round of testing.
You spelled Microsoft® wrong. 😂
How big is the company you're working in?
In my experience that's just a corporate thing.
