Mailing List Archive

> Code which happens to involve "fork" is generally not in this
> category, but rather still live and being maintained and
> developed, but by someone who isn't working on NT. Unix is not
> buried yet, and few customers of NT are totally replacing all of
> their other platforms and going to a NT-only status - implying
> these things sounds more like a marketing viewpoint than a
> technical one.

And it is highly unlikely that Unix will ever be buried. Religion
aside we're a Unix house and have no interest in other OS's other
than in supporting customers that use them.

> The desire here is to be able to write portable code that is
> usable on multiple systems, not just to continue to use old Unix
> code on NT systems.

Although if NT were compatible with our standard systems, it might
get to first base with us. Otherwise it's just a curiosity, something
that we might play with in our spare time (BTW - to be fair, NT is
not half bad. I won't comment in this forum on what I think of it's
brethren though ...)

So I think it is to NT's advantage to be able to handle standard

utilities with minimal porting effort. If the effort is too high,
NT won't get considered.

> I will agree that turning this thread (no pun intended) towards an anti-MS
> bias is counter-productive and steers it away from the main focus. But the
> base fact remains, as Tom pointed out: WinNT is *supposed* to be a POSIX-
> compliant O/S. Being able to claim that gains MS certain inroads. But the

> reality is that it isn't, since fork() is part of the POSIX base that NT
> claims.

Perhaps the best thing to do is simply agree that Windows NT is a different
operating system and is a non-POSIX compliant OS that needs to be dealt with
by Perl the same way as any other non-POSIX system. Other NON-Posix systems
lack fork(), thus if fork is desirable in general, then a general solution
to the non-Posix problem needs to be found.

Dale
(with the broken replyto!)
amon@gpl.com

>(PS: I do agree however, with the general sentiments about NT. Every pro<SNIP>
>data format lessens the power of perl that much more. When are software
>engineers on NT/windows going to realize that being universally readible is
>desirable too? )

Um -- what do you mean that things aren't readable? Or do
you mean legible? :-)

--tom

In-Reply-To: <199512110404.UAA16263@imail1.microsoft.com>
I've been away for a week, learning about running a "dying" (?) OS on a
brand new 64 processor Pentium MMP machine, so I missed this tread when
it blew up.

My heart goes out to those poor, misunderstood, altruistic saints at
Microsoft. How could we possibly think they had ulterior motives? I
mean, look at how they have fed the NT version of Perl back into the
mainstream. Look at how they embraced CORBA with open arms.

p.s. Can't we drop the PerlPorters subscription to NTPerl? I am getting
fed up of this martyr act that people connected to Microsoft seem to use
all the time.

Alan Burlison aburlison@cix.compulink.co.uk

At 04:06 PM 12/15/95 -0500, Chip Salzenberg wrote:
>NT Perl does OLE but not DLLs.

You're somewhat behind the times, Perl for Win32 now does Dynaloading.

>It's not furthering
>Perl's interests, or users' interests, to support NTPERL; it's using
>Perl to leverage NT.

How's that? I myself come from an open-systems (i.e. Unix) background, and
can sympathize with many of the sentiments expressed by the Perl community
regarding the NT Perl. However, I think that NT Perl (now Perl for Win32),
is *BENEFICIAL* to Perl as a whole. I seem to recall Larry Wall declaring
that Perl's purpose is "text processessing, the Unix Way" which, to me, is
not about using fork() and other arcane hacks (very nice hacks that have
proved invaluable, but still hacks). "doing things The Unix Way" does not
equate with "using BSD system calls" or "using System 5 system calls". The
Unix Way is about leverage, about portability (both code and data), about
simplicity of design, about avoiding creeping featurism and concentrating on
a single task. The port to Win32 has been a rather painful process
(philosophically, at least), but I think Good Things are in store for Perl
as a whole. Having been jolted out of our comfort-zone, we're now being
coaxed into avoiding Unixisms like `pwd` and moving to portable solutions
like Cwd::cwd. In conclusion, I agree somewhat with the idea expressed by
others that "NT Perl must be as close to Unix Perl as possible", but only in
that Unix Perl should also be as close to NT Perl as possible. For Perl to
grow as a REAL language, it has to break free of its
honoured-but-restrictive Unix roots, and move towards true portability and
flexibility.

