See information and features in General
Note that starting to use Widcomm is not as easy as the other stacks, as unfortunately a native DLL (or two) is required as well as the normal managed library assembly -- that's because its API is C++ and thus can’t be P/Invoke’d directly. The native library(ies)
must be copied to the device for support to work. See XXXX
There is good support for BluetoothClient.Connect
(including RSSI), device discovery including ‘live’ discovery, and for
is supported for PairRequest
alone. For BluetoothRadio
property ClassOfDevice is not supported, nor on Win32 is the Mode property, etc.
is supported for all RFCOMM/SPP connections. be aware of the SDP limitations (see below): i.e. one query at a time and multiple results returned. In particular, if the remote service has restarted more that ten times we won't
read the last record(s) and the connect will fail it the service's current channel number is not the same as in the last record we read. BluetoothClient.Authenticate
are not supported, nor is SetPin
Data transfer (for BluetoothClient and BluetoothListener) seems fine.
note that that stack does not do clean-up if a program exits without clearing its SDP record. That misleads remote client applications that the service is still running. Also when the application next restarts the server can get
the same port (SCN) assigned and thus adds the same record, but any incoming connections don't get passed through! Seen on WM at least.
There are a couple of issue with SDP querying. First the API returns ALL the matching records it has ever read from the peer, so expect to get muliple results if you query more than once! Secondly Widcomm provides access only to particular Attributes and not
to the whole raw record. The current support is reading the Service Class and Name, and RFCOMM Channel Number attributes only. Finally only one request is supported at a time.
Security: The major issue on Widcomm, apart from the need for the native DLLs, is that there is no support for handling pairing etc, unlike most of the other platforms there is no way to get an event/callback when pairing is required to allow the program to
supply a PIN/passphrase/confirmation etc. The only support is API function Bond and UnBond.
both work. Of course Widcomm has built in OPP and FTP servers so they will get the incoming requests and not any ObexListener. Either have your application use a different Service Class Id, have it use a specific
Service Name, or disable the built-in OBEX servers.
To check if Widcomm/Broadcomm support is being loaded, check whether BluetoothRadio.PrimaryRadio
returns a radio and whether it's SoftwareManufacturer
is an enum value of
Broadcom detailed support table
(The Broadcom/Widcomm SDKs are at
As noted above a native DLL is required alongside the managed library DLL (InTheHand.Net.Personal.dll
). The native DLL is called
On Windows Mobile just copy the version from the folder to suit your platform (WM5
On desktop Windows things are much less simple. Three native components are required:
- Another Widcomm supplied DLL called btwapi.dll.
- The Microsoft Visual C++ Runtime libraries.
So you need to copy some DLLs to the same folder as your program (and InTheHand.Net.Personal.dll
- Copy the 32feetWidcomm.dll version from the folder to match your program bit-ness (i.e. either from folder
Win32-x86 or Win32-x64).
- Copy the btwapi.dll from the child redist folder. (According to the Widcomm documentation: "Note: Only redistribute btwapi.dll if it is not already present on the target system. Overwriting an existing btwapi.dll will cause unpredictable
- Ensure you have the necessary Microsoft Visual C++ Runtime libraries. To test this, run the
Test32FeetWidcommWin32.exe in the same folder as your DLLs, again using the version folder matching your program bit-ness. The current version of the library can be downloaded from
http://www.microsoft.com/en-us/download/details.aspx?id=26347 "Microsoft Visual C++ 2005 Service Pack 1 Redistributable Package MFC Security Update".
Some example dependency failure are shown at
Example Win32 load errors
Win32 -- Multi-stack
All stacks on Windows (that I've seen) have the limitation that they only support one Bluetooth Controller/radio/dongle. As a workaround for this there's been the idea that one could install multiple stacks and thus get to use multiple controllers as
they each support one radio.
This is possible with Widcomm and Microsoft stacks together. However this is not possible when compiling using the Widcomm version 6 SDK. If you want to use multi-stack, then one must use the
from the SDK v5 folder i.e. Win32-x86 SDK5
folder. Note however that this version might not work on new Widcomm installation. :-(