(no subject)

[torkell]

Seen on a web site distributing a RTSP implementation in source code form:

How to configure and build the code on Windows

To configure the code for Windows, first unpack it on a Unix machine

The justification for this is, apparently, "it's rather hard to imagine anyone doing serious development of networking software without having any access to a Unix machine". I do have access to a unix machine, however that machine happens to be at the university, which is not where I am.

Come on, you unix fanboys need to learn that not everyone uses unix or unix-variants. Would you be happy if I distributed code that compiled on linux, but only if you first unpacked it on a windows box?

Comments

[olego.livejournal.com]

Hey, I'm planning (still planning) to make my puzzle run on BOTH Windows AND *nix. (Though I don't know how I'd accomplish it. :-D)

At least to me, Windows has 2 different networking modes.

The first is just like *nix, but worse: it has only a handful of FDs, it doesn't treat files and sockets the same way, etc. All these are the lowercase function names.

But then there are the CamelHump functions, which provide functionality I've never heard in Unix before. Like a function call to accept a connexion, based on the IP. (As opposed to accept(), check IP, and close().) It also provides a nice multi-threaded replacement for select().

But I agree with your frustration. Writing good code means going by standards, and not using platform-specific hacks.

[torkell]

CamelHump? Not heard that term before. But yes, some of the WSA* and mixed-case functions are very nice.

BTW, you can feed socket handles to the Win32 ReadFile* and WriteFile* functions. Come to think of it, there's not much in the way of I/O handles that you can't feed to those. Shame you can't use CreateFile to create and open sockets.

Anyway, I didn't know you were making a puzzle. I shall have to give it a go once it appears, as the last one was very good.