Enough of my weekly rant for now, back to worrying about real issues like
recycling white-paper, paying the bills and placating my significant other. ;-)




Wei-Yuen_Tan@hip.com
Grunt worker
h i p c o m m u n i c a t i o n s i n c.

>I seem to recall Larry Wall declaring
>that Perl's purpose is "text processessing, the Unix Way" which, to me, is
>not about using fork() and other arcane hacks (very nice hacks that have
>proved invaluable, but still hacks).

Maybe in perl0 .. perl3 or so, but certainly by perl5 perl has
become a general purpose programming language. It's NOT just
about text processing. This is a myth.

Perl is also about insulating the user from annoying system
dependencies. Of course, that's what POSIX was for, and
while we have OpenVMS and OpenVMS, we don't have OpenNT. :-)

Wei-Yuen Tan is doing good work in a bad world, so please don't
pick on him too much.

--tom

PS: WYT, maybe you should include a doc explaining which
of the standard perl functions don't work under NT. I keep
seeing postings about this.

Functions for SCALARs or strings:
chomp, chop, chr, crypt, hex, index, lc, lcfirst, length,
oct, ord, pack, q/STRING/, qq/STRING/, reverse, rindex,
sprintf, substr, tr///, uc, ucfirst, y///

Regular expressions and pattern matching:
m//, pos, quotemeta, s///, split, study

Numeric functions:
abs, atan2, cos, exp, hex, int, log, oct, rand, sin, sqrt,
srand

Functions wfor real @ARRAYs:
pop, push, shift, splice, unshift

Functions for list data:
grep, join, map, qw/STRING/, reverse, sort, unpack

Functions for real %HASHes:
delete, each, exists, keys, values

Input and output functions:
binmode, close, closedir, dbmclose, dbmopen, die, eof,
fileno, flock, format, getc, print, printf, read, readdir,
rewinddir, seek, seekdir, select, syscall, sysread,
syswrite, tell, telldir, truncate, warn, write

Functions for fixed length data or records:
pack, read, syscall, sysread, syswrite, unpack, vec

Functions for filehandles, files, or directories:
-X, chdir, chmod, chown, chroot, fcntl, glob, ioctl, link,
lstat, mkdir, open, opendir, readlink, rename, rmdir,
stat, symlink, umask, unlink, utime

Keywords that control flow of your perl program:
caller, continue, die, do, dump, eval, exit, goto, last,
next, redo, return, sub, wantarray

Keywords altering or affecting scoping of identifiers:
caller, import, local, my, package, use

Miscellaneous functions:
defined, dump, eval, formline, local, my, reset, scalar,
undef, wantarray

Functions for processes and process groups:
alarm, exec, fork, getpgrp, getppid, getpriority, kill,
pipe, qx/STRING/, setpgrp, setpriority, sleep, system,
times, wait, waitpid

Keywords related to perl modules:
do, import, no, package, require, use

Keywords related to classes and object-orientedness:
bless, dbmclose, dbmopen, package, ref, tie, untie, use

Low-level socket functions:
accept, bind, connect, getpeername, getsockname,
getsockopt, listen, recv, send, setsockopt, shutdown,
socket, socketpair

System V interprocess communication functions:
msgctl, msgget, msgrcv, msgsnd, semctl, semget, semop,
shmctl, shmget, shmread, shmwrite

Fetching user and group info:
endgrent, endhostent, endnetent, endpwent, getgrent,
getgrgid, getgrnam, getlogin, getpwent, getpwnam,
getpwuid, setgrent, setpwent

Fetching network info:
endprotoent, endservent, gethostbyaddr, gethostbyname,
gethostent, getnetbyaddr, getnetbyname, getnetent,
getprotobyname, getprotobynumber, getprotoent,
getservbyname, getservbyport, getservent, sethostent,
setnetent, setprotoent, setservent

Time-related functions:
gmtime, localtime, time, times

At 12:13 PM 12/19/95 MST, Tom Christiansen wrote:

