Question

I can successfully open the device with WinRT API (Permissions need to be granted by the user) but I cannot make the legacy DLL to access the device. The following symptoms I encounter:

1. device = RfcommDeviceService.fromIdAsync(service.id) pops up the Permission dialog which I accept
2. streamSocket.connectAsync(device.connectionHostName, device.connectionServiceName) connects successfully to the device
3. The legacy API tries to use WSAConnect to open the same device and gets an 10048 (socket in use). This is expected.

then I try to not connect the device from WinRT and get 10013 (An attempt was made to access a socket in a way forbidden by its access permissions.)

First of all, the process should have already access to the socket, as granted by the user during the RfcommDeviceService.fromIdAsync() call. Secondly why does the access permission is checked only after it checks for an in-use port?

I hope we can use the legacy DLL and do not have to rewrite everything for a LOB WinRT app.

Thursday, July 10, 2014 1:46 PM

Answers

WSAConnect is desktop only. It's not designed for or supported in the Windows Store apps' app container. Take a look at brokered Windows Runtime Components to work with desktop code in your side-loaded app.

Sorry Rob, writing a C# application server is not an option at all in our scenario. I understand all that "protect Joe Average consumer" from malicious Store apps (and applaud it to some extent), but in the Enterprise Env such restrictions are just annoying
as hell (as well as the whole incoherent deploy process of LOB apps, that cannot be applied to real world scenarios).

And look at the build and deploy process of those "brokered Windows Runtime Components". The boilerplate code you have to churn up, oh my! The team that came up with those ideas can't be taken serious. Is that really what MSFT thinks should be the new way
of developing Windows apps for the Enterprise?

Nevermind though. We emulated the WSA* calls now with a simple (!) proxy DLL that the 3rd party DLL loads and calls some 3 little functions there that use the WinRT API for RFComm and some async/sync trickery to provide the necessary functionality to the
3rd party DLL.

All replies

WSAConnect is desktop only. It's not designed for or supported in the Windows Store apps' app container. Take a look at brokered Windows Runtime Components to work with desktop code in your side-loaded app.

Rob, I feared such answer. But this thread here http://social.msdn.microsoft.com/Forums/windowsapps/en-US/ba6527db-9a25-4aba-a51a-b9b6191e5406/how-to-use-windowsdevicesbluetoothrfcomm-apis-to-connect-to-a-bluetooth-device-spp-in-winrt?forum=winappswithnativecode
mentions we can use win32 Bluetooth API.

I already successfully got mmio in an old DLL working under WinRT as long as I first get the permissions from the User via WinRT calls to Audio capture devices. So I hoped the same would work for SPP Bluetooth.

Sorry Rob, writing a C# application server is not an option at all in our scenario. I understand all that "protect Joe Average consumer" from malicious Store apps (and applaud it to some extent), but in the Enterprise Env such restrictions are just annoying
as hell (as well as the whole incoherent deploy process of LOB apps, that cannot be applied to real world scenarios).

And look at the build and deploy process of those "brokered Windows Runtime Components". The boilerplate code you have to churn up, oh my! The team that came up with those ideas can't be taken serious. Is that really what MSFT thinks should be the new way
of developing Windows apps for the Enterprise?

Nevermind though. We emulated the WSA* calls now with a simple (!) proxy DLL that the 3rd party DLL loads and calls some 3 little functions there that use the WinRT API for RFComm and some async/sync trickery to provide the necessary functionality to the
3rd party DLL.