Darren New <dne### [at] sanrrcom> wrote:
> But yes, I have used named pipes in Unix before, and they can be 
> surprisingly handy for some things. Kind of annoying in that (at least 
> back then) the locking/exclusion semantics made things difficult. 
> Difficult enough I wound up writing a socket listener instead and 
> replaced the I/O stuff with libraries to talk to the sockets.

  I don't know why, but somehow you always succeed in doing two things:

1) Whenever someone belittles Windows, especially on its API and its
capabilities, for example by saying that Windows does not support this
or that, you almost always have a counter-argument ready, telling that
Windows *does* support it. (And even if the support is extremely hard
for a regular user to use, while the same feature in eg. linux is rather
simple to use, you still manage to make it *sound* like it's a completely
trivial thing to do in Windows as well, even if it really isn't.)

2) Whenever someone exalts unix in general or linux in particular, and
this is something which is absolutely undeniable, you often aknowledge
it, but *still* manage to somehow find something negative about it, making
it sound less useful. (While I'm not doubting your honesty, it often is
something which is rather difficult to verify in a few minutes, especially
for someone who is not thoroughly acquainted with the internal workings of
unix/linux/posix, which sometimes just feels too convenient.)

  I'm not saying that what you are saying is not true. I just sometimes
get the feeling that you make things sound more positive or negative than
they really are, on purpose.

-- 
                                                          - Warp

Post a reply to this message

Darren New wrote:
> Not surprisingly, if you use the UNIX interface libraries to access
> Windows juju, no, it might not work.  That whole "lowest common
> denominator" type thing doesn't really work anywhere once you get
> sophisticated about things.   :-)

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.

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.

Something I think is interesting on Unix, even though I have never really
done it:
Download a .iso using BitTorrent. Burn it to a real CD. Delete the .iso to
save hard disk space. You can still keep seeding the torrent by
reconfiguring the torrent client to read from /dev/cdrom instead of
~/whatever.iso. Do *that* in Windows!

Post a reply to this message

Warp wrote:
> 1) Whenever someone belittles Windows, especially on its API and its
> capabilities, for example by saying that Windows does not support this
> or that, you almost always have a counter-argument ready, telling that
> Windows *does* support it. 

Well, oddly enough, when I say in public that Linux can't do something 
it can, I usually get corrected also. :-)

> (And even if the support is extremely hard
> for a regular user to use, while the same feature in eg. linux is rather
> simple to use, you still manage to make it *sound* like it's a completely
> trivial thing to do in Windows as well, even if it really isn't.)

It's not hard to use named pipes or the "odd syntax" names if you know 
about them and use (for example) man(2) level calls instead of man(3) 
level calls.

> 2) Whenever someone exalts unix in general or linux in particular, and
> this is something which is absolutely undeniable, you often aknowledge
> it, but *still* manage to somehow find something negative about it, making
> it sound less useful. (While I'm not doubting your honesty, it often is
> something which is rather difficult to verify in a few minutes, especially
> for someone who is not thoroughly acquainted with the internal workings of
> unix/linux/posix, which sometimes just feels too convenient.)

I've done a lot of work with UNIX, usually on server type stuff. Before 
that, my server type stuff was all done on mainframes, where lots of 
attention was paid to getting things right in corner cases UNIX 
traditionally doesn't (or didn't) address. So yeah, I often mention 
problems I run into.

I've done more user-level stuff in Windows, usually using the MS servers 
that come with it and are thus nicely integrated et al, so I don't have 
to worry about the crap parts. I suspect if I'd done more system-level 
high-reliability work in Windows, I'd have just as many war stories 
about that too.

I think I'm pretty fair at mentioning stupidities in Windows, too, yes? 
It's not like I deny Windows has its warts.

The Windows API is way, way more complex than the UNIX APIs, even 
discounting legacy stuff. Most people don't ever actually learn it in 
any sort of organized way, in part because (as far as I know) there 
isn't any way to just sit down and read the API. There's no man(2) 
equivalent you can just spend a week reading. So I correct 
misconceptions, is all.

>   I'm not saying that what you are saying is not true. I just sometimes
> get the feeling that you make things sound more positive or negative than
> they really are, on purpose.

I guess sometimes I just feel it needs some balance. :-)  Besides, it 
would be boring if we all just agreed with everything. ;-)

But yeah, I guess when someone says "UNIX is great because it has X that 
Windows doesn't", my first reaction is indeed to say "Windows has X, and 
UNIX's X has limitations that have bitten me in the past." Mainly 
because UNIX in general tends to target the "90% correct is good enough" 
market, and I strive for excellence in my programs, and I learned to 
program on a machine where a crash produced about a ream of print-out so 
you could track down what went wrong.

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