>PS: WYT, maybe you should include a doc explaining which
>of the standard perl functions don't work under NT. I keep
>seeing postings about this.

That's the purpose of STATUS.TXT that comes with Perl for Win32. I haven't
touched it in a while though, it's very possible that I've neglected
updating it. Apologies to all affected.

Most Unix-specific functions are unavailable under Win32, they either are
unimplementable or don't make sense conceptually and hence should be
avoided. The unsupported functions are:

> Input and output functions:
> dbmclose, dbmopen, flock

I had DBM support going for a bit, but a bug has shown up with indices being
corrupted. Haven't had time to fix it. Also, STATUS.TXT incorrectly states
that select(,,,) is unimplemented, it has in fact passed all our tests with
flying colours.

> Functions for filehandles, files, or directories:
> chmod, chown, chroot, fcntl, ioctl,
> lstat, readlink,
> stat, unlink, utime

> Functions for processes and process groups:
> alarm, fork, getpgrp, getppid, getpriority, kill,
> pipe, times, wait, waitpid

%SIG also doesn't do anything useful under Win32.

> Keywords related to classes and object-orientedness:
> dbmclose, dbmopen

> System V interprocess communication functions:
> msgctl, msgget, msgrcv, msgsnd, semctl, semget, semop,
> shmctl, shmget, shmread, shmwrite

> Fetching user and group info:
> endgrent, endhostent, endnetent, endpwent, getgrent,
> getgrgid, getgrnam, getlogin, getpwent, getpwnam,
> getpwuid, setgrent, setpwent
>
> Fetching network info:
> endprotoent, endservent,
> gethostent, getnetbyaddr, getnetbyname, getnetent,
> getprotobyname, getprotobynumber, getprotoent,
> getservent, sethostent,
> setnetent, setprotoent, setservent


Wei-Yuen_Tan@hip.com
Grunt worker
h i p c o m m u n i c a t i o n s i n c.

> From: Wei-Yuen Tan <Wei-Yuen_Tan@hip.com>
>
> At 04:06 PM 12/15/95 -0500, Chip Salzenberg wrote:
> >NT Perl does OLE but not DLLs.
>
> You're somewhat behind the times, Perl for Win32 now does Dynaloading.
>
> >It's not furthering Perl's interests, or users' interests, to support
> >NTPERL; it's using Perl to leverage NT.
>
> How's that? I myself come from an open-systems (i.e. Unix) background, and
> can sympathize with many of the sentiments expressed by the Perl community
> regarding the NT Perl. However, I think that NT Perl (now Perl for Win32),
> is *BENEFICIAL* to Perl as a whole.

I agree - so long as Perl for Win32 _is_ Perl.

Perl for Win32 will bring Perl to the masses.

> The Unix Way is about leverage, about portability (both code and data), about
> simplicity of design, about avoiding creeping featurism and concentrating on
> a single task.

> The port to Win32 has been a rather painful process
> (philosophically, at least), but I think Good Things are in store for Perl
> as a whole. Having been jolted out of our comfort-zone, we're now being
> coaxed into avoiding Unixisms like `pwd` and moving to portable solutions
> like Cwd::cwd.

I'm really glad the 'coaxing' is working :-)

> In conclusion, I agree somewhat with the idea expressed by
> others that "NT Perl must be as close to Unix Perl as possible", but only in
> that Unix Perl should also be as close to NT Perl as possible. For Perl to
> grow as a REAL language, it has to break free of its honoured-but-restrictive
> Unix roots, and move towards true portability and flexibility.

I hope and pray that those fine words will be translated into active
discussions and contributions to perl5-porters and not, as has often been
the case so far, of new features appearing in Perl for Win32 without
discussion.

It should be obvious from this list that no one person or organisation has
all 'the best ideas' for perl. It follows that HIP cannot claim to have all
the best ideas for its perl porting work. Perl5 is, to a very large extent,
a group effort and is *much* the richer for it. I hope that HIP will join
in with the group and discuss its plans so that we can all agree the
best way forward.

