Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl Monk, Perl Meditation
 
PerlMonks  

Perl and Windows 7

by CountZero (Bishop)
on Aug 01, 2012 at 16:21 UTC ( #984829=perlquestion: print w/ replies, xml ) Need Help??
CountZero has asked for the wisdom of the Perl Monks concerning the following question:

Greetings Sisters and Brothers in Perl!

Our company is planning to move to the Windows 7 platform by the end of the year or early next year. Our IT department (of which I am not a member) is testing all present applications for compatibility.

As I use Perl and Perl is not an "approved" technology any testing comes down to me.

Unfortunately I do not have a Windows 7 testbed computer (and I cannot really ask for one given that Perl is sailing under the radar here), I turn to the Monastery to listen if anyone of you have installed Strawberry Perl on a Windows 7 PC and whether they encountered any specific difficulties. Not only the basic install, but also the installation of non-core modules. Most specifically I am thinking of modules such as Moose, DBI, DBD::mysql, DBD::SQLite, DBIx::Class, Catalyst, Dancer and such.

As IT promised that the Windows 7 install would be rigidly controlled (it is rumored we will not even be able to change the placement of the icons on our desktop), I will have to get formal approval for the Perl installation on my PC and I am not likely to get it unless I can tell IT that Perl will work on Windows 7. A classical "chicken or the egg" situation: I cannot test it since it is unapproved and it cannot get approved until I test it.

So it is with great expectations I look at your experiences with Perl on Windows 7.

CountZero

A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity." - The Tao of Programming, 4.1 - Geoffrey James

My blog: Imperial Deltronics

Comment on Perl and Windows 7
Re: Perl and Windows 7
by Anonymous Monk on Aug 01, 2012 at 17:16 UTC
    I have experience w/ both cygwin and AS perl implementations. The transition to Win 7 went without a hitch for all my programs.

    Where I've experienced the greatest friction has been with the ability of some modules to work in 64bit versions of perl on any version of Windows.

    My verdict? Have no fear of Win7 and perl, but unless you're juggling large ammounts of data in memory, you may wish to stick w/ the 32 bit versions.

    TJD

      To clarify: I use 32 bit perl implementations on 64 bit Win 7.

      TJD

Re: Perl and Windows 7
by VinsWorldcom (Priest) on Aug 01, 2012 at 17:29 UTC

    I've been using Perl (both Activestate and now Strawberry only) on Windows 7 x64 for 2+ years. I started with Activestate and then moved to Strawberry 5.10.1. I'm now at 5.12.3 but have also tested 5.14.x.

    I use some non-core modules and all installed without issues. I used the patches to get Net::Pcap to compile and work and even got Tk to compile with a little Google search (one line fix in a header file). I've only used the DBI modules for testing connectivity to an MS Access database and that didn't work for me when I moved from Windows XP 32-bit w/ Strawberry to Windows 7 64-bit w/ Strawberry. I suspect it has to do with the ODBC 32-bit/64-bit EXE and since it was only a test for me, I didn't pursue it.

    I also do some IPv6 work and found that although core module Socket should have IPv6 support as of 5.14 - it doesn't on Windows, even though Windows will support the get*info() functions as evidence C programs which I wrote to test and they compiled fine with the gcc provided with Strawberry (and a header file tweak). I needed to install Socket::GetAddrInfo to get IPv6 working.

Re: Perl and Windows 7
by sundialsvc4 (Monsignor) on Aug 01, 2012 at 17:33 UTC

    I have recently been involved in a similar assessment for a client – not specifically concerning just Perl but a number of different internal applications.   A capsule summary of our findings would be this:

    (1)   The Win32 API upon which all software of course depends remains largely unchanged.   Therefore, applications and DLLs by and large continue to execute as expected.   A smörgåsbord of non-API libraries have experienced the usual set of changes, which will or will not affect you according to exactly how your particular applications are link-edited.   In the case of Perl, for example, some CPAN libraries that are “wrappers” for other libraries may require rebuilding, and the CPANTS test-outcomes tables should be consulted well in advance.

    -----

    (2)   The most significant change of Win7 is, of course, the security-infrastructure management, which has continued to become more visible and intrusive.   Digitally-signed installers ... and therefore, the use of installers at the exclusion of every other installation option ... now receive an almost fanatical degree of attention.   I expect that Strawberry Perl will by its nature have difficulty with this, and that Active State Perl will continue to become more expensive.   ... :-) ...   And actually, that wasn’t an attempt at humor.

    Windows 7 reflects the realization that most “rogue” software that seriously causes harm arrives on a computer by being installed there.   Applications are intentionally being made very difficult to install by any means other than the use of an installer, and installers are made virtually impossible to use at all unless they are digitally signed.   While this makes perfect sense for an application, and is already in common use e.g. on smart phones and tablets, it does present problems for a complex language-system such as Perl, as it also does for many in-house applications not related to Perl.   Windows (finally) pays very close attention to where a DLL or an executable may be located.   It has the power to restrict overrides to the library search-path.   It can require signed-code anywhere.

    In summary, I think that a proper answer to your question will be more complex than simply determining whether or not the Strawberry Perl core runs on Windows-7.   (It does.)   What will be of concern is whether the entire set of CPAN libraries that your systems directly or indirectly use can, on a case-wise basis, successfully build and install themselves on all of your company’s Windows-7 targets.   To that end, you need to find a way to work closely with the IT teams now, presenting the Perl-based target applications (not “Perl itself”) as the systems that your business must legitimately be able to run.   You will get buy-in by pointing out, not only that Perl is not the exception nor exceptional, but that it is the means to an end.

    -----

    (3)   More-or-less as a footnote ... the 32/64-bit issue applies in the usual way.   A representative target build-system must be set aside, and Strawberry (with all of your CPAN requirements) must be built upon it to assure compatibility.   Once a stable code-base of the entire application is assured, a conventional installer can be used for simplified deployment, and if this be so, a Windows-7 aware version of the installer de jour should be used.   In other words, you might wish to build Strawberry, and do all of the installations of CPAN material, then “snapshot” the whole thing for deployment purposes using a different installer ... one which is purposed to install the application(s) on a target computer.   Your company may well wish to apply their own digital signature to that installer.   The same procedure may be advisable in the case of their existing “purely home-grown” internal applications, as well.

        :-)   I think you have no fear about that, at least insofar as installed applications are concerned.   Every corporation in the world has “its own” applications, and therefore has the need to be able to install them on “its own” computers.   But we do (finally!) live in a less-trusting world, in which “any ol’ application installer” that happens to show up on your doorstep will no longer be given the Administrator/Root password as a matter of course, and succeed quite unhindered in its possibly nefarious business.

        Even though a few of the articles that you mentioned do seek to raise an alarm, the simple truth in the corporate environment is that corporations are full of home-grown applications that need to be installed upon other machines within their workplace.   What the companies in question need, even though they may not have formally recognized this need before now, is the ability to ensure that the “home-grown application” really did come from them!   Both Windows and OS/X, entirely of necessity, do provide the means for corporations to issue their own digital signing certificates that will be accepted within the corporation’s own designated trust chains (and of course, nowhere else).

        (Let us meanwhile sincerely hope that the days are long-gone when any ol’ web site can download an “extension” and have it be installed automagically ...)

        Your company IT department now has the ability to ensure that the only apps that can be installed upon “their” computers, are “theirs.”   (They can even exclude public applications, if they so choose.)   Therefore, if your application needs to be widely distributed within the company, you might have to construct a custom installer for it.   If, on the other hand, the application needs only to continue to run on the one machine where it is now situated, that is a much simpler requirement.

