Philip Langdale authored Dec 04, 2018 and Niklas Haas committed Dec 06, 2018

There are two win32 specific handle types, which we believe to be
the ones that would be primarily used by a win32 client.

There is the 'NT Handle', which is available on Windows 8 or newer,
and the 'Global share Handle' (abbreviated as KMT in the Vulkan spec),
which is available on Windows 7 and newer, but which apparently
shouldn't be used when the 'NT Handle' type is available. We do not
attempt to judge usage, and it is up to the client to decide which
of the two types it wants to use.

Note that the existing logic for identifying the handle_caps is not
actually sufficient. We need to call specific functions to identify
what is possible for buffers, images, and semaphores.

* vkGetPhysicalDeviceImageFormatProperties2KHR
* vkGetPhysicalDeviceExternalBufferPropertiesKHR
* vkGetPhysicalDeviceExternalSemaphorePropertiesKHR

and these need to be called with the specific flags and parameters,
so I think it basically ends up being that you can't tell if your
image/buffer/semaphore is exportable until you create it. Anyway.

I am not in a position to test any of these changes. Someone who
can build on win32 must do that.