locked
Are Winsockets allowed on Windows Store apps?

    Question

  • Hello guys,

    we are in process of porting our engine to Windows 8.1 and Windows Phone 8.1 and part of it contains networking code which uses winsockets.

    The code works great on Windows Phone, but could not be build on Winodws 8.1 target.

    After checking wincosk2.h file it has a macro defined like:

    #if WINAPI_FAMILY_PARTITION(WINAPI_PARTITION_DESKTOP)

    Which basically disables whole file.

    I found an official article saying that it is possible to use winsockets on Windows and Windows Phone

    http://blogs.windows.com/buildingapps/2014/10/13/winsock-and-more-open-source-for-your-windows-store-apps/

    And I have VS 2013 Update 4, so it should be there, but I still can't make.

    So are winsockets available for Windows 8.1 target? Or the article is invalid?

    Saturday, April 18, 2015 2:39 PM

Answers

  • It seemed I found the issue.

    Windows app cannot be connected to as tcp server from a desktop app (which my tests actually tried to do)

    If I run them from remote machine, everything works. Is it an expected behavior?

    Also I have other question now.

    If VS 2013 Update 4 bundles winsock2 header that builds and works with WACK 3.3 that does not allow winsockets, and while Windows 8.1 SDK update has WACK3.4 that allows socket API, but bundles older winsock2 header which does not build.

    How to get WACK3.4 with correct winsock2 setup?

    Windows Store apps are sandboxed and are not allowed to communicate with other local processes through the network stack. Any attempt to open a communication between them will be blocked.

    Windows and Windows Phone Store Policies

    "Your app must not communicate with local desktop applications (on Windows devices) or services via local mechanisms, including via files and registry keys."


    Sunday, April 19, 2015 6:04 PM
  • It seemed I found the issue.

    Windows app cannot be connected to as tcp server from a desktop app (which my tests actually tried to do)

    If I run them from remote machine, everything works. Is it an expected behavior?

    Also I have other question now.

    If VS 2013 Update 4 bundles winsock2 header that builds and works with WACK 3.3 that does not allow winsockets, and while Windows 8.1 SDK update has WACK3.4 that allows socket API, but bundles older winsock2 header which does not build.

    How to get WACK3.4 with correct winsock2 setup?

    • Marked as answer by ar2rsawseen Sunday, April 19, 2015 7:56 PM
    Sunday, April 19, 2015 5:27 PM

All replies

  • Check all supported Windows Sockets functions here

    https://msdn.microsoft.com/en-us/library/windows/apps/br205759.aspx

    Saturday, April 18, 2015 3:40 PM
  • If you have VS 2013 Update 4 properly installed, then you will have gotten an updated Windows 8.1 SDK. In that version of winsock2.h, only the ASCII versions of most of the WinSock APIs are excluded from Windows Store. You have to use UNICODE exclusively for Windows 8 Store apps.


    Saturday, April 18, 2015 4:21 PM
  • So it is possible.

    What do you mean by UNICODE exclusively

    Is it a macro, or converting chars to wchar

    or any other specific steps?

    Saturday, April 18, 2015 4:48 PM
  • So it is possible.

    What do you mean by UNICODE exclusively

    Is it a macro, or converting chars to wchar

    or any other specific steps?

    API that manipulate character data come in an ANSI and Unicode version.

    Unicode in the Windows API

    Sunday, April 19, 2015 4:26 PM
  • It seemed I found the issue.

    Windows app cannot be connected to as tcp server from a desktop app (which my tests actually tried to do)

    If I run them from remote machine, everything works. Is it an expected behavior?

    Also I have other question now.

    If VS 2013 Update 4 bundles winsock2 header that builds and works with WACK 3.3 that does not allow winsockets, and while Windows 8.1 SDK update has WACK3.4 that allows socket API, but bundles older winsock2 header which does not build.

    How to get WACK3.4 with correct winsock2 setup?

    • Marked as answer by ar2rsawseen Sunday, April 19, 2015 7:56 PM
    Sunday, April 19, 2015 5:27 PM
  • It seemed I found the issue.

    Windows app cannot be connected to as tcp server from a desktop app (which my tests actually tried to do)

    If I run them from remote machine, everything works. Is it an expected behavior?

    Also I have other question now.

    If VS 2013 Update 4 bundles winsock2 header that builds and works with WACK 3.3 that does not allow winsockets, and while Windows 8.1 SDK update has WACK3.4 that allows socket API, but bundles older winsock2 header which does not build.

    How to get WACK3.4 with correct winsock2 setup?

    Windows Store apps are sandboxed and are not allowed to communicate with other local processes through the network stack. Any attempt to open a communication between them will be blocked.

    Windows and Windows Phone Store Policies

    "Your app must not communicate with local desktop applications (on Windows devices) or services via local mechanisms, including via files and registry keys."


    Sunday, April 19, 2015 6:04 PM
  • Damn, that kills the purpose of what I'm doing.

    I was porting a gaming engine to Windows platform, and I need to create a player in which users can run the code written in IDE, which is transmitted through tcp on all other platforms.

    With our engine IDE we also bundle all the players for all platforms where users can test their code before exporting it as an app.

    Then it makes it impossible to do on Windows 8.1 apps.

    Why such restriction?


    Sunday, April 19, 2015 6:25 PM
  • Why such restriction?


    Presumably for security reasons. A sandboxed app environment needs to strictly enforce information that is shared across processes.

    I ran into this same issue with my app, yMIDI. Although it was originally designed for remote communications some users wanted to use it with local rtpMIDI ports too. Since communication was over the network stack, this was not possible.

     
    Sunday, April 19, 2015 7:26 PM
  • Well that's bad

    I don't see a security threat really, especially when it can connect remotely, but not locally? That just does not make sense to me. But probably I just don't have enough information about it.

    Sunday, April 19, 2015 7:57 PM