From: Peter J. Holzer on 8 Mar 2010 17:31 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 8 Mar 2010 21:33 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 8 Mar 2010 22:35 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 10 Mar 2010 15:22 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
First
|
Prev
|
Pages: 1 2 3 Prev: Decimal sort Next: FAQ 4.65 How can I get the unique keys from two hashes? |