5 ms·
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 opera
by rumcajz 14y ago
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.
- MatthewPhillips 14y agoDoesn't OpenVMS have POSIX?
- pjmlp 14y agoIt 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 14y agoI'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 14y agoWindows has a POSIX implementation. https://en.wikipedia.org/wiki/Interix https://en.wikipedia.org/wiki/Interix
- pjmlp 14y agoThe 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.
- blub 14y agoWould be much more useful to say why it took that long...
- to3m 14y agoWell, 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.
- eps 14y agoWas it because epoll vs iocp differences?
- udp 14y agoNow 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.
- pjmlp 14y agoSolaris?
- udp 14y agoInteresting - I wasn't aware that any other platform implemented IOCP. I wonder how that performs vs. traditional I/O with /dev/poll?
- pjmlp 14y agoYou can get information about it here http://web.archive.org/web/20110719052845/http://developers.sun.com/solaris/articles/event_completion.html http://web.archive.org/web/20110719052845/http://developers....
- eps 14y agoIt 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.
- rumcajz 14y agoepoll/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.