Nicolas Alvarez wrote:
> That's not the Unix interface. open() is POSIX, I would be surprised if it
> worked at all on Windows. But fopen() is standard C, and I would guess on
> Windows it's implemented using CreateFile, not open.

I think it depends on the library, yes. :-)  Certainly open() works on 
every Windows C compiler I've used. It's not any more native than 
fopen() is, tho.

> Most open-source command-line tools don't work with any \\Windows\Crap. I
> once tried to access the CDROM drive as raw blocks on Windows, and only one
> tool (a port of dd) succeeded at reading from "\\.\Cdrom0". I don't care if
> they use UNIX interfaces or what. All I care is that they don't work, and
> they would with a plain old Unix fifo.

Depending what you're doing with them, yes. For plain old reading and 
writing, sure, that stuff works better under UNIX. It's certainly easier 
if you're used to unix-style programming.

On the other hand, try doing something like copying a file, including 
all the attributes (permissions, auditing, encryption, etc) and 
everything else, with a unix-style program. There's a reason Windows is 
more complicated - it really does do more stuff.

> reconfiguring the torrent client to read from /dev/cdrom instead of
> ~/whatever.iso. Do *that* in Windows!

I don't think that would work in Windows, AFAIK. Does /dev/cdrom really 
stop reading under Linux when you get to the end of the data? I'll have 
to give that a go. :-)

No, Windows is definitely not as device-agnostic as UNIX is. Doing funky 
stuff really requires you to know what kind of device you're talking to 
in Windows more than Linux.  It's not absolute, but it's certainly more 
problematic.

-- 
Darren New / San Diego, CA, USA (PST)

Post a reply to this message