Why are Bluetooth functions exported from the infrared control panel?
Remember infrared communications?
Okay, maybe you don’t. It was a thing for a while in the late 1990’s and early 2000’s, but it never really caught on, and it became overshadowed by other short-range wireless communication mechanisms like Wi-Fi and Bluetooth.
If you peek inside the the infrared control panel
irprops.cpl, you’ll see that it exports a ton of Bluetooth functions. What is Bluetooth doing in the infrared control panel?
Rewind to 2004. Windows XP Service Pack 2 was under development, and one of the features being added was support for Bluetooth. However, at the time, the service pack rules prevented adding new DLLs to the system. The Bluetooth folks had to squeeze their new APIs into the existing infrared control panel.
The restriction on introducing new binaries to the system was subsequently lifted, but the functions had to remain in
irprops.cpl for compatibility. Those functions nowadays merely forward to the implementation in the real Bluetooth DLL
For over a decade, the documentation has exhorted people to use
bthprops.lib rather than
And finally, the Windows SDK pulled the plug. It no longer includes a copy of
irprops.lib, thereby removing the temptation to link with the wrong library. If you want to call those Bluetooth functions, link with
Note that if you do this, your program won’t run on Windows XP Service Pack 2, because Windows XP Service Pack 2 doesn’t have a
bthprops.cpl. For the hopefully none of you that are developing software to run on Windows XP Service Pack 2 (and really, who are you people?), you can copy
irprops.lib from your Windows XP SDK and link with that.
Bonus chatter: Why not just ship
irprops.lib as a duplicate of
bthprops.lib? That way, people are silently upgraded to the correct library.
Sure, that would silently upgrade people to the correct library, but it also means that if you are one of those hopefully none of you that is writing code that intends to run on Windows XP Service Pack 2, your code silently broke: Your program that used to run on Windows XP Service Pack 2 no longer works, and there was no warning or error message anywhere along the way.
We decided that it was better to make the break obvious.
> However, at the time, the service pack rules prevented adding new DLLs to the system.
What was the reason for this restriction? Trying to prevent application dependencies on a specific service pack? Or maybe something around simplifying updates and rollbacks?
No idea. If I had to guess, I would guess it was a limitation of the Windows Update infrastructure: Perhaps it knew how to update files, but not how to create new ones. (Because what’s the version number of a nonexistent file?)
If I were in charge of things, ther version number of a nonexistent file would be 0.0.0.0, but somebody somewhere has used negative version numbers that would appear to be older than a nonexistent file.
That is not how update.exe works AFAIK.
I thought IR was popular in Japan for exchanging contacts on phones.
My first laptop have IR port too. Unfortunately IBM only provide driver for Win2k and I’ve chosen to install Win98 instead, so the IR port never really have any use.
Luckily I am able to require Service Pack 3 when targetting Windows XP …or POSReady 2009 actually.
I’m one of those who test their programs for compatibility with at least Win2k (and sometimes Win9x as well). Obviously, not as part of my job but for my pet projects. After all, the effort put into making Windows backwards-compatible should be used by someone. It’s just cool to see your program run on any NT-family Windows version (or even any 32/64-bit Windows version) ever existed. It is twice cool to feel that you support the Windows platform completely, unlike so-called “cross-platform” toolsets that barely support a small subset of each platform.
<OffTopic>When will the suggestion box be open again? I have a question about the treatment of the first character in a window title that doesn’t seem to be explained anywhere and might be a good story about compatibility.</OffTopic>