I’ve previously run the Widcomm stack under a debugger but never with enough time to investigate it thoroughly.  Having changed the threading model and since that didn’t do anything to help Widcomm work when the Microsoft stack is present I wanted to get stuck in to fixing this.

In short what I found was that when the Widcomm stack loads (actually when I create a BluetoothListener on the Widcomm stack) I see calls to the Microsoft stack API and to Winsock!  First it calls the BluetoothFindFirstRadio/etc API and then it calls: socket(AF_BTH, SOCK_STREAM, BTHPROTO_RFCOMM).  Then when the BluetoothListener is active if one breaks into the debugger and lists the threads one thread is sitting waiting on WSAAccept.

So it’s all very clear now.  It’s not some unintentional conflict between Widcomm and the Microsoft Bluetooth stack that breaks some threading or message passing system, instead its fully intentional behaviour on Widcomm’s part.  For Vista instead of porting their whole stack to the new platform they instead just provide a wrapper around the Microsoft stack.  And this is what’s causing the problems here.  We want the Widcomm API to use the Widcomm stack but it’s finding the Microsoft stack, and assuming that’s its own stack isn’t present.  So we need a way to tell Widcomm, “Don’t use the Microsoft stack”.

In order to test whether that’s all that is required, I used the debugger to make it appear like the Microsoft stack wasn’t present.  I set a breakpoint on ws2_32.dll!socket and the breakpoint was hit with Widcomm doing the call above.  I arranged for the socket creation to fail and thus forced Widcomm to use its own stack.  Doing this made the two stacks coexist. 🙂  I was able to get the two stacks to connect to each other on the same PC: a BluetoothClient on Widcomm connecting to a BluetoothListener on Widcomm, and the also with the roles reversed.

So how can we get Widcomm to ignore the Microsoft stack:

  1. Find if there’s a a Registry key or similar that Widcomm provides to disable the wrapping behaviour. 
  2. Do some cunning interception of the socket API call and cause it to fail when Widcomm attempts to open a Bluetooth socket.
  3. Try an older version of the Widcomm SDK to see if it provides the wrapping behaviour and thus the feature isn’t present in an older version.  There’s the danger that we lose some features present in up-to-date SDKs.

Don’t know when I’ll next have some time to do some more investigation so feel free to carry out your own investigations in the meantime.