My legacy static library uses WinSock api. How can I use it from Metro App? RRS feed

  • Question

  • I described my use-case below. Then I posted 4 questions. It will be very helpful if I get some expert suggestions. Thanks in advance.

    I have an existing C++ library built as static in VS2008 (call it MyCnx.lib). It uses WinSock Win32 api calls and thus has dependency on winsock2.h and related header files (such as ws2def.h qos.h Ws2tcppip.h Iphlpapi.h). I "converted" my project and solution from VS2008 to VS2011 Beta and the build failed with error message that it cannot find winsock2.h file; (the Win8 SDK was already installed). I downloaded Microsoft SDK 6.0A and installed it on the Win8 Consumer Preview environment and the build and link succeeded, provided I added:
    C:\Program Files\Microsoft SDKs\Windows\v6.0A\Include
    C/C++ / General / Additional Include Directories:

    I also included the preprocessor flag: WINAPI_FAMILY=WINAPI_PARTITION_APP

    Qs 1: Will this MyCnx.lib work, if I build my existing desktop application (which consumes this MyCnx.lib) on Win8?

    QS 2: Will this MyCnx.lib work from a new C++ Metro Style app on Win8 on x86 hardware? If not, what requirements does MyCnx.lib must meet?
    [(a) In some threads, I see existing Win32 api calls must be replaced by now new api's from WinRT library.
    (b) In the Build video by Jason Olson, PLAT 877T, it seems, a "thin" layer of public functions with WinRT conventions (ref in class declarations), which would call native functions in existing legacy library, would suffice the job. (a) or (b)?]

    Qs 3: Repeat Qs 2, for ARM hardware.

    QS 4: Repeat Qs 2, for a C# (not C++) Metro Style app on Win8 on ARM hardware.

    Thanks again.

    • Edited by Shafiq2012 Tuesday, April 24, 2012 12:53 AM
    Monday, April 23, 2012 11:51 PM


