Problems with Win 10 Pro 64-bit to Get ActivePERL to Run

Hey All. Sorry for this broad/general question, but my schedules are very tight nowadays and maybe somebody can save me the time of researching this question. QUESTION: What’s the deal with Windows 10 Pro 64-bit and trying to run ActivePERL 5.26 (or 5.28)? The last time I installed a working version of ActivePERL was in 2017 (5.??) on a Win 7 PC. Everything worked fine on that build, and on the build before that (2010)… [and on the build that I had before that (2004)].

Now that I have finally upgraded to Win 10 64x and installed ActivePERL 5.26, I can’t seem to get much of ANYTHING to work well. Is there a short answer to that? Is it a Win 64x security thing?

The download build goes OK.

  • I try to run some scripts and nothing is working as it should.
  • Term::ReadKey seems to be a part of this package, but that ain’t working as it expected either (does not read key press)
  • Even reading arrays doesn’t seem to be happening for simple scalar assignments??

I installed as “Administrator”.
I checked/changed permissions on any/all folders that PERL resides in, uses, or writes to.

I know that at some point I’ll have to try to find the time to sit down and look at this thing, but for now any suggestions are appreciated.

Thanks much.

MISC. NOTE: I’ve got a good number of scripts that are in the 600-line to 1000-lines of code range. So, line-by-line deconstructing this thing would be a monster (nightmare) task.

Hi John,
Not sure if you saw this but our newest Perl, is Perl 5.32. It represents a radical departure for us where it’s only delivered via our package manager State Tool. But I know it works great on Win 64. If you’re not afraid of the command line you might want to give it a try. More information here Sometime next year we’ll be reintroducing installers.

As ActivePeERL 5.26 or 5.28 in general those are know to work but hard to say without seeing specific error messages.

Term::ReadKey could very well be a Window specific issue. If you have any further information feel free to post it here.

Reading arrays, highly doubtful that it’s broken in our build or we would have heard about that for now. But then again I’m not a Perl expert, but I do work with tons of them. Feel free to post some sample Perl code and we can at least verify if it’s suppose to work or not.

Thanks for the note, Scott. I was figuring that somebody might chime in with a word that Win 64x is finicky, just like it can be with so many other things. All of my previous ActivePERL installations installed and worked right out of the bag without a hitch. That’s “one of” the reasons I waited this long to change to Win 64x. (I think that the first install that I used of ActiveState was in 2004?.. possibly it was at the previous job in 2001??)

One of the issues I ran into right away with Win64x is that the system takes ownership of some folders. “I” was the one who copied the scripts to a folder in the first place, and then Windows wouldn’t let “me” edit “my” own scripts. That, and Windows seems to be even more active with the security thing (to prevent malware), so there might be some permissions issues with running code all willy-nilly in various folders around the PC.

I’ll make some time to look at it. It’s personal home PC use, so not super critical that I get it up and running immediately. Since this new PC is all still a relatively new install, I may go ahead and look at 5.32 and the State Tool. Thanks.

That’s great! Glad to hear you’ve been with us for so long!

You’re spot on. In general, most issues we encounter on Windows is either related to newer security/antimalware protections or path related issues from library authors whose primary OS is linux. The security issues can be tricky as they don’t always fail in obvious ways. Being that we’ve had 5.26 and 5.28 out for so long I expect that’s the culprit.

5.32 is a good choice because that’s where the lion share of our development effort is going these days so you’ll find us more responsive to issue there. Best of luck and keep me posted on your progress, feedback like yours will help us make it less finicky so always appreciated!

Just for posterity, here is an example of one of the problems I’m having. I reduced the following snipet of code all the way down to a text book example with just 7 lines of code - and it still doesn’t run properly. This short ‘readkey’ has been working on my Win 7 machine for the past 10 years without a problem. When I run the script below (on Win 10 64x now), initially it would not read a key press at all. But now, when I run the script, Windows will fork a Perl process, open the window, but just will sit there blank (instead of ‘print’-ing to the screen the word “Selection”. ‘After’ I press the letter “r” for example, it will at least read the key input now (“r”), and ‘then’ it will print
“SelectionThe key pressed was: r”

I’ve seen that happen before, but never with just a few lines of test code. I don’t remember what caused it before; whether a sub-process was being forked in a situation with an array or something… I don’t remember. (I don’t recall it being a standard I/O thing of some sort though, or a local variable issue.)

I supposed I can go back to ‘standard in’ for now to avoid the readkey issue. Now, onto line by line debug/testing for the array issue. Hey… I tried… to put off switching to Win 10 for as long as possible. Maybe I’ll try my old Win 95 machine.


  • use Term::ReadKey;
  • print “Selection”;
  • ReadMode(‘cbreak’);
  • $selection=ReadKey(0);
  • ReadMode(‘normal’);
  • print “The key pressed was: $selection”;
  • $pause = <>;


on my Win 10 64x ???
ActivePERL has been pretty resilient all these years that I’ve used it, so I figure “what the hay”… I’ll install the last version that worked for me for all of those years. AND IT WORKS!!! Everything in all of my scripts (so far) is working now!!!
(yeah, but, yeah… I’ll be keeping plenty of backups on hand - in case this thing is not designed to run on x64 and yields unexpected results.)

Any input on this one is much appreciated.

John, that issue in your mini test script could be a print buffer problem. Perl may not print anything to screen until it has a full buffer or the script ends. You could try including \n in your prints i.e.
print “Selection\n”
which may flush the buffer or include the line
Before any print statements. Which should turn on autoflush.
I found this issue when Perl updated at one point so the functionality probably changed, can’t remember when though, but was a couple of years ago at least

1 Like

Issues with old versions are most often with the installers not understanding User folder layout changes in newer versions of Windows. x86 on x64 issues can come up when there are two versions of a service, and the 64 bit service is targeted by the x86 code instead of the 32-bit equivalent. The main issue with that Perl would be it’s age, and the age of everything that went into building it.