develooper Front page | perl.perl5.porters | Postings from June 2022

Re: Which versions of Windows are still supported ?

Thread Previous | Thread Next
Craig A. Berry
June 1, 2022 02:01
Re: Which versions of Windows are still supported ?
Message ID:
On Tue, May 31, 2022 at 1:10 AM Nicholas Clark <> wrote:
> On Tue, May 31, 2022 at 06:37:02AM +0200, Tomasz Konojacki wrote:
> > On Tue, 31 May 2022 12:36:30 +1000
> > sisyphus <> wrote:
> >
> > > Specifically, as regards creating patches to bleadperl, do I need to cater
> > > for the possibility that someone might be building bleadperl on Windows XP ?

Not "building on" but possibly "targeted for" as I think has been
covered, but generally I think it's a bad idea for Perl to try to
support very old software that is unsupported by the vendor,
especially where extended support for a proprietary product ended over
eight years ago.

> > > Might it make a difference if the part of bleadperl I'm patching was
> > > dual-life ?

It sounds possible, depending on where upstream is, but unless the
module maintainer is actively advocating for and maintaining a Windows
XP target, I don't think anyone is in a position to say you should try
to support Windows XP.

You might have more trouble with old versions of Strawberry Perl and
the embedded Cygwin.  At least that was the case for me when I updated
the Win32 extension recently and got bitten by the fact that the CI
testing uses old versions of Strawberry Perl that embed old versions
of Cygwin that don't define libraries that had been available for
years at the time of those Cygwin releases.  In other words, the test
infrastructure may tell you what you have to do, which won't
necessarily match up with what it makes sense to support.

> Whether XP is still worth anything is not really something I can judge.
> (IIRC we've had long discussions about the trade offs)

There are many excellent releases of Perl that work on Windows XP,
some of them in the 5.8.x series in case you know anyone associated
with it :-).  I suggest that people go off and find them; if they have
security bugs that have not been fixed, they are probably among the
least of the dangers of running XP in the second decade of this

> From what I remember (as a complete outsider) there are at least two
> significant API gains from raising this to Vista. One was something to do
> with files or maybe simlinks. The other is that (I believe) it's technically
> just possible to really fork in Vista. (Whether this is actually like saying
> that 'perl 5.6 is "Marketing Compatible" Unicode', or actually something
> you'd use in anger, I don't know.)

I'm mostly an outsider too, but I think these things don't, in the
Princess Bride sense, mean what we think they mean.  I have a vague
memory that symlinks have very limited use cases and didn't really
have a prayer of working in a way that could pass the Perl test suite.
I would be delighted to discover that I am wrong or out-of-date about

I believe what was new regarding fork() was the ability to clone
process context, the searchable keyword apparently being
RtlCloneUserProcess.  See:

But whether this plays nice with all of the other moving parts of two
processes sharing things seems more doubtful.

> As in, "could we drop all the pseudo-fork hackery, and just fork for real?"

I don't know, but the folks at Microsoft Research think fork() is a
bad idea on any platform:

which may not bode well for Microsoft's supporting what's needed to do
fork() long term.  The short, quotable version of that article is
"fork was a clever hack for machines and programs of the 1970s that
has long outlived its usefulness and is now a liability."  So maybe
the question is what the concurrency model for Perl should be in the
middle of the 21st century, not whether fork emulation is still
viable.  But that's OT for this thread and way outside of my areas of

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About