All replies

  • Hello,

    Not all Win32 API can be used in metro style app.
    You can use these networking API in metro

    Here is the Socket namespace in metro

    Therefore, I suggest you to check your original codes to change the network APIs in it.

    Best regards,

    Jesse Jiang [MSFT]
    MSDN Community Support | Feedback to us

    Tuesday, April 24, 2012 7:25 AM
  • Since I have legacy socket code implemented in C/C++ style, now how do we migrate it to new Metro Style socket code, is my question.

    Does this mean, my old socket related code needs to be completely rewritten, or does it mean, from api to api to transformation is somewhat feasible?

    In other words, new Metro Style Networking namespace code look very object oriented style, not calling-api style. That seems a good amount of rewrite.

    Please advise.

    Thursday, April 26, 2012 6:28 PM
  • If your api's are supported then you can use them. If not, then you need to rewrite. The WinRT C++ projections are object oriented, though the lower level WinRT underneath the C++/CX C++ language projection is purely procedural and looks very much like old-school COM programming. We strongly encourage the use of the C++/CX C++ projections unless there are very specific reasons you need to use the low-level RoApi, or the WRL template library.

    Regarding the use of any other SDK other than the Windows 8 SDK, you are setting yourself up for broken apps and heartache. You installed the v6 SDK and then used the WINAPI_PARTITION_APP preprocessor define. The v6 SDK knows nothing about that macro so it's a no-op. The compiler and linker happily compile and link in api's that are not Metro style safe and your app will not pass app certification or run under the Metro desktop.

    Compile your code under Dev11 with only the Windows 8 SDK installed (or at least in the Include path). For the code that does not compile, you need to start investigating WinRT replacements.

    Friday, April 27, 2012 10:30 PM
  • Thanks for the note.

    I uninstalled SDK 6.0A. Now it is a 100% VS11 Beta environment.

    I built my library using Metro Style Dynamic Library. Following 3 sets of WIN32 apis are not "suppressed". I.e., I if-def-ed them out to complete the build. Now the challenge for me: rewrite them "some how" using new Metro Style code. Some suggestions will help as to how to attack this problem of rewriting (or code replacement).

    getsockopt socket getsockname bind connect send sendto recv recvfrom listen accept closesocket ioctlsocket WSAStartUp WsaCleanUp

    CreateThread OpenThread ResumeThread Sleep TlsAlloc TlsFree TlsGetValue TlsSetValue WaitForSingleObject

    CreateFolder CreatePrivateFile GetTemporaryFolder TempFilename MoveFile MoveFolder CopyFile IsTemporaryPath GetAppPathname GetDiskFreeSpace

    Friday, April 27, 2012 10:56 PM
  • Windows.Networking.Sockets, PPL Tasks, and Windows.Storage

    Windows 8 samples are broken down via technology area here: http://code.msdn.microsoft.com/windowsapps

    PPL is  here http://msdn.microsoft.com/en-us/library/dd504870(v=vs.110).aspx

    • Proposed as answer by Jesse Jiang Tuesday, May 1, 2012 8:16 AM
    • Marked as answer by Jesse Jiang Monday, May 7, 2012 2:34 AM
    Tuesday, May 1, 2012 1:59 AM
  • Thanks for the feedback.

    Some WIN32 sock apis, integral part of my legacy library, are just too difficult to be replaced. For example, here is another post of mine, where I am trying to get a sense what should be my path to rewrite old sock win32 code in Metro App Winrt.

    Please see here:


    Saturday, May 5, 2012 11:30 PM
  • Hi,

    I read in this link (http://msdn.microsoft.com/en-US/library/windowsphone/develop/jj662956(v=vs.105).aspx) that, Windows Phone 8 can use win32 apis (from winsock2.h).

    SO, windows store app (for windows 8 surface) cannot use winsock and windows phone 8 apps cna use. Is that right?


    Tuesday, July 23, 2013 2:00 PM
  • Installing a different SDK or trying to circumvent the header WINAPI family partitioning system may get the code to *build* but you will never be able to *deploy* it to the Windows Store since it will fail to pass the WACK validation. In some cases the legacy API might work locally, and in other cases it will fail with an usual error due to the locked down system privileges for Windows Store apps (aka AppContainer). The whole point of getting those compilation errors in the first place is to make it easy to identify the areas of your application that need rewriting for Windows Store apps. In this case, you need to use Windows.Networking.Sockets for your Windows Store app version of your library.

    Note that the Windows 8.0 SDK still includes all the winsock API headers for use by Win32 desktop applications. You just have to have WINAPI_FAMILY set to WINAPI_PARTITION_DESKTOP rather than WINAPI_PARTITION_APP.

    RE: Windows phone 8

    The Windows phone 8.0 platform doesn't support all the new WinRT networking APIs, so the old WinSock APIs are available on that platform as an interim solution.

    There's great alignment in many parts of Windows Store apps and Windows phone 8, and even some overlap with Win32 desktop applications. Networking happens to be an area of divergence.

    You may find the following resources useful to read:

    Dual-use Coding Techniques for Games (blog)

    How to Leverage your Code across WP8 and Windows 8 (BUILD 2012)


    Tuesday, July 23, 2013 8:09 PM
  • Thanks CHuck...

    SO, that's helpful info. It would be useful for all if this info is published in the respective documentation of MSDN also.

    Also, can I say that, anytime these "Interim" solutions can go off the shelf, it is not advisable to use these interim items in development (if possible) and only use winrt apis 

    Thanks anyway..

    Wednesday, July 24, 2013 1:06 PM
  • If you want to target Window Store apps, you need a WinRT implementation. If you want to target Windows phone 8 or Win32 desktop, you need Winsock.
    Wednesday, July 24, 2013 8:51 PM
  • I'm *REALLY* disappointed that Microsoft provided no guidance for porting your app from winsock to windows.networking, and opted to cut it instead of deprecating it over a period of time. Making this change is not a trivial task to put it mildly. Also, the fact that it's available in desktop AND phone apps makes its exclusion from Windows Store apps appear arbitrary. Finally, your explanation for why it's available on the phone scares me, and doesn't appear to align with the story from the networking session at build 2012, which I'd really like to think is the real answer: there are several communications apps available on other platforms (using BSD sockets) which are more easily ported to the wp8 platform when winsock is available (paraphrased).

    Tuesday, August 13, 2013 3:42 PM
  • There is new material on MSDN specifically for networking in Windows Store apps. You may find this useful.

    Work with networking in your DirectX game

    Tuesday, August 13, 2013 5:55 PM
  • BTW: Jmorrill created a shim/wrapper on top of WinRT networking api https://winrtsock.codeplex.com/
    Friday, August 16, 2013 10:18 AM