How share C++ socket code (WinSock) across Windows platforms?

Question

"MSDN WinSock documentation" dated 29 Nov 2012:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms740673(v=vs.85).aspx
States:
 - "Windows Sockets 2 is designed for use by C/C++ programmers."
 - "Windows Sockets 2 can be used on all Windows platforms."

"MSDN Windows Phone 8 and Windows 8 platform comparison" dated 15 Mar 2013:
http://msdn.microsoft.com/en-us/library/windowsphone/develop/jj681690(v=vs.105).aspx
States:
 - "developers can create apps for both platforms and maximize code reuse."
 - "The set of native APIs that are common to Windows Phone 8 and Windows 8 include
    DirectX, XAudio2, MediaEngine, STL, CRT, WinSock"

My issue contradicts the above statements in that WinSock does not seem to be available in "Visual Studio 2012 Express for Windows 8", and hence I cannot share existing WinSock based code across a Windows Store App and other Window platform Apps. 

Q1) Could you please advise if the WinSock API's are available in the 'paid for versions' of Visual Studio 2012 for Windows 8 (for Windows Store Apps)?

Q2) If the WinSock API is not currently available for Windows Store Apps what is the recommended way of sharing standard socket code between
Windows XP, Windows Vista, Windows 7, Windows 8 Desktop, WindowsRT, and Windows Phone 8 ?.

Answer 1

Q1 - Regardless of what version of VS2012 you're using, Windows Store applications do not have access to the WinSock API. They have to use the networking classes in WinRT.

Q2 - For XP, Vista, W7, W8 desktop and possibly WP8 you could use WinSock as the common API for networking. Windows Store Apps are the outlier. It's possible to abstract your networking at an application level in your own libraries.

Answer 2

Thanks I3v3I6 for your quick response, it wasn't clear to me in the Visual Studio and MSDN documentation that that was the case. Looks like I have some non-trivial porting to do!. 

My networking is currently abstracted from my Apps into my own networking library - this well-tested library currently runs on Linux, Android, OS X,
iOS, Windows 3.1 thru Windows 7. It will also probably work unchanged on Windows 8 desktop and Windows Phone 8. 

It seems a very strange decision to provide the WinSock API on ALL Windows platforms except WindowsRT ! 

This makes it more difficult than it needs to be to port and maintain Apps between Microsoft platforms!

I would have thought that this would be a 'large headache' for many Windows developers - and I can not envisage any technical reasons why WinSock is not available for all Windows 8 platforms.

Does any one know if there are any plans to support WinSock for Windows Store Apps in the future - perhaps in a Visual Studio Update ?

Answer 3

Does any one know if there are any plans to support WinSock for Windows Store Apps in the future - perhaps in a Visual Studio Update ?

Don't get your hopes up. Microsoft has clearly stated that they intend for the WinRT API to be as natively asynchronous as possible. Although WinSock can be used asynchronously it doesn't fit well with the WinRT asynch model.

Answer 4

Then why make it available for Windows Phone 8 Apps ?  - I presume to make porting Apps from competing phone platforms 'easier' - if so then it would also make sense to provide it on WindowsRt to make it easier to port Apps from competing tablet platforms 'easier'? - It seems that the Microsoft 'Windows Phone 8' SDK people have different 'goals' than the Microsoft 'Windows 8 for Store Apps' SDK people? 

A comment from a 'Microsoft person' on this issue would be welcome.

If there are no plans to address this, then the MSDN reference I quoted above needs changing to:

"Windows Sockets 2 can be used on all Windows platforms except WindowsRT."

Answer 5

WinSock support is one of the few areas where WP8 is better than W8.

Oh, and just wait until you see how the official W8 Socket examples receive an arbitrary length response! If that doesn't make you vomit (asynchronously, of course), nothing will.

Answer 6

@All

I am asking a silly question....

-> Whether or not Windows Phone 8 uses any version of Windows Runtime(WinRT) ?

-> Whether or not Windows Store Apps can be deployed in Windows Phone 8 ?

Answer 7

I've decided not to port my Comms library to WindowsRt - I will develop for Windows 8 Desktop (WinSock) and Windows Phone 8 (WinSock) - my company will not be developing any Windows 8 Store Apps (no WinSock) - undoubtedly that will scare Microsoft into seeing sense (ha ha, I wish).

Mokarrom: my understanding (which may be wrong) is that WindowsRt (for tablets) and Windows Phone 8 both use WinRT API's (some are the same on both, some are 'similar', and others are different! - you need to do your research!) . Regarding your second question, if you develop Apps that abstract the different API's and device differences then that App could presumably target both platforms - however the Windows Store App would need to be built using 'Visual Studio 2012 for Windows 8' while the Phone version would need to be built using 'Visual Studio 2012 for Windows Phone 8'.  

Answer 8

@All

I am asking a silly question....

-> Whether or not Windows Phone 8 uses any version of Windows Runtime(WinRT) ?

-> Whether or not Windows Store Apps can be deployed in Windows Phone 8 ?

To add to Keith Slack's reply:

1. Windows Phone 8 (WP8) uses the Windows Phone RT API (WinPRT), which is close to WinRT but has some significant differences. For example, there are no Roaming files in WinPRT, no FilePicker, etc.

2. Windows Store apps are incompatible with Windows Phone 8, both at the source and binary levels. You can't simply recompile for the phone, you have to make changes to your XAML and code (mainly the UI level code, your core code can mostly remain the same). This isn't a huge deal since you're dealing with much smaller screen in WinPRT and will need to change the UI anyway.

I *hope* that some of the differences between WinRT and WinPRT will be removed/reduced in the upcoming Windows "Blue" versions of WinRT and WinPRT. I don't think that full source code compatibility is necessary (binary compatibility is definitely not necessary) but I would like to see more unification of the UI concepts and code. I'd like to see this compatibility stretch across to XBox8, too (WinXRT anyone?).