Post a reply to this message

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

Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> But yes, I have used named pipes in Unix before, and they can be 
>> surprisingly handy for some things. Kind of annoying in that (at least 
>> back then) the locking/exclusion semantics made things difficult. 
>> Difficult enough I wound up writing a socket listener instead and 
>> replaced the I/O stuff with libraries to talk to the sockets.
> 
>   I don't know why, but somehow you always succeed in doing two things:
> 
> 1) Whenever someone belittles Windows, especially on its API and its
> capabilities, for example by saying that Windows does not support this
> or that, you almost always have a counter-argument ready, telling that
> Windows *does* support it. (And even if the support is extremely hard
> for a regular user to use, while the same feature in eg. linux is rather
> simple to use, you still manage to make it *sound* like it's a completely
> trivial thing to do in Windows as well, even if it really isn't.)
> 
> 2) Whenever someone exalts unix in general or linux in particular, and
> this is something which is absolutely undeniable, you often aknowledge
> it, but *still* manage to somehow find something negative about it, making
> it sound less useful. (While I'm not doubting your honesty, it often is
> something which is rather difficult to verify in a few minutes, especially
> for someone who is not thoroughly acquainted with the internal workings of
> unix/linux/posix, which sometimes just feels too convenient.)
> 
>   I'm not saying that what you are saying is not true. I just sometimes
> get the feeling that you make things sound more positive or negative than
> they really are, on purpose.
> 
So, he does this in other conversations too, not just ones on economics? lol

-- 
void main () {

     if version = "Vista" {
       call slow_by_half();
       call DRM_everything();
     }
     call functional_code();
   }
   else
     call crash_windows();
}

<A HREF='http://www.daz3d.com/index.php?refid=16130551'>Get 3D Models, 
3D Content, and 3D Software at DAZ3D!</A>

Post a reply to this message

Patrick Elliott wrote:
> So, he does this in other conversations too, not just ones on economics? 

And programming languages. ;-)

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

Post a reply to this message

Nicolas Alvarez wrote:
> 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.

Oh, and BTW, I saw on a MS blog (while searching for something else) 
that someone complained they couldn't open "\\?\GLOBALSPACE\..." in 
.NET. The answer was "Yes, .NET checks for paths that start that way on 
purpose and refuses to open them because it isn't portable."

WTF?  This is Microsoft. :-)

So, yeah, even .NET won't let you read from shadow copies without 
dropping down into C or something.

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

Post a reply to this message

Eero Ahonen <aer### [at] removethiszbxtnetinvalid> wrote:
> Invisible wrote:
> > So check this out: Apparently piping works on Windoze.
> >
> > I knew redirecting the three standard handles works on Windoze, but I
> > had no idea you could actually pipe data directly from one program to
> > another. I thought only Unix could do that particular trick.
>
> Welcome to world of PC's. IIRC piping worked even on MS-DOS (eg. type
> autoexec.bat|more).

Yes, that's the only pipe I used on DOS.  After all, what good is a pipe when
you don't have grep, sed and the whole gang?...

Post a reply to this message

Darren New wrote:
> Oh, and BTW, I saw on a MS blog (while searching for something else)
> that someone complained they couldn't open "\\?\GLOBALSPACE\..." in
> .NET. The answer was "Yes, .NET checks for paths that start that way on
> purpose and refuses to open them because it isn't portable."

WTF indeed! o_O

Post a reply to this message

Warp wrote:
> Windows *does* support it. (And even if the support is extremely hard
> for a regular user to use, while the same feature in eg. linux is rather
> simple to use, you still manage to make it *sound* like it's a completely
> trivial thing to do in Windows as well, even if it really isn't.)

Actually, I think I've realized what's going on here.

I've used enough different systems that incidental awkwardness doesn't 
bother me. Weird syntax and clunky that's annoying to work around isn't 
a problem for me any more.  Fundamental breakage that can't be avoided 
is a problem for me, because I tend to run into this sort of thing a lot 
in the kinds of stuff I do. The stuff I do needs to be correct when it's 
working, even tho I don't always design things for 100% uptime.

So the fact that you need to use some OS-specific call to create a 
volume shadow copy and what you wind up with is some weird string like 
\\?\globalnamespace\vss\{12318-847-randomguid-381}
as the root directory (and you need more OS-specific calls to get to it) 
doesn't bother me nearly as much as (say) the inability to make a 
consistent backup of a running UNIX file system because it's changing 
between the time you stat the file and the time you open it.

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

Post a reply to this message