Re: Perl on Windows Best Practices?

[bulk88]

I personally use ActivePerl or self compiled VC Perl (same thing). As other said in the thread, more XS things compile on 32 bits than on 64 bits. Windows is kindda a deprecated platform for Perl. In the late 1990s and early 2000s, Microsoft (through AS) and ActiveState/Hip poured a ton of resources into creating Win32 Perl. All that went dead when .NET came out (AS Perl.NET was the last Perl thing MS ever funded I think), or when MS realized that Perl can't be compiled to .NET CLR bytecode and "embrace extend extinguish" wouldn't work with the Perl crowd.

Cygwin Perl I don't recommend, it seems to get less attention than Mingw and VC Perl from p5p. Between Mingw (GCC) and VC I'm not sure. VC is C89 and MS has repeatedly said since 2008 on their forums/bug trackers that they will not be added any C99 or C11, or any features at all, to VC plain C compiler (C++ is a different story with MS). Many non-Perl POSIX-ish FOSS projects (which can wind up as XS modules in Perl) have formally abandoned compatibility with VC and say "we only support and use GCC C [time for MS to grow up/peer pressure on MS to adopt C99/C11]". But with VC Perl, I think its easier to debug the Windows vs Perl interaction because of the VC debugging symbols MS offers. But because Mingw Perl is a much newer product in the history of Perl, and includes its own reverse engineered equivalent of Platform SDK, some things that compile for modern VC Perl won't compile for Mingw Perl. Not all VC C code (lvalue casts for example) is valid GCC C code. Mingw Perl's FOSS Platform SDK is often older than the latest MS Platform SDK, so things that want to use Vista/NT6/Win 7 APIs might not compile with Mingw yet (plus AS's PPM build farm uses circa 2002 headers). Then again, you said you want XP compatibility, so Platform SDK age is irrelevant for you.

I believe that Win32 Perl, can use a registry entry in addition to environment variables to determine @INC. Having 1 /site/lib and one /lib on a network share for everyone might be something you want to do. Beware of network latency though, My Network Places paths/mapped paths might cause unacceptably slow Perl interp startups. Then again you said that your IT department refuses to help. Have you considered portable perl installed on a USB stick and give one to each employee? Updating will be a chore. Considered writing a perl script that will update every PC's C: Drive Perl dir once a month over the network?

You don't want Perl Module hell (AKA DLL hell) between your different PCs.

[BrowserUk]

Beware of network latency though,

Hm. Given modern network speeds, it would have to be a script with a huge number of dependencies for even a 10Mb/s network to require much more than a second or two to load. And does anyone run at less that 100Mb/s these days? Mostly, company LANs are substantially faster.

It would only be a problem if someone was trying to run high-frequency, short lived scripts -- say web-server CGIs -- across the network, but even then, filesystem caching would step in a remove the problem.

[bulk88]

SMB/My Network Places/CIFS handshaking/latency is slower than any HD IMHO or even HTTP. Look at it in wireshark one day, many handshake back and forth set up stuff, lots of metadata queries on the files, attribute reading and setting, file pointer setting, etc. Dozens or hundreds of sub 100KB files gets slow and will not saturate a network connection mbps wise in my experience between Windows computers. Of course copying files with Explorer and Perl interp starting up and loading PMs are both synchronous I/O. I tried copying my perl dir from 1 XP machine to a Server 2003 machine with Explorer, no HD light flashing on the source machine (the whole perl dir was in read cache from a recent grep of the dir), probably none on the Server 2003 machine (8 GB of RAM, 7 GB probably free), the average was 1-2 mbps up (to dest) and 500 kbps down (from dest) when copying .pl and .pm files, and jumped to 70 mbps and 500 kbps down (from dest) when copying .pdb files. I have a 100mbps ethernet network. I dont think file caching works over SMB connections, atleast with NT 5, since multiple clients or the server itself can read write the file at any time and SMB has no way of pushing cache invalidation messages across the wire or doesn't use them in most cases.

It seems things improved with NT 6, http://en.wikipedia.org/wiki/Server_Message_Block#SMB2. I have no NT 6 machines.

[BrowserUk]

I dont think file caching works over SMB connections,

Hm. l: is my net use for live.sysinternals.com\tools via my (currently) 700kbs broadband and wifi:

C:\test>net use l:
Local name        l:
Remote name       \\live.sysinternals.com\tools
Resource type     Disk
The command completed successfully.

The first time I download procexp.exe it takes 34 seconds for the 2.5 MB file:

C:\test> prompt [$t] $p$g

[ 4:41:09.11] C:\test>copy l:\procexp.exe .
        1 file(s) copied.

[ 4:41:43.33] C:\test>dir procexp.exe
11/07/2012  17:38         2,691,192 procexp.exe
               1 File(s)      2,691,192 bytes
               0 Dir(s)  101,746,388,992 bytes free

After that it is almost instantaneous. This is done by hitting cursor up and enter as fast as I can:

[ 4:56:14.29] C:\test>del procexp.exe && copy l:\procexp.exe .
        1 file(s) copied.

[ 4:56:14.34] C:\test>del procexp.exe && copy l:\procexp.exe .
        1 file(s) copied.

[ 4:56:14.38] C:\test>del procexp.exe && copy l:\procexp.exe .
        1 file(s) copied.

[ 4:56:14.42] C:\test>del procexp.exe && copy l:\procexp.exe .
        1 file(s) copied.

[ 4:56:14.47] C:\test>del procexp.exe && copy l:\procexp.exe .
        1 file(s) copied.

Between .04 and .05 of a second. That can only come from local caching.