Linked by Thom Holwerda on Wed 20th Dec 2017 17:34 UTC
Windows

Support for the unix socket has existed both in BSD and Linux for the longest time, but, not on Windows. On Windows, there were some alternatives for local IPC, such as named pipes. But, calling conventions are different between the named pipes and sockets, making writing low-maintenance cross-platform applications difficult. For example, one such place where these two constructs differ (other than the API) is terminating the connection. BSD Socket API provides a bidirectional close semantics using 'shutdown'. There is no direct equivalent of that in named pipes. Such differences make it difficult to port unix socket applications from Linux to Windows and vice versa; up until now!

Build 17063 brings native support for the unix socket to Windows. Starting this build, two Win32 processes can use the AF_UNIX address family over Winsock API (which is very similar to the BSD socket API) to communicate with each other. Currently, the support only exists for the stream (SOCK_STREAM) socket type, which is a connection-oriented protocol for one-to-one communication. Support for the datagram (SOCK_DGRAM) can be considered in future depending on the adoption, feedback and scenarios.

Another step to make Windows friendlier to UNIX/Linux users and developers.

Permalink for comment 652341
To read all comments associated with this story, please click here.
RE: More aimless MS "Strategy"
by kurkosdr on Fri 22nd Dec 2017 18:04 UTC in reply to "More aimless MS "Strategy""
kurkosdr
Member since:
2011-04-11

The only meaningful thing this will do is inspire developers to abandon (parts of) the Windows api.


Which is exactly the reason I think Windows 10 is a linux distro in denial.

APIs are added at a breakneck pace (not bad in itself), but win32/win64 compatibility is sometimes broken (ain't nobody got time for that), and you can't opt to receive only security patches, you get upgraded to the latest version either you want it or not.

Most importantly, the win32/win64 API is treated as legacy nowadays, despite the fact it is the only API that does things like SLI/CrossFire, true full-screen apps (exclusive GPU usage), v-sync disable, stereoscopic output and the like, and even complex mouse-driven UIs, at least on Microsoft Windows and despite the fact it is the API most high-dollar Windows apps use.

Linux compatibility in Windows is good if you like linux distros, but the way Microsoft treats win32 and win64 is not good for people who like Windows, and most importantly for businesses who rely on the API stability of win32 and win64 as was offered by Windows versions previous to Windows 10.

Is Belfiore and the other Redmondian hipsters suffering from Apple-eny sure that this decision ("move fast and break things?") was a good one? Just because something is good for a consumer OS like iOS doesn't mean it is good for an OS like Windows which has a huge and complex hardware and software ecosystem and is used by businesses who value stability.

Let me give you a hint: How many businesses plan to upgrade to Windows 10?

Edited 2017-12-22 18:14 UTC

Reply Parent Score: 0