Re: Perl and Windows 7
by jandrew (Hermit) on Aug 01, 2012 at 17:37 UTC

    I just recently switched from Win XP 32 bit Activestate perl 5.10 to Win 7 64 bit Strawberry perl 5.14.

    I made the switch from Activestate to Strawberry perl because of the reduction in up version ppm support for perl modules. By that I mean that the basic cpan or cpanp install can work across multiple perl versions for many modules but Activestates ppm support which is tied to the perl version will often be months later than the module release. The major downside here has been mixing it up with any XS modules. This has mostly been an issue when the module looks for make or nmake rather than the Strawberry perl dmake. The upside is now my install reports go to the CPAN testers (mostly).

    Ultimatly the largest barriers have been Tk and DBI-> Access. Tk doesn't ship with the base Strawberry install and won't pass all tests. (I solved this with a forced install). My DBI connection to some prototyping Access databases that I use still isn't up yet. I suspect that the root cause here is on the windows side not the DBI side since Access requires that you set up an ODBC handle. I have a 32 bit version of Access ($work won't pony up for 64 bit Office yet even though moving forward 64 bit systems are default) on a 64 bit system and that seems to be the disconnect. I so far have resisted downgrading Strawberry perl to 32 bit with the thought that it might finally be time to move all my database work to PostgreSQL.

