|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |