Perl
[feature] Drop support for Win32 platforms older than Windows Vista
Perl's Win32 platform support is currently specified back to Windows 2000 and XP, however these two platforms in particular (as well as Windows Server 2003) are increasingly problematic to support. They are long out of support and have, by all indications, near zero usage share. Thus, I believe the risk-benefit balance of removing support for 2000, XP, and Server 2003 is clear enough for quick consensus.
Please feel free to describe or link issues that would be easier to solve or obsoleted without the need to support these platforms.
The advantage of being able to easily write symlink() is good.
Windows 7 still has a lot of shares, so I would like it to be supported even if there is no Microsoft official support.
Windows XP and Vista share is small (about 1%).
Personally, I think it's okay to remove support if Perl's porting is simplified.
We had a discussion about this before.
Before you can "drop support" for something, we must first actually define what "support" means and define it, as well as policies and guidelines for dropping support, and document them.
Right now the state of all of the above is, simply, complete chaos and undefinedness.
Please, do at the very least demonstrate that you have read the first post here and the linked documentation to learn that you are asking here for something that doesn't even exist, neither in the positive nor negative sense:
https://github.com/Perl/perl5/issues/18243#issue-722376918
Drop support in this case simply means allowing development and simplification of features that break functionality on these platforms.
There's nothing forbidding it in the first place. There is no support policy, list or guarantee in the documentation.
That is not true in practice, as I have observed core committers repeatedly take extra effort to ensure support back to windows 2000.
The definitions of supported platforms and making consistent the appearance and practical support is a task that needs some agreement and authority. The goal of this issue/discussion is simply to achieve consensus that nobody needs to work to support these specific platforms anymore, because we currently have not expressed that and they are hindering progress on Windows issues that already have precious few contributors capable of tackling them.
That is not true in practice, as I have observed core committers repeatedly take extra effort to ensure support back to windows 2000.
Right, which is also problematic in its own way. If demands are made on people as something that aren't simply requests or self motivation, then those should be grounded in documentation.
(Thank you for linking that issue as I had forgotten about that discussion)
Cheers. :)
The goal of this issue/discussion is simply to achieve consensus that nobody needs to work to support these specific platforms anymore, because we currently have not expressed that and they are hindering progress on Windows issues that already have precious few contributors capable of tackling them.
I'd prefer to see it the other way around, for a simple reason:
Explicitly declaring "x is now deprecated" invites people to become zealous and start cutting out things, resulting in reduced functionality, without also creating new features.
I'd rather see people declare "i want to do this, and to achieve that, i'd need to break this".
(There's also the side point of this, as far as i can tell, being the only declaration of something as deprecated without that being done in direct connection with "i want to implement this"; and i'd be unhappy to see this kind of special treatment of one thing, when no such special treatment is needed at all.)
I'd rather see people declare "i want to do this, and to achieve that, i'd need to break this".
I wish to encourage that in this discussion as well.
In that case, maybe it could be made as a round call for intent to work on windows features, explaining that there is no support policy, and inviting people to state what they fear might hinder them in doing so, to gauge if said things would actually cause opposition?
@xenu informs me that names for locales didn't really come along until Vista; this means that locale support is pretty crippled on earlier versions, and I think it's not worth our precious effort trying to do any support form them
@wchristian
Before you can "drop support" for something, we must first actually define what "support" means and define it, as well as policies and guidelines for dropping support, and document them.
Clearly defined things is beneficial in some case.
On the other hand, Practical things is good in many cases.
Isn't the point that core developers want to stop old windows support because they want to make Windows porting code more manageable and simple?
so, core team think they want to get consensus.
Isn't the point that core developers want to stop old windows support because they want to make Windows porting code more manageable and simple?
Please actually read the linked ticket and previous discussion to learn how the point is that there is no porting policy in the first place and that asking to "stop support" is asking everyone to believe in something imagined.
@wchristian
I can agree that there is no clear porting policy written.
"stop support" message maybe means "stopping newer Perl to run old windows".
@yuki-kimoto imo, the best faith reading of the material i can offer is:
"no guarantee of support is made, and if someone wants to implement a feature that would break something, it would be polite of them to ask beforehand, and the final call is with the committer and the pumpkings at their own discretion"
and imo, in lieu of actual policy i believe that should be retained, instead of engaging in special treatment for windows that would not be done for any other os
I think it seems useful to have a list of platforms such that:
- we consider not building on platform X to be a bug, to be fixed before a stable release
- we consider not building on platform Y to be expected, and not a reason to add code complexity
Some platforms will clearly be the first kind and some the second kind. Everything else is unknown until classified, but probably the answer can often be "look, if it worked yesterday and the thing that broke it isn't worth much, why did we break it?" My guess it that there are versions of Windows we would like to categorize as Y. I will raise this on the list soon.
I think it seems useful to have a list of platforms such that:
* we consider not building on platform X to be a bug, to be fixed before a stable release * we consider not building on platform Y to be expected, and not a reason to add code complexitySome platforms will clearly be the first kind and some the second kind. Everything else is unknown until classified, but probably the answer can often be "look, if it worked yesterday and the thing that broke it isn't worth much, why did we break it?" My guess it that there are versions of Windows we would like to categorize as Y. I will raise this on the list soon.
I think that defining tiers may be helpful for that.
Whats the point or purpose or proposal of this ticket? All of blead's Win2K/XP related code was removed a few years ago while I was busy with another non-perl job and not reading the ML.
The new C99 mixed declarations minimum also severely limits which CCs I can use to produce a Perl 5.41 that runs on 2000/XP/2003. Therefore while I definitely have the skills and knowledge to easily add back the 2K/XP support code to blead in a new PR, mostly likely with a perl541.dll compiled in C++ mode as a cheap quick hack to get C99's mixed decls feature. I don't have any personal hobby or day job incentive to make such a PR, since my semi-air gapped Win2K work systems, 1 or 2 not air gapped very rare XP systems, and rest of the the 2010s/2020s Win 7 systems, all are still using Perl 5.26 in 2025 built with VC 2003 i386 or VC2008 x64.
I don't see any benefits to upgrade those private biz apps to execute on a newer stable Perl than my 5.26. Since WinPerl 5.26 was 100% IMO flawless except for CPerlHost API bloat. Stable Perls 5.30-5.40 only introduced dozens of flaws, defects, de-optimizations, and introduced alot of very poorly written and poorly designed C code.
Is this ticket instead about chainsawing support < Vista of p5p/.git/dist modules? What Win32-related stuff is there to even chainsaw inside the CPAN p5p/.git/dist modules? Win32API::File.pm.xs and Win32.pm.xs are very neglected modules from p5p/.git/cpan.
The post 5.30 features of heavy runloop COWing, COW 255 default being on, very good idea but still half-baked SV_CONST() cache, sv_*_simple() sv_*_fresh() macros or inlines, don't counter balance all the other problems and heavy CPU burn and TUI console lag of post 5.30 WinPerl.
locale.c is spaghetti on WinPerl.
MSVC's next gen UCRT library was written by AI https://www.business-standard.com/companies/news/builderai-faked-ai-700-indian-engineers-files-bankruptcy-microsoft-125060401006_1.html and MS internally refuses to use link their OS and other SW against ucrtbase.dll, MS's internal policy is to link against msvcrt.dll.
the post 5.30 regexp engine does O(n^???) abuse of SvShrinkToCUR(), there are PRs open to fix this by Richard, but the PRs are stalled b/c bus factor problems, and nobody from P5P has the skills to attempt to review the PRs, since the author is making his own educated informed guesses, while all other P5P ppl understand they would be passing off pub/watercooler talk as a professional "review" if they tried to review or write input on the PRs
post 5.30 WinPerl has 10x the strace file system IO calls of 5.26 to do the same things, mostly caused by TonyC's beneficial forklift upgrade to win32_stat() combined with enhanced POSIX compatibility of UCRT (UCRT adding the CLOEXEC feature) combined with previously Unix-only PerlIO .c code suddenly passing a #ifdef test on WinPerl, and all those then then cause a nasty interaction causing a sky high amount of win32_isatty(); calls to execute.
My pet project feature of https://perldoc.perl.org/perlvar#$%7B%5EWIN32_SLOPPY_STAT%7D disappeared in 5.34.0. But that isn't necessarily a bad thing, since I'm not sure if WinPerl 5.41 actually needs the feature after the win32_stat() forklift upgrade. The upgrade stopped using any libc func calls from the MS CRT. That flag controlled interactions with the "libc" view of the WinOS. WinPerl after the upgrade is 100% native Win32 code.
Alot of defects, not enough benefits. WinPerl 5.26 is good enough to do what its needs to at my day job, and still recent enough to import a new CPAN module and not have PP syntax errors.
