This time, I've added the support for the Broadcom (formerly Widcomm) stack on the Windows Mobile side.

This should add support for the Motorola Q9, which uses this particular stack.

On the stability and compatibility side, I've only tested on a version of the widcomm stack for the HTC Wizard, but only on WM6 and I don't know if it actually works on other devices :)

If it works for you, please let me know !

Download Bluetooth Remote Control 0.8.3 now !

If you ever want to install the Broadcom stack on WM6 for the HTC Wizard and you get a "Not enough driver memory", try changing the "StackMode" value from "0" to "1" in HKLM/Widcomm/BTConfig/General. It worked out for me :)

C++, my almost favorite language. This language had good intentions, really. But this is such a pain -- a  pit of despair -- to have to deal with library compatibility and compilation parameters matching issues, where it should be handled by the system.

Anyway, if you're trying to use the Broadcom Bluetooth SDK for Windows CE with VS2005 or VS2008, you might encounter this pretty message :

error LNK2019: unresolved external symbol "__declspec(dllimport) public: int __cdecl CRfCommIf::SetSecurityLevel(wchar_t *,unsigned char,int)" (__imp_?SetSecurityLevel@CRfCommIf@@QAAHPA_WEH@Z)

The symbol actually exists in the broadcom provided library (BtSdkCE30.lib or BtSdkCE30.lib)  but is defined like this :

SetSecurityLevel@CRfCommIf@@QAAHPAGEH@Z

which, undecorated, means :

int CRfCommIf::SetSecurityLevel(unsigned short *,unsigned char,int)

See the difference ? The wchar_t type the compiler is using should be an unsigned short. Basically, both types are binary equivalents but the compiler is treating them as different, hence the different signature.

To fix this, just set the option "Treat wchar_t as Built-in Type" to No.

This way, the wchar_t will go back to being a short, and then match the method built in the static library.

I'm going back to my C# code, now.