[rumcajz]

My experience: When implementing ZeroMQ, porting it to a new platform normally took few hours. Porting it to OpenVMS, which is a real oddball among modern operating systems took several days. Porting it to Windows took several months. Even today, after years of active development there are still features that don't work on Windows.

[to3m]

Well, I'm more confident about video games than I am about ZeroMQ, I have to say. But I might imagine on balance of probabilities that this will turn out to be a case of "POSIX and pthreads" ;) - it often is with Unix stuff. (Sadly, Windows ain't POSIX, and it doesn't have pthreads. So... there you go.)

But it's certainly possible that Windows is even more bizarre than I suppose, in ways that I have yet to encounter.

[blub]

Would be much more useful to say why it took that long...

[eps]

Was it because epoll vs iocp differences?

[udp]

Now that's one area where Windows really differs. You can't write a high performance server for Windows without using IOCP, which couldn't be more different from what every other platform has for that kind of thing (epoll, kqueue, /dev/poll, ...)

It was interesting watching node/libuv face all the same problems I did when originally trying to abstract over this.

[eps]

It is possible to wrap iocp api into a bsd-style socket interface compatible with epoll semantics. It ain't pretty, the socket int becomes an index into an internal map of per-socket support structs, there are ungodly edge cases and what not, but it's doable nonetheless.

[pjmlp]

Solaris?

[udp]

Interesting - I wasn't aware that any other platform implemented IOCP. I wonder how that performs vs. traditional I/O with /dev/poll?

[pjmlp]

You can get information about it here

http://web.archive.org/web/20110719052845/http://developers....

[rumcajz]

epoll/iocp is the most visible difference, however, the amount of time spent porting is more due to subtle differences in every POSIX-like function. File discriptor is int? Nope, it's SOCKET. -1 means it is invalid? Nope. Use INVALID_SOCKET instead. error codes are stored in errno? No. Use WSAGetLastError() to retrieve the error. Still, EAGAIN should be EAGAIN, even on Windows? No. Use WSAEAGAIN instead. And so on and on.

[MatthewPhillips]

Doesn't OpenVMS have POSIX?

[pjmlp]

It is optional and not up to date with the latest specification.

The problem with POSIX, like any other standard, is that not all systems implement the same POSIX.

[MatthewPhillips]

I'm not a porter so I'm just trying to understand here, but I would suspect that having POSIX, albeit quirky, would automatically make it easier to port than Windows which has no POSIX. Like porting a web app to IE6 is easier than porting it to a Node CLI app. Does that analogy not work?

[parfe]

Windows has a POSIX implementation.

https://en.wikipedia.org/wiki/Interix

[pjmlp]

The problem is that each POSIX compatible system tends to have different levels of support for the various POSIX standard versions.

Additionally there are APIs which have undefined edge cases or different limits (e.g. amount of open file handles).

So even if you only target POSIX systems, you have to pollute the code with #ifdef to handle such differences.

It is similar to do web development. There are standards, but each browser version is a different world.