Re: Perl and Windows 7
by dasgar (Deacon) on Aug 01, 2012 at 17:41 UTC

    So far, I haven't had any issues with using 32-bit Strawberry Perl on 64-bit Windows 7. Of course, I'm probably a "light" Perl user compared to you based on the modules that you listed.

    Also, you might want to check out DWIM Perl from Gabor Szabo. He's basically taking Strawberry Perl and adding in more modules that he felt would be useful to have. In fact, some of the modules that you specifically named are included. It also includes Padre.

Re: Perl and Windows 7
by davido (Archbishop) on Aug 01, 2012 at 17:59 UTC

    I think all the anecdotal evidence that Perl works just fine on Windows 7 is failing to really answer the question until someone takes the time to comment on the specific stack / toolchain the OP mentioned:

    • Moose: Seems to have a clean tester's matrix for Win.
    • DBD::mysql: This is problematic, as it requires that the target system install MySQL Server first. Many GNU/Linux dists come with MySQL preinstalled, but Windows doesn't. Consequently, the tester's matrix looks terrible for DBD::mysql, when it's really not as bad as it sounds. I haven't specifically tested on Win7, but have on Vista with no problem.
    • DBD::SQLite: No problem on any version of Windows I've used, and it has a pretty clean tester's matrix too.
    • DBIx::Class: I've installed it on Windows Vista.
    • Catalyst: I don't think I've installed Catalyst on a Windows system, but I don't recall for sure.
    • Dancer: Should be no problem. The tester's matrix is clean. I've never installed it on Windows.
    • ...and such...: I've installed Mojolicious on just about everything, including Win7. If you have other specific concerns please mention them.
    • Perl itself: I've installed Strawberry (32 and 64) on Win7, as well as ActiveState Perl. I usually use Strawberry on Win (out of habit), but I understand that ActiveState has gotten a lot better with respect to providing the tools necessary to use the standard cpan utilities. My original reason for shifting to Strawberry Perl several years back is probably mostly moot if this is the case.

    If you don't get anyone with specific experience installing Catalyst and DBD::mysql on Win7, send me a reminder /msg, and I'll reboot one of my systems to Win7 and do some test installs for you. It's obviously easier for me if someone else has already worked with those modules on Win7, but if not, after I get your /msg I'll go ahead and put them through their paces after which I'll follow-up here.


    Dave

      Following-up to my previous post...

      I booted to Windows 7 Home Premium. 64-bit Strawberry Perl v5.14. It's a pretty clean slate because I mostly use it with VisualStudio 2010. The rest of the time the system lives booted to Ubuntu Linux, so Windows stays pretty much pristine. I had already installed Strawberry Perl in the past, but practically no non-core modules.

      • cpan App::cpanminus: No problem. All the rest were installed with cpanm.
      • DBD::mysql: Had to install MySQL server first. Then it installed without a hitch.
      • DBD::sqlite: No problem.
      • DBIx::Class: No problem.
      • Dancer and Mojolicious: No problem.
      • Catalyst: No problem.
      • Moose: Pulled in by Catalyst... no problem.
      • DBI, DBIx::Connector: No problem.

      By "No problem", I mean they passed their test suites and installed cleanly with cpanminus. Those modules' test suites are probably extensive enough to give you confidence that you'll be able to actually use the modules as they're intended to be used.

      I think that covers your list. Let me know if there are others that you are concerned about. Most of this is also covered by the CPAN testers reports, but DBD::mysql and Catalyst seem to not be adequately represented on the Windows platforms by those reports.


      Dave

