develooper Front page | perl.perl5.porters | Postings from July 2018

Re: What platforms should we remove support from?

Thread Previous | Thread Next
Karl Williamson
July 30, 2018 17:43
Re: What platforms should we remove support from?
Message ID:
Top posted.

Based on feedback so far, here is an updated list of potential 
candidates for removal:

amigaos  current code to support this is broken and hard to maintain, 
hence a strong vote from LeonT to remove this

epoc Support already officially dropped; code still here to handle it is 
a relic

irix people still use perl on irix, though maybe not modern perls.  A 
box to test on is in the works.

MacOS (classic)  Support already officially dropped; code still here to 
handle it is a relic

sunos  (not solaris)
symbian The platform is dead, and this port was just a toy

vos  Stratus has patched this in the past few years, so khw thinks this 
should stay

wince  The people who wanted to keep it have dropped their opposition, 
and it's probably currently broken

MSWin32 VC6 Has specialized code.  khw's feedback on this, is that I had 
to work around issues with this in 5.27, so some of that specialized 
code is very recent.   I could have used that time more productively, 
and think we should drop support for this.

On 07/29/2018 12:15 PM, Karl Williamson wrote:
> On 07/28/2018 06:16 PM, Tomasz Konojacki wrote:
>> On Sat, 28 Jul 2018 17:43:25 -0600
>> Karl Williamson <> wrote:
>>> We agreed to remove support for Ultrix in the thread beginning at
>>> What other ancient platforms should go (like Atari) ?
>> Recently there was some discussion about removing Windows CE support:
>> Also, it's not really a platform, but dropping Visual C++ 6 support is a
>> recurring topic on this list, most recently in this ticket:
> ok.  Comments welcome on these.
> I am of the opinion that we shouldn't remove stuff just because it's old 
> and even disused.  As others said in the thread, only if it's causing us 
> problems now should it be removed.  These problems could mean a bunch of 
> specialized code for it, such as VC++6 has, or a bunch of open tickets 
> that would require adding specialized code to fix.
> So, for example, if the only specialized code is a hints file that just 
> sets some compile options, I see no need to remove that hints file. 
> However, if those options are essentially a euphemism for doing 
> specialized code that applies just to the given OS, then it would be a 
> candidate for removal.  Such is the case for Ultrix, which sets 
> LOCALE_ENVIRON_REQUIRED.  That enables some complex code to be compiled, 
> that is unused anywhere by in Ultrix.  And this is why I want to get rid 
> of Ultrix.
> I grepped through the hints files looking for other instances like this. 
>   I found just these:
>"$ccflags -DPERL_ISC"
>"$ccflags -DPERL_ISC"
> $_defemxcrtrev -D__ST_MT_ERRNO__"
> $_defemxcrtrev -D__ST_MT_ERRNO__"
> I did not look to see what these specialized options do, but I think 
> these are a starting point of things to consider removing support for.
> Even though the core C language files may not have much in the way of 
> specialized support, the supporting modules shipped with core do.  There 
> are a bunch of instances where $^O is examined.  I grepped for those, 
> and threw out any .t or .pod files.  In the interest of moving forward, 
> I compiled this list of platforms that are tested for, minus the ones I 
> am confident that we want to continue to support:
> amigaos
> android
> apollo
> bitrig
> dec_osf
> dgux
> dragonfly
> epoc
> haiku
> interix
> irix
> MacOS
> mint
> mpeix
> msys
> NetWare
> nto
> os2
> qnx
> riscos
> sunos
> symbian
> unicos
> unicosmk
> uts
> uwin
> vos
> Don't be appalled if something you care about is on this list.  Just let 
> the list know.  And even if something is on the list, if we decide it's 
> not worth supporting, then we (or maybe just I) can look and see how 
> much code is needed to support it, and if it's a trivial amount, I don't 
> see a need to remove it.

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