http://www.perlmonks.org?node_id=984508

KevinZwack has asked for the wisdom of the Perl Monks concerning the following question:

Dear Monks,

A little background: In my last job, I developed engineering tools for my colleagues, mostly in Perl (for over ten years, started with Perl 3). Everyone had a SunOS and later Solaris workstation; we had an NFS drive called /tools, and /tools/bin was automatically added to everyone's PATH when they logged in. Life was good, myself and others could add tools, upgrade Perl versions, install or upgrade CPAN modules, etc. pretty transparently to the others users (provided that all tools were tested and any needed changes were made first).

Now I have a similar job at a different company where everyone has a Windows PC, and life is hell. We have some tools written and Perl, and myself and others are advocates of Perl. However, here are some examples of the problems we are running into:

  1. About half the PCs are XP/x86, and the other half are Windows 7/x64. Some CPAN modules work on x86 but not x64 (e.g., Win32::SerialPort).
  2. Most people have CYGWIN installed, as we make extensive use of xterm windows, plus there are a lot of Bash scripts (although once people learn Perl, they much prefer it). People also have Strawberry Perl installed, and having both on the same machine creates a lot of confusion.
  3. We do not have a central repository for executing tools (let alone SCM, but that's other topic). We have various automated test runners, but file paths like \\server\foo\bar don't work. For some reason, they need paths like X:\bar to operate correctly. So various tools are mapped to various drive letters, but obviously this isn't a scalable solution, and not all drive letters are available on all PCs.
  4. When we hire new employees, they generally get a new PC, and are told to install this and/or that Perl and a long list of CPAN modules which may or may not build correctly in their environment.
  5. Our IT department is more hostile then helpful, so we cannot expect them to "push" anything out to PCs, or common login scripts, etc.
  6. They tried deploying a virtual machine image with all the tools in place, but everyone hated that. Plus it made upgrades difficult.

Needless to say, we spend an inordinate amount of time trouble-shooting what I would call "infrastructure" problems, rather than working on the engineering problems at hand. I have pretty much been given carte blanche by management to come up with how our tools infrastructure should be implemented, provided the infrastructure problems are resolved once and for all. So my question is this: what are other people doing that works well to deploy Perl applications in a Windows environment?

I would like to standardize on a single Perl, but which one? (Cygwin, Strawberry, ActiveState?) The existing tools generally require Perl 5.12 or newer. I would like to feel confident that everyone is using the correct version of a tool by putting them in some common network drive location... I could probably get T: reserved for this purpose, provided we give up some of the other drive letters we are using... None of us are strong PC admins, we all have Unix backgrounds. We are stuck with using Windows since many of the products we make run on Windows. Any thoughts?

Update 8/1/2012

I have installed the 32-bit Strawberry Portable ZIP version on a network share. I have successfully installed all the CPAN modules we use and performed some basic tests on XP x86/Win7 x64. So far, everything seems to be working fine. I think if I provide our users with .bashrc files that set their environment variables appropriately, hopefully things will work from their xterm sessions. Thanks again for all the great suggestions.

Replies are listed 'Best First'.
Re: Perl on Windows Best Practices?
by BrowserUk (Patriarch) on Jul 30, 2012 at 21:14 UTC
    About half the PCs are XP/x86, and the other half are Windows 7/x64

    Put a 32-bit perl on a network share. Give anyone wanting perl access to that share and set their assoc .pl to point to that shared perl. 32-bit Perls run perfectly on 64-bit Windows.

    If there are some scripts that need/benefit from using a 64-bit perl, install a 64-bit perl on teh same share (different) path and set up associations for that using a different file extension (say .p64).

    • When a user runs a script that needs 64-bit, they'll type theScript ...;
    • that will resolve (via PATHEXT=.p64;.COM;.EXE;.BAT;.CMD;) to a file called theScript.p64;

      If it becomes necessary to have both 32-bit & 64-bit versions of a given script; then the 32-bit is call theScript.pl and because the machines with 32-bit OSs have their pathext set as PATHEXT=.pl;.COM;.EXE;.BAT;.CMD;; when they type theScript ..., it gets resolved to the 32-bit version.

    • the association for that will be assoc .p64=Perl64
    • the ftype for that will be ftype Perl64="P:\\perl64\bin\perl.exe" "%1" %*;

    A similar set of associations for files named .pl run the 32-bit perl.

    You have 2 centrally maintained, universally accessible builds of perl that everyone can use.

    Getting them to use them is then a matter of political will and company process.


    With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.

    The start of some sanity?

Re: Perl on Windows Best Practices?
by roboticus (Chancellor) on Jul 30, 2012 at 20:53 UTC

    KevinZwack:

    Try using forward slashes instead of doubled backslashes for UNC names. That works just fine with cygwin--at least *here* it does:

    #!/usr/bin/perl use 5.14.0; use warnings; use autodie; open my $FH, '>', '//npckfs01/users/301058/ZOOG'; print $FH "The quick red fox, etc. etc. etc.\n"; close $FH;

    ...roboticus

    When your only tool is a hammer, all problems look like your thumb.

Re: Perl on Windows Best Practices?
by bulk88 (Priest) on Jul 31, 2012 at 01:04 UTC
    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.
      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.


      With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.

      The start of some sanity?

        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.
Re: Perl on Windows Best Practices?
by kevbot (Vicar) on Jul 31, 2012 at 03:40 UTC

    I have been using the 'PortableZIP editon' of Strawberry Perl to share scripts at work. I use it over the network. So, I uncompressed the Strawberry zip file into a directory on a network share. Now, users can run portableshell.bat from the top-level directory.

    This way, one can install cpan modules or your own modules once and everyone will have access to them. The only problem I seem to have with this approach is the occasional cpan module that runs fine on unix but is broken on windows. I tend to develop on a unix machine so I just need to be careful when I start using a new dependency. It's a bit frustrating to introduce a dependency just to find out that it doesn't work on Strawberry.

Re: Perl on Windows Best Practices?
by 2teez (Vicar) on Jul 30, 2012 at 23:38 UTC

    I would like to standardize on a single Perl, but which one? (Cygwin, Strawberry, ActiveState?)

    • I presently use both ActiveState Perl and Strawberry on Win7 OS. I preferred Starwberry Perl, for the way it install cpan modules 'out of the box' with little or no effort. However, using ActiveState is also cool but sometimes installing cpan modules could be a nightmare, only that I know how to wake when having bad dreams :)!
    • Plus the fact that Strawberry Perl is A 100% Open Source Perl for Windows that is exactly the same as Perl everywhere else, while ActiveState Perl have binary distributions of Perl for Win32 which is also free.
    • Check this: http://www.perl.org/get.html for more details.
