@Perl on 64bit W7

May 30, 2008
65
1
#1
@perl doesn't seem to work on 64bit W7. I use TC 12.00.32.

It seems ActiveState doesn't install perlscript on 64bit windows.
when trying to run using %@perl it says:
"Error (SYS): Invalid class string"

I use ActiveState Perl 5.10.1.1007

From the installer it seems the same is true for 5.12 (I didn't install it though).

Is this a known issue, and is there a workaround?
 

rconn

Administrator
Staff member
May 14, 2008
10,643
97
#2
@perl doesn't seem to work on 64bit W7. I use TC 12.00.32.

It seems ActiveState doesn't install perlscript on 64bit windows.
when trying to run using %@perl it says:
"Error (SYS): Invalid class string"

I use ActiveState Perl 5.10.1.1007

From the installer it seems the same is true for 5.12 (I didn't install it though).

Is this a known issue, and is there a workaround?
You'll have to ask ActiveState about that. They've been (very) late with x64 Windows support for their scripting languages in the past -- Tcl/tk still doesn't have it.

If they still don't support it (which is pretty inexcusable, as it only requires a recompile), the workarounds are to either use the 32-bit TCMD, or compile your own x64 PerlScript.
 
May 30, 2008
65
1
#3
You'll have to ask ActiveState about that. They've been (very) late with x64 Windows support for their scripting languages in the past -- Tcl/tk still doesn't have it.

If they still don't support it (which is pretty inexcusable, as it only requires a recompile), the workarounds are to either use the 32-bit TCMD, or compile your own x64 PerlScript.
That's actually not really a solution..

I've tried to install AS 32bit (which doesn't seem to install perlscript anyway on 64bit).

Recompiling is another issue.. first the source is needed from AS, then a proper 64bit compiler..
oh, and there might be an issue or two with the code..it usually is.

I don't know any other versions of perlscript than AS's, and if there was, it probably wouldn't have the same guids, so it wouldn't work with TC anyway.

The lack of perlscript was one of my biggest hurdles when transitioning to 64bit as I used it rather extensively, but installing W7x86 (which seems to be the only proper solution) etc just to be able to use it is rather...eh..problematic.

The conclusion probably would be, no actual support for perl under 64bit as perlscript doesn't seem to exist for that platform.

I seem to remember that TC11x64 did support it though (I uninstalled it when installing 12)?
 

rconn

Administrator
Staff member
May 14, 2008
10,643
97
#4
That's actually not really a solution..

I've tried to install AS 32bit (which doesn't seem to install perlscript anyway on 64bit).

Recompiling is another issue.. first the source is needed from AS, then a proper 64bit compiler..
oh, and there might be an issue or two with the code..it usually is.

I don't know any other versions of perlscript than AS's, and if there was, it probably wouldn't have the same guids, so it wouldn't work with TC anyway.

The lack of perlscript was one of my biggest hurdles when transitioning to 64bit as I used it rather extensively, but installing W7x86 (which seems to be the only proper solution) etc just to be able to use it is rather...eh..problematic.

The conclusion probably would be, no actual support for perl under 64bit as perlscript doesn't seem to exist for that platform.

I seem to remember that TC11x64 did support it though (I uninstalled it when installing 12)?
I just tried it here and the 32-bit Perl installation does work fine with PerlScript and Take Command 32-bit on Windows 7 x64.

There are several issues here -- first, the lack of PerlScript support in AS Perl x64 would only affect you if your Perl scripts depend on running internally in TCMD (and sharing TCMD variables and commands). If you're running a Perl script externally (i.e., the same way as you would with CMD) then there's no need for PerlScript support, so you can run the scripts from TCC x64 (using Perl.exe). Just uncheck the internal Perl scripting option in TCC (OPTION / Startup / Scripting / Perl).

If you *do* need the internal TCC PerlScript support, you can install TCC x32 and and run them there.

Take Command v11 (actually TCC v11) did not support PerlScript. It supported Embedded Perl, which I dropped from v12 because it was terminally buggy in Windows. (God help you if you hit Ctrl-Break while running a Perl script, as Perl's Windows exception handling was fubar.)

Have you asked ActiveState about PerlScript x64 support?
 
May 30, 2008
65
1
#5
I just tried it here and the 32-bit Perl installation does work fine with PerlScript and Take Command 32-bit on Windows 7 x64.

....snip

If you *do* need the internal TCC PerlScript support, you can install TCC x32 and and run them there.

Take Command v11 (actually TCC v11) did not support PerlScript. It supported Embedded Perl, which I dropped from v12 because it was terminally buggy in Windows. (God help you if you hit Ctrl-Break while running a Perl script, as Perl's Windows exception handling was fubar.)

Have you asked ActiveState about PerlScript x64 support?
I'll guess I have to retry.. at least the msi installer didn't seem to install it, even if everything was checked.

I think PerlScript/Embedded would be almost the same from the script's view.

I haven't asked AS lately as I'm using the community version..
I did ask a year or so ago though, with no real result (when I initially experienced this with another product using scriptengines)..

I guess I'll have to rewrite a couple of scripts then.
I haven't used it too extensively, so it probably wouldn't take too long.

I appreciate the answer though.
 
May 30, 2008
65
1
#7
Hi,
I found this workaround :
desactivate perl script in "option"
and
set .pl=C:\perl64\bin\perl.exe
Best regards
Just so you know.. thats not really a workaround.

However, after I posted this thread I removed the need for @perl statement at all by
recoding those batchfiles (including whatever the @perl was doing) into real applications (which works on both w32/64).
 
#8
Arriving very late to this particular party...

I have run across this same problem on a system with a 64-bit o.s. installed. That is, the error ""Error (SYS): Invalid class string" whenever I attempt to launch a Perl script by simply invoking its name. E.g.:

c:\scripts> filename.pl

However, for whatever the reason, the following works -- at least on that machine:

c:scripts> perl.exe filename.pl

I don't know if it will work in all circumstances. The odd thing is, this was not a problem in the past on this same machine. The drive crashed, our hardware guys installed a new drive and reinstalled the o.s. -- same o.s. version, as far as I know -- and then the problem began.

c:\scripts> eset .pl
.pl=c:\Perl\bin\perl.exe

c:\scripts> which perl.exe
perl.exe is an external : C:\perl\bin\perl.exe

I no grok...