Visual C++ WinRT FAQ – Winsock and other APIs

When migrating apps or libraries that use sockets to WinRT, the absence of Winsock is often one of the first hurdles for many C++ devs. The suggested alternative to Winsock is to use the Windows.Networking.Sockets namespace. For a full list of alternate APIs that replace existing ones, see:

Be aware that you will most likely not get a one-to-one mapping for various API functions and structures. So you should fully expect to re-design and workaround that and use alternate approaches to achieving the same functionality/usability.


Building Metro apps without Windows 8

This is an FAQ on the forums. And unfortunately but unsurprisingly, the answer is no, you cannot build a Metro app without Windows 8. If you are running Windows 7 and don’t want to risk screwing up your OS, you could install Windows 8 on a VM or dual-boot off a VHD/2nd partition. Those options are reasonably performant, and more so if you have an SSD.

Visual C++ WinRT FAQ – Inter-Process-Communication

This is slightly related to the previous FAQ on connecting to localhost. While Metro apps can use contracts to communicate at some level with other apps, that is not equivalent to the traditional concept of inter-process communication. A metro app cannot communicate with a desktop app or even with another metro application on the same machine.

With desktop apps, the metro app cannot take for granted that it’s running or available, and thus it makes sense to not allow that. But you may be wondering why IPC is blocked between two metro apps. Well, metro apps can be in a suspended state at any given time, and there’s no sure way to predict its state. So even if there are two apps running at the same time, neither app can be sure if the other app’s ready to accept data or a command. This is quite likely why they decided to design it so that metro apps cannot talk to each other.

So, what’s the workaround? Again, the only reliable way an app can talk to another app on the same machine is to use a a 3rd service that’s running on the network, or to use a cliched phrase, use the cloud.

Using Socket.Disconnect(true)

Recently, someone asked this question on the CodeProject forums where the OP wondered if reusing the socket would mean he’d get the same client endpoint. This is the gist of my response to him.

Calling Socket.Disconnect(true) will internally result in Winsock’s DisconnectEx function being called with the TF_REUSE_SOCKET parameter.

From the docs:

Prepares the socket handle to be reused. When the DisconnectEx request completes, the socket handle can be passed to the AcceptEx or ConnectEx function.

So it’s only the socket handle that will be reused. This has nothing to do with your local endpoint.

Socket reuse is meant for fairly advanced use, where you know exactly what you are doing. It’s typically used in high performance heavy traffic TCP servers. The idea being that by reusing a socket, you save some time (the time that would normally have gone into allocating that socket and its resources). So what some server developers do is to have a pre-created socket pool that they pull sockets from as and when required.

So in my opinion, for a client side TCP application there is never a good reason to reuse a socket.

In short, always use Socket.Disconnect(false) unless you really know what you are doing.

For some reason, this is not so well documented and leads to a lot of confusion.

FAQ: Cannot reuse closed WPF windows

In an earlier FAQ entry, I talked about how you can show a previously closed Windows Forms form. Well the same holds true for a WPF window and for the same underlying reason. When you close a WPF window, the native window is closed and destroyed. So trying to re-show it will just throw an exception. The solution is to either hide/show windows as required, or to instantiate and show a new window whenever that’s needed.

FAQ: C# calling C++ code with callbacks with unmanaged array arguments

This question or a similar variation pops up in the forums once in a while. The core problem is that while null terminated char arrays can be marshaled to a System.String fairly easily, with other unmanaged arrays the marshaller cannot know for sure what size of array to create. The solution is to marshal the argument as an IntPtr and then in the calling code, the user can manually create a managed array and copy the data into it. This assumes that the unmanaged API has a size parameter (which it invariably does) that indicates the length of the unmanaged array. Here’s some example code that shows how this is done:

C++ code

typedef long (CALLBACK * READDATA)(unsigned char * data, int length);

extern "C" __declspec(dllexport)  void __stdcall SomeFunc(READDATA rd)
 unsigned char data[5] = {'a', 'b', 'c', 'd', 'e'};
 rd(data, 5);

And here’s the calling code:

C# code

delegate int ReadDataDelegate(IntPtr data, int len);

static extern void SomeFunc(ReadDataDelegate d);

private static void CallNativeWithCallback()
    ReadDataDelegate newCB = new ReadDataDelegate((data, len) =>
        byte[] array = new byte[len];
        Marshal.Copy(data, array, 0, len);
        foreach (byte b in array)
        return 0;

FAQ: Cannot re-show a WinForms form that's been closed

This one comes up in the forums at least once a week. The scenario is where someone shows a form, closes it while retaining the handle, and then tries to show it again by calling Show or ShowDialog on the closed form. This throws an exception that says the object has been disposed.

Here’s my standard answer. You cannot re-show a form once it’s closed because the underlying window is destroyed. You can hide the form and then re-show it as required thereby reusing the same form instance.

Alternatively, for modal dialogs, instantiate a local form variable and call ShowDialog on that. So each time it’s a new form. And this way you don’t need to keep the form in memory all the time, specially if it’s an options dialog that’s rarely brought up.