Re: Perl on Windows Best Practices?
by dasgar (Priest) on Jul 31, 2012 at 04:01 UTC

    Others have covered most of the information that I could share on the topic of your post.

    About half the PCs are XP/x86, and the other half are Windows 7/x64. Some CPAN modules work on x86 but not x64 (e.g., Win32::SerialPort).

    It's been my experience so far that the Win32 modules that I've used on 64-bit Windows work just fine. I guess that could change with future Windows operating systems.

    Also, since I personally don't have any scripts needing features like 64-bit integers from 64-bit Perl, I've been using 32-bit Perl on 64-bit Windows without any issues so far.

Re: Perl on Windows Best Practices?
by sam_bakki (Pilgrim) on Jul 31, 2012 at 12:18 UTC

    Hi

    I also faced similar issues in Windows perl distribution. I have solved by using

    1. Install & use ActiveState Perl - Windows x86 version - All the modules builds properly & Work properly in x86 (including Win32::Serialport) in my laptop (Which is Windows 7 , X64 but I have x86 version of gcc to compile CPAN modules which are not available in PPM)

    2. Purchased ActiveState PDK - There is utility called perlApp, which will convert your .pl to .exe (and includes all dependencies like .ico, .pm , .dll etc etc..) , Which works perfectly with Active perl.

    3. Create x86 .exe version of tools and distribute. (It will work on x86 & x64)

    4. Note: Yes, I know, creating .exe will increase size. But there is a option to create a dependent exe which uses installed perl without bundling perl in .exe. But I am fine with the size (usually ~3 MB).

    Thanks & Regards,
    Bakkiaraj M
    My Perl Gtk2 technology demo project - http://code.google.com/p/saaral-soft-search-spider/ , contributions are welcome.

Re: Perl on Windows Best Practices?
by blue_cowdawg (Monsignor) on Jul 30, 2012 at 20:34 UTC

    Personally I'm partial to ActiveState Perl on WinBloze. Having said that I also make use of the Perl that comes with Cygwin. Both are 5.14.2


    Peter L. Berghold -- Unix Professional
    Peter -at- Berghold -dot- Net; AOL IM redcowdawg Yahoo IM: blue_cowdawg
Re: Perl on Windows Best Practices?
by gam3 (Curate) on Aug 01, 2012 at 14:55 UTC
    Sorry to go off topic, but I love the title of the post. Sounds kind of like: Running with scissors; best practices.
    -- gam3
    A picture is worth a thousand words, but takes 200K.
      Thanks, that made me laugh.
Re: Perl on Windows Best Practices?
by KevinZwack (Chaplain) on Jul 31, 2012 at 15:27 UTC
    Thank you all, there are many good suggestions here. I will try these and see if we can get a smoother running Perl infrastructure.
Re: Perl on Windows Best Practices?
by mr.nick (Chaplain) on Jul 31, 2012 at 17:41 UTC
    mostly in Perl (for over ten years, started with Perl 3)

    Eh? Perl 3 came out in 1988 or 1989 and lasted only two years or so until the Camel book came out. Ten years ago would be around be 5.8 or so.

    Don't mean anything by that, but "ten years ago" and "perl 3" really don't belong in the same sentence. Hell, "twenty years ago" and "perl 3" don't belong together.

    mr.nick ...

Re: Perl on Windows Best Practices?
by linuxkid (Sexton) on Jul 31, 2012 at 20:01 UTC

    I use strawberry when i use windoze, and to install modules, you can do a use CPAN; install Some::Module; with an install Some::Module for each module you need.

    --linuxkid


    imrunningoutofideas.co.cc