locked
Legacy Win32 WSAConnect in LOB Modern App returns 10013

    Question

  • I struggle here with a legacy Win32 Winsock Dll (no source code available) that allow communication with a Bluetooth SPP device.

    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.
    Thursday, July 10, 2014 3:29 PM
    Moderator
  • 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.

    • Marked as answer by pkursawe Saturday, July 12, 2014 10:33 PM
    Saturday, July 12, 2014 10:33 PM

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.
    Thursday, July 10, 2014 3:29 PM
    Moderator
  • 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.

    All this makes WinRT certainly not "Enterprise ready".

    Thursday, July 10, 2014 3:45 PM
  • As I mentioned, take a look at brokered Windows Runtime Components. They are designed specifically to allow enterprise apps to leverage existing desktop code in side-loaded apps.

    As noted in the thread you link, you can use Win32 and COM APIs listed at http://msdn.microsoft.com/en-us/library/windows/apps/br205757.aspx . You cannot use arbitrary API in a Windows Store app. The documentation for WSAConnect specifically says that it is desktop only:

    Thursday, July 10, 2014 5:15 PM
    Moderator
  • 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.

    • Marked as answer by pkursawe Saturday, July 12, 2014 10:33 PM
    Saturday, July 12, 2014 10:33 PM