From: Peter J. Holzer on
On 2010-03-08 20:53, Ilya Zakharevich <nospam-abuse(a)ilyaz.org> wrote:
> On 2010-03-08, Ben Morrow <ben(a)morrow.me.uk> wrote:
>> then: TTBOMK there aren't any C libraries for native Win32 (without any
>> sort of Unix emulation layer) which don't use cmd.exe for system(3).
>
> This statement is IMO an oxymoron; system() is ALREADY a part of
> "unix-emulation layer".

Only if you count C itself as part of the "unix-emulation layer".

hp
From: Ilya Zakharevich on
On 2010-03-08, Peter J. Holzer <hjp-usenet2(a)hjp.at> wrote:
> On 2010-03-08 20:53, Ilya Zakharevich <nospam-abuse(a)ilyaz.org> wrote:
>> On 2010-03-08, Ben Morrow <ben(a)morrow.me.uk> wrote:
>>> then: TTBOMK there aren't any C libraries for native Win32 (without any
>>> sort of Unix emulation layer) which don't use cmd.exe for system(3).
>>
>> This statement is IMO an oxymoron; system() is ALREADY a part of
>> "unix-emulation layer".
>
> Only if you count C itself as part of the "unix-emulation layer".

No. system() is not a part of C.

BTW, let me clarify: I suspect what is a "Unix emulation layer" for
Ben is just "implementation of POSIX APIs on top of
`(the-given-)system'-calls" for me...

Yours,
Ilya
From: Ben Morrow on

Quoth Ilya Zakharevich <nospam-abuse(a)ilyaz.org>:
> On 2010-03-08, Peter J. Holzer <hjp-usenet2(a)hjp.at> wrote:
> > On 2010-03-08 20:53, Ilya Zakharevich <nospam-abuse(a)ilyaz.org> wrote:
> >> On 2010-03-08, Ben Morrow <ben(a)morrow.me.uk> wrote:
> >>> then: TTBOMK there aren't any C libraries for native Win32 (without any
> >>> sort of Unix emulation layer) which don't use cmd.exe for system(3).
> >>
> >> This statement is IMO an oxymoron; system() is ALREADY a part of
> >> "unix-emulation layer".
> >
> > Only if you count C itself as part of the "unix-emulation layer".
>
> No. system() is not a part of C.

It's in the standard library, so it's part of C. (Unlike, say, open(2),
which isn't.)

> BTW, let me clarify: I suspect what is a "Unix emulation layer" for
> Ben is just "implementation of POSIX APIs on top of
> `(the-given-)system'-calls" for me...

No. I consider Cygwin &c. emulation layers because they don't just
provide libc, they also remap the filesystem[0] and (attempt to) provide
Unixish kernel-level services like fork and ptys which aren't
implemented in NT. From the point of view of an application program like
perl, Cygwin behaves a lot more like a rather strange Unix than it does
like some variant of Win32, which is why $^O is different.

Ben

[0] Yes, I am aware that Win32 also remaps the filesystem relative to
the NT kernel, and that Interix is probably better described as 'a
separate OS running over the NT microkernel' than 'an emulation layer
running over Win32'.

From: Ilya Zakharevich on
On 2010-03-09, Ben Morrow <ben(a)morrow.me.uk> wrote:
>> BTW, let me clarify: I suspect what is a "Unix emulation layer" for
>> Ben is just "implementation of POSIX APIs on top of
>> `(the-given-)system'-calls" for me...
>
> No. I consider Cygwin &c. emulation layers because they don't just
> provide libc, they also remap the filesystem[0] and (attempt to) provide
> Unixish kernel-level services like fork and ptys which aren't
> implemented in NT.

You just confirm my statement: I do not care what is kernel-level and
what not (same as a Perl script - it would not care). You do.

> From the point of view of an application program like
> perl, Cygwin behaves a lot more like a rather strange Unix than it does
> like some variant of Win32, which is why $^O is different.

IMO, any Perl port must be "just a strange flavor" of another port (as
far as possible). All significant differences must be triggered
explicitly, by pragmas.

Yours,
Ilya