On Windows, a file descriptor is emulated in user-space as a wrapper around the real Win32 API. Indeed, the first operation libuv almost always must do is to throw away the wrapper (by calling uv__get_osfhandle). However, since the wrapper is implemented in user-space, this adds unnecessary overhead, makes the API less flexible, and is potentially error-prone (it assumes that the caller and libuv are linking against the same copy of msvcrt). A couple of functions already accept a uv_os_sock_t, essentially just to work around these limitations. While libuv could continuing adding dual APIs for everything (e.g. see uv_poll_init vs. uv_poll_init_socket), this doesn't seem particularly ideal to me.

What I would like to propose is to consistently remove this extra indirection from all APIs in libuv, and replace all usages of uv_os_sock_t with uv_file, while redefining uv_file on Windows to be a HANDLE.

It this is acceptable, I will start work on a PR.

Existing clients can initially transition to the new API by adding the following helper function code snippet:

HANDLE os_handle = _get_osfhandle(fd), handle;
if (!DuplicateHandle(GetCurrentProcess(),
                     os_handle,
                     GetCurrentProcess(),
                     &handle,
                     0,
                     TRUE,
                     DUPLICATE_SAME_ACCESS)) {
  return INVALID_HANDLE_VALUE;
}
_close(fd);
return handle;

Longer term, those clients would now be able to transition to using the Win32 API directly instead of requiring indirection through the MSVCRT API.