Fun with icons and Vista compliance

 Fun story today about that time I tried to make my company's program comply with the Vista requirements. Spoiler alert: it's literally not possible to comply with Vista requirements.

At the time I worked for WildTangent, a leading provider of games and a nifty game-catalog program that many companies pre-installed on their computers. We also did 3D on the web before realizing that the market for 3D on the web was very limited :-(

Vista had the noble and sensible goal of getting companies to stop using weird, undocumented hacks (read The Old New Thing for many, many blog posts by Raymond Chen about compatibility). Enter a Vista requirement: "Everything must follow the written standards". 

Vista also wanted to be big, fresh and exiting. And in Vista, that meant "large icons". Windows programs were accustomed to making tiny little 8x8 and 16x16 icons. These were appropriate for the tiny screens of the time, but in the Vista timeframe more and more people were getting big monitors.  Enter our second requirement, "all Vista programs must include a 256x256 icon".

And the last bit of knowledge: the officially documented Icon spec in Windows is clear about two things: the icon's size must be included and fit into a 1-byte field, and that there is a limited number of valid icon sizes. 

Both of these are problems. A value of 256 (for a 256x256 icon size) is to large to fit into a 1-byte field. In practice, Windows code just decides that a value of zero means 256, but at the time it was completely undocumented. The icon size of 256x256 not being on the official list of acceptable icon sizes was just the icing on the cake, as it were.

The Microsoft response? They didn't care. 

 

Your Bluetooth is bad, August 2026 (Battery and Name)

 Your Bluetooth is bad, and you should feel bad

Alternate title: Your Bluetooth is OK, but it could be better

 Just two gripes this time!

Always include a name. 

I'm looking at you, Ruuvi. The Ruuvi sensors are interesting little devices. They started out back when the Eddystone protocol was an exciting new thing (fun fact: Copilot thinks there are still major Eddystone devices in the real world!), then made essentially the same sensors but with their own advertising format. And the Ruuvi company includes good documentation on their GitHub!

But ... why don't the tags advertise their names? Normally the way my app can tell one device from another is just from the name (and so far, without any overlaps) or for standard devices like Bike sensors, from the services exposed. Now I have to paw deep into every advertising packet just to see if an advert might be from a Ruuvi.

Use battery percentages, not voltages

Providing a battery voltage and not a percent, IMHO, is just weaseling your way out of a small bit of analysis. And it's an analysis that you, the maker, can do best.

There is no user out there who wants to know that the battery is at 2.45 volts. But everyone wants to know if the battery is running low. You can either do a conversion in your app, or you can just do the conversion on the device.

Not only that, but end users just expect a "ballpark" figure. This is confirmed by Microsoft, which expects devices to provide 11 steps (0..100% in 10% steps including the 0 and 100), and by the Bluetooth SIG which made the standardized battery levels.