Honest question: does the Microsoft funding of the port mean that HIP is
in any way reluctant to work actively with a group who might do significant
work for free? Would that put HIP in a difficult position? (No anti-Microsoft
flames from others please.)

Tim.

(p.s. I look forward to a Cwd.pm patch to change the $archname tests for Win32)

> From: Tom Christiansen <tchrist@mox.perl.com>
>
> Wei-Yuen Tan is doing good work in a bad world, so please don't
> pick on him too much.

Seconded.

> PS: WYT, maybe you should include a doc explaining which
> of the standard perl functions don't work under NT.

README.txt (build 100) says:

Differences between/additions to the UNIX distribution
======================================================

This port of Perl for Win32 is based upon the UNIX distribution of Perl 5.
Any modifications made to the UNIX distribution will be submitted to the UNIX
porting team so that they may be included when their next port is released.

Perl scripts written under UNIX terminate lines with a line feed.
Windows NT, however, terminates text lines with two characters: a carriage
return AND a line feed. Be warned: if you are moving Perl scripts over to
your Windows NT machine from UNIX, you may have some reformatting to do!

Since not all of the functions from the UNIX version of Perl 5 have analogs in
the Windows NT realm, we've left some unimplemented! A list of all functions
NOT implemented in this release can be found in either "STATUS.TXT" or
"STATUS.HTM".

(It ought to say _which_ 'UNIX distribution of Perl 5')

I've appended STATUS.TXT below. Please, perl5-porters, don't howl too
loudly when you read it!

It would be interesting to compare this list with one from a gcc-win32 port.


> I keep seeing postings about this.
>
> [...]
> Time-related functions:
> gmtime, localtime, time, times

I'd like to put in a vote for times() since the standard Benchmark
module is broken without it.

Tim.


You are reading: STATUS.TXT
---------------------------

Only a subset of the standard Perl 5 Kit has been implemented, as there is
usually no direct equivalent of the functionality in Windows NT.

Any functions marked with '**' will NOT warn that they are not implemented.
Providing this 'warn facility' would require changes to the Perl 5 UNIX Distribution.

Following are the unsupported functions:


Unsupported network routines
============================

getnetbyname()
getnetbyaddr()
getnetent()
getprotoent()
getservent()
sethostent()
setnetent()
setprotoent()
setservent()
endhostent()
endnetent()
endprotoent()
endservent()
socketpair()


Unsupported System V compatible IPC routines
============================================

msgctl()
msgget()
msgrcv()
msgsnd()
semctl()
semget()
semop()
shmctl()
shmget()
shmread()
shmwrite()


Unsupported I/O routines
========================

ioctl()**
select($w, $x, $y, $z)**
-- The single argument version of select HAS been implemented.


Unsupported filesystem routines
===============================

chmod()**
chroot()
fcntl()**
flock()
link()
lstat()**
readlink()**
symlink()
sysread()**
syswrite()**
umask()**
utime()**


Unsupported security-related routines
=====================================

crypt()
getlogin()**
getpgrp()
getppid()
getpriority()
getpwnam()
getgrnam()
getpwuid()
getgrgid()
getpwent()
getgrent()
setpwent()
setgrent()
endpwent()
endgrent()
setpgrp()


Unsupported process-related routines
====================================

fork()
kill()
pipe()
setpriority()
times()
wait()
waitpid()


Unsupported miscellaneous routines
==================================

alarm()
dbmclose()**
dbmopen()**
dump()**
syscall()

> From: Wei-Yuen Tan <Wei-Yuen_Tan@hip.com>
>
> Also, STATUS.TXT incorrectly states that select(,,,) is unimplemented,
> it has in fact passed all our tests with flying colours.

Ah, that reminds me. Some assorted queries ...