Re: Perl and Windows 7
by rpnoble419 (Pilgrim) on Aug 01, 2012 at 19:50 UTC
    I made the Win7 switch two years ago as well. I run DBI->MySQL and DBI->SQLite in both ActiveState and Strawberry. I'm running 5.10.1 on both versions, as this is what my hosting company supports. I have had no issues with installer alerts from either product (I get more alerts from my firewall software). I do run the 32-bit version of Strawberry on my Dedicated server (win server 2008 x64) as I could not get all of the modules to install under the x64 Strawberry. I have seen no lag time in the Perl processes I run because of this. My Win32::GUI applications run without any issues. I have not tried TK.
Re: Perl and Windows 7
by ww (Bishop) on Aug 01, 2012 at 21:23 UTC

    Concluding that davido's observation about useful replies is a useful model:

    • Win7 ("Pro")
    • AS, initially, 5.10, currently 5.14
    • DBI, DBD::mysql, DBD::SQLite
          ... about which you asked and which I use, posed no problems.

    Install/execute restrictions can be a PITA; my favored editor was not certified by M$, early on, so had to tolerate a "You really, really want to run that?" dialogue, but while annoying, unless you're billing hours in milliseconds, or have a 'very, very short fuze,' it's probably not an intolerable problem -- if, indeed, you hit any such aps.

      Thank you! Your answer gives me hope that I do not have to go without my favourite tools in Windows 7.

      CountZero

      A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity." - The Tao of Programming, 4.1 - Geoffrey James

      My blog: Imperial Deltronics
Re: Perl and Windows 7
by lancer (Beadle) on Aug 02, 2012 at 12:23 UTC
    As IT promised that the Windows 7 install would be rigidly controlled (it is rumored we will not even be able to change the placement of the icons on our desktop), I will have to get formal approval for the Perl installation on my PC and I am not likely to get it unless I can tell IT that Perl will work on Windows 7.

    That doesn't sound like a highly productive environment. Maybe it's time to leave.
      That doesn't sound like a highly productive environment. Maybe it's time to leave.

      As someone who works in such a rigidly controlled environment — and is, like all my coworkers, plenty productive — I can tell you what a load of horse manure that is.

      I am not part of the IT department and not even supposed to write any programs at all. All the colleagues are just computer consumers and not required to know anything about computers except the MS Office stack and the corporate tools.

      Being a lawyer by training and profession I have nevertheless always tinkered with programming for over 35 years now and whenever I do a repetitive task twice I write a program to do it the third time.

      From the company's point of view a restricted environment is most easy to control and much cheaper to deploy and maintain. The vast majority of the colleagues will have no problems with it.

      If I can give Perl a clean Bill of Health on W7, I will find a way to convince them to include it on my PC or --that would be heaven-- on a company wide basis on all PCs. We are allowed to dream aren't we?

      CountZero

      A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity." - The Tao of Programming, 4.1 - Geoffrey James

      My blog: Imperial Deltronics
Re: Perl and Windows 7
by cavac (Chaplain) on Aug 02, 2012 at 16:49 UTC

    I use AS perl for developing in-house software. I do most of software development on XP, but some on Win7. Rollout from XP to 7 is usually not a problem.

    Performance is reasonably good. So far, the only major thing that can be a pain in the seating device is working with the registry on 64 bit systems. You really have to always keep in mind if your program is 64 or 23 bit (they don't share registry that well).

    If your programs need administrative rights, you may have to adapt your software, because just running under an administrative account may not be enough. You may start your journey here. Or, if you can, just disable that UAC thingie. Most malware bypasses this without problem anyway.

    "I know what i'm doing! Look, what could possibly go wrong? All i have to pull this lever like so, and then press this button here like ArghhhhhaaAaAAAaaagraaaAAaa!!!"

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://984829]
Front-paged by Corion
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others examining the Monastery: (3)
As of 2014-07-23 03:46 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite superfluous repetitious redundant duplicative phrase is:









    Results (132 votes), past polls