Is there a reason why HIP aren't using the standard tests
but have instead got a separate ./ntt/*/*.ntt test suite?
Why the different suffix?

Does HIP build/test code rely on the case of the directory and
file names in the source tree? If not could you change the case
back to lowercase where ever a directory matches one in the
standard distribution (the tet directories, for example, are
Base, Comp, Op etc instead of base, comp, op).

Was renaming the source files from *.c to *.cpp in the last
release _really_ necessary? (I presume it's related to perl
being implemented as a DLL).

Do HIP have any plans to migrate the directory structure towards
the standard one?

Finally, what is HIP's 'policy' regarding tracking perl releases
and how do you implement changes (since you can't apply patches
automatically having renamed or deleted most of the files).

Tim.

Strange sunspot activity caused Tim Bunce <Tim.Bunce@ig.co.uk> to write:
| I've appended STATUS.TXT below. Please, perl5-porters, don't howl too
| loudly when you read it!

Wouldn't it have been a shorter list to say which *were* implemented? ;-)

-spp

> From: Wei-Yuen Tan <Wei-Yuen_Tan@hip.com>
>
> Most Unix-specific functions are unavailable under Win32, they either are
> unimplementable or don't make sense conceptually and hence should be
> avoided. The unsupported functions are:
>
> > Input and output functions:
> > dbmclose, dbmopen, flock
>
> I had DBM support going for a bit, but a bug has shown up with indices being
> corrupted. Haven't had time to fix it. Also, STATUS.TXT incorrectly states
> that select(,,,) is unimplemented, it has in fact passed all our tests with
> flying colours.

So dbmclose and dbmopen will return one day. Good.

I presume flock can be emulated without much problem. Lots of scripts use it.

> > Functions for filehandles, files, or directories:
> > chmod, chown, chroot, fcntl, ioctl,
> > lstat, readlink,
> > stat, unlink, utime

Getting a reasonable stat() working is very important (File::Find for example).
Umm, what about all the -X files tests? A broken stat implies that these
are broken. I think lstat() would just be stat() on Win32.

> > Functions for processes and process groups:
> > alarm, fork, getpgrp, getppid, getpriority, kill,
> > pipe, times, wait, waitpid

As I've said elsewhere recently, times() would be useful for Benchmark.
Even a poor emulation (user time only as wall time at one second resolution)
would be better than nothing. Benchmark is useful.

> %SIG also doesn't do anything useful under Win32.

But I presume __DIE__ and __WARN__ work.


Tim.

At 12:03 AM 12/20/95 +0000, you wrote:
>
><snip>
>
>So dbmclose and dbmopen will return one day. Good.
>
>I presume flock can be emulated without much problem. Lots of scripts use it.

Yes, and flock() will be be in the next release.

>
><snip>
>
>As I've said elsewhere recently, times() would be useful for Benchmark.
>Even a poor emulation (user time only as wall time at one second resolution)
>would be better than nothing. Benchmark is useful.
>

I'm looking at times(). Maybe next release.

>> %SIG also doesn't do anything useful under Win32.
>
>But I presume __DIE__ and __WARN__ work.
>
>
>Tim.
>
>
-- Doug

I understand most of the unsupported routines under NT, but I don't
understand these two:

>Unsupported filesystem routines
...
>sysread()**
>syswrite()**

Why no sysread and syswrite? Certainly NT contains low-level reading
and writing functions (they just aren't called read() and write()).

In fact, to talk to things like tape drives under NT, you have to use the
low level win32 functions and HANDLEs because (for reasons know only to
Microsoft :-), the <stdio.h> layer on NT doesn't support opening or reading
devices (or at least it didn't the last time I checked).

Which brings up another question I have wondered about: Does the NT port of
perl allow me to open funny devices like \\TAPE0 (or whatever it is called,
I remember it is something like that)?

--
Tom.Horsley@mail.hcsc.com
Home: 511 Kingbird Circle Delray Beach FL 33444
Work: Harris Computers, 2101 W. Cypress Creek Rd. Ft. Lauderdale FL 33309
Support Project Vote Smart! They need your support in non-election years too!
(email pvs@neu.edu, 1-800-622-SMART, http://www.vote-smart.org)

>Come to think of it, has anybody ported perl for use with BOB?

You mean the cute little flying robot from Disney's `The Black Hole'
(TM)? :-)

Mx.

------------------------------------------------------------------------

Martyn J. Pearce Tel: (01494) 429529 ext. 329
Computervision Research & Development Group Facsimile: (01494) 440303

------------------------------------------------------------------------