Personally, I think the entire premise of what you are trying to do, and the way you are going about trying to do it is completely wrong.

One of your stated aims is avoiding the installation of perl on every workstation. But, by packaging your apps in this way and running them from a remote share, you are effectively causing Perl to be shipped across the network and installed locally, before the app can start to run. And that process has to be repeated each time each person runs an app. Even when they are re-running the same app a few seconds later.

Also, you complain that one of the packagers doesn't follow use lib ... directives. But lib is a hack. A useful hack intended to bypass silly administrative decisions, but still a hack. If you are responsible for writing and deploying apps company wide, you should certainly have the authorities and permissions to install packages into the production Perl environment. And if all your packages were correctly installed, you wouldn't have to rely upon lib, and the packagers wouldn't be having this problem.

But finally, if you are going to deploy the apps by placing them on a network share, why bother packaging them in the first place. It makes no sense.

If instead, you shared your production Perl installation, with all the packages required by all your apps correctly installed. And place the top-level .pl scripts (or some placeholder .cmd files if some local setup is required), within that installation. Then your users can run those applications from that shared installation. They will load faster because there is no need to transmit, unpack and install everything into the local file system every time.

It makes it easier to test, easier to deploy, easier to control access (via permissions, groups etc.), and you avoid the packaging requirement completely.

I've done this quite effectively. I simply 'shared' the directory where I had Perl installed and wrapped the Perl script as a *.bat file that knew how to launch perl as \\mymachine\perlshare\bin\perl. Then when people (inevitably) copied the *.bat to wherever they put their little utilities, it continued to work.

I even allowed people to avoid relying on my Perl installation if they wanted to. My *.bat wrapper (based on what pl2bat does) would try to run a local "perl" first and only run \\mymachine\perlshare\bin\perl if no local "perl" was found. In a few cases where my script required non-core modules, I even made it smart enough to try to 'require' the needed module(s) and, if that failed, it would just silently exit in a way that would tell the *.bat wrapper to launch via my shared perl.

- tye        

Installing modules is a pain. I vastly prefer Strawberry Perl, and I mostly use that nowadays.

I don't understand that. Unless you tell it otherwise, cpan Module will use dmake and mingw for both. Additionally, ActivePerl provides other options, so it should make things easier, not harder.

It then grinds away for half an hour, using 80% of my CPU the whole time. What the HELL is it doing?

Sounds like you installed Wx::Alien, which builds the wxWidgets library for Wx.

It took me much longer to build, although turning off the realtime antivirus made a huge difference.

The program can't start because wxbase28u_gcc_custom.dll is missing from your computer.

That's the main file of the wxWidget library. (IIRC, it uses one or two others too.) Off the top of my head, it's installed under Alien/Wx in the arch-specific branch of the library directory. Or is it in the share directory?

I don't understand that. Unless you tell it otherwise, cpan Module will use dmake and mingw for both. Additionally, ActivePerl provides other options, so it should make things easier, not harder.

That's how things are with Strawberry—just use CPAN and things Just Work. With ActiveState, unless they've changed things in the past two years, you need to have Visual C and nmake installed (which I don't), or anything XS-based fails miserably. AS does have ppm,but—at least the version I have (5.10)—it's horrible.

Sounds like you installed Wx::Alien, which builds the wxWidgets library for Wx.

Well, yes. It's mandatory for Wx now. Was pp trying to rebuild the entire Wx library from scratch?

It took me much longer to build, although turning off the realtime antivirus made a huge difference.

Now why on earth would that make a difference? That's the kind of thing that would never even occur to me.

Off the top of my head, it's installed under Alien/Wx in the arch-specific branch of the library directory. Or is it in the share directory?

See, isn't that the sort of thing that a packaging utility is supposed to figure out for itself? Cava had no problem figuring that out.

That's how things are with Strawberry—just use CPAN and things Just Work.

Same with ActiveState. Like I above, cpan Module. It'll install dmake and mingw if no compiler is found.

With ActiveState, unless they've changed things in the past two years, you need to have Visual C and nmake installed (which I don't)

You don't need this, but it's a free one-click install if you want to use it.

AS does have ppm,but—at least the version I have (5.10)—it's horrible.

I used ppm with 5.10 for a long time. It's great. I rarely had to leave it. Are you just using the AS repo, or did you check the others?

ith ActiveState, unless they've changed things in the past two years, you need to have Visual C and nmake installed (which I don't),

ActiveState has has dmake/MinGW longer than two years

ppm install dmake MinGW
ppm upgrade dmake MinGW
[download]

As far as installing modules on AS, as long as AS has it (a .ppd), AS installation is very easy. There have been big improvements in their ppm (Perl Package Manager). And no I do not, nor have I ever worked for AS.

Update:
I think the AS cpan shell will actually do all this automatically for you the first time it is run, but mingw is an installable module with AS ppm! I just fired up ppm and installed this for grins - ppm figured that dmake was a dependency of mingw and it installed that too. Anyway this looks way more organized than it used to be. And also be aware that not every .ppd is at active state - the ppm handles multiple repositories.

mingw would be a welcome addition to AS ppm, if it installs as easily as you say. I am running 5.10 of ActiveState's installation, and its ppm is just awful. When you start it, it runs for two or three minutes in a single-threaded state that doesn't even yield to events, meaning that the window doesn't even redraw and can't be moved while it's busy.

I know ppm can handle multiple repositories; often that's the only way to get certain binary modules.

Maybe I should give it another try.

The mingw installation via ppm took about 3 minutes on the machine I'm using at the moment.

A few comments about ppm:
- First, yes it can take awhile for the gui to start and you do get the "hourglass phenomenon". During this time, it is re-syncing with the repositories that you have active. That means (a)if you've recently used it, it is a lot faster because your local info is more up to date, (b) the fewer repositories you have active, the less syncing it will have to do. For default I just leave the main AS one active and if I can't find what I want there, then I add more repositories as the hunt widens..

- If the GUI offends you, then why use it? The command line I/F didn't go away. open an command window and type "ppm help" and you'll see what to do.

Oh, an unrelated but perhaps nice point for you to know...the new version of PDK can do all of the "final polishing" of the .exe (embed your company's icon and put in the build version info, product name, etc) without having to fiddle with running another utility. It will have all the normal windows stuff.

Everyone can now run these perl-scripts, by double-clicking on the perl files.

Of course, start-up time is terrible since everything, including the perl-executable, all modules, dlls, ... must be fetched over a network link (but you save the unpacking and local installing, so there is some speed improvement). However, once started, speed is as usual.

Update: I see that BrowserUK had the same idea (Re: Packaging Perl Programs (is) Painful). Obviously, great minds think alike! ;-)

Are there any sane packagers for Perl?

Use a package system that's suitable for your OS. How do you now distribute something that's not written in Perl? Use whatever you'd be using if you had not know your particular program was written in Perl.

Well, the programs that we develop and use internally that aren't Perl are C or C#, so they are a single executable that we put out onto the network or onto people's computers.

You're using C# without the .NET framework? Are you packaging the entire 20-megabyte .NET 1.0 framework into every executable file (or maybe the 197 MB .NET framework 3.5)?

Has anyone yet mentioned intranet web apps using perl cgi?

thunders made an excellent point that the evolution of perl has not revolved around GUI, whereas MS development has had point-and-click as a priority for a long time.

MS fills the niche of providing OS and apps for those who really don't like computers, and really really don't want to look under the hood to see what's there. One of my own gripes about MS is that this development attitude seems to have spilled over to their developer tools: Visual This, Visual that, left-click a few times and Presto! you have an app. And little idea how it actually works.

However, the reality is that most of our users fall into that MS niche and we have to deal with it. We have to support MS platforms (we have a Windows 7 Migration Kickoff Meeting coming up, groan groan groan) and MS tools are the simplest way to approach that. MS's closed proprietary code enforces it.

I've been using AS 5.10 and their ppm for some time, never had a problem with it. Considering that AS is trying to mate apples with watermelons, I think they do a pretty good job.

I have this dream that all my users are running Linux, but then I also dream about winning the lottery. The reality is that I still have to go to work in the morning and deal with the point-and-click crowd ... I guess that's why they call it work.

"Has anyone yet mentioned intranet web apps using perl cgi?"

See Steffen Müller's Application Deployment and Dependency Management with PAR presentations, the Frankfurt one mentions Application repositories (slide 49) which may be of interest.

Those slides are good, but the gist of it is
• PAR::WebStart
• parrepo/PAR::Repository
• PAR::Repository::Client
• PAR::Repository::Web

I'm using Cava Packer to package up a Perl script as a Windows .exe. The process generates an installer that is about 2.3 MB. The installer seems to work fine and the script runs as expected. True, there is a mess of files buried down in the Program Files folder, but so long as the app runs and the install/uninstall process is clean, so what? Disk space doesn't cost anything these days and a 9 MB footprint is pretty modest compared with many applications.

So you've had your opportunity to vent your frustration with this post. I had mine with another reply. Let's get back to work and analyze how we can improve things for the next guy. I'll just address some parts of your post and refer to the PAR toolkit only:

• The "use lib" bug": You reported it and it's fixed in the Module::ScanDeps trunk. It'll be gone after the next release.

• The slowness of Module::ScanDeps: The bulk of the time taken to package an application with PAR::Packer (== pp) is taken up by Module::ScanDeps. It scans your code for potential dependencies. Then recurses into them and does the same. This results in a lot of IO *and* in a lot of CPU churn. This is partly alleviated for multiple repeated builds by using the caching feature. But not entirely. It turns out that there's an underlying problem. Just recently, Chia-liang Kao reported this to me. I'm paraphrasing:

  The expanded DateTime::Locale modules all use utf8 and create a n-by-m dependency matrix with add_info [a Module::ScanDeps method for adding a dependency link]. They all get pushed into the return value which gets constantly iterated over. The duplicated calls only get skipped in the next level.

  This shows that there's clearly room for improvement. Neither Chia-Liang nor I have had the time to investigate a fix and it's not likely to happen any time soon. Volunteers and discussion on the PAR mailing list would be most welcome!

• Couldn't package Wx application: Others have pointed out that the external wxWidgets libraries need manual treatment. This isn't really a flaw in PAR (or other packagers). The only way to find out about what shared libraries would be needed by an XS module would be to ask the run-time linker. But that would be so utterly platform dependent and probably prone to breakage that nobody has bothered to attempt it. Instead, there are things like Wx::Perl::Packager that have the special cases for common libraries built-in.

• The --gui option hides errors: Well. It is documented as:

  Build an executable that does not have a console window. This option is ignored on non-MSWin32 platforms or when -p is specified.

  I think that this is quite clear about the effect of the option.

• Executable size: Unfortunately, PAR packaged executables tend to be very large. It's because your Perl installation (which is packaged in the exe, mostly gzip'd) is very large, too. Add some shared libs... and you easily arrive at a couple of MB or even over ten. An alternative is something like Cava, which instead creates a "portable" library tree next to the slim executable loader. Choose your poison. There's one avenue to gain a bit in the case of PAR. The components that are required to bootstrap the application at run-time so far can't be compressed. Nowadays, that makes up for quite some overhead. Roderich Schupp and I have been experimenting with statically linking the executables to libz and decompressing the bootstrap-components on the fly. Roderich's code is available as a branch in the PAR repository. I'm sure he'd be open to contributions.

I hope this constitutes a start in the direction of rational discussion (and action) with the goal of making our tools better.

Couldn't package Wx application: Others have pointed out that the external wxWidgets libraries need manual treatment. This isn't really a flaw in PAR (or other packagers). The only way to find out about what shared libraries would be needed by an XS module would be to ask the run-time linker. But that would be so utterly platform dependent and probably prone to breakage that nobody has bothered to attempt it.

It is a pita, but I doubt its too fragile (its how I do it). One way is with ldd, another is with sysinternals listdlls.

Better yet is gcc/mingw objdump , ex

$ objdump -p C:\strawberry\perl\site\lib\auto\Wx\Wx.dll  |grep "DLL Na
+me"
        DLL Name: KERNEL32.dll
        DLL Name: msvcrt.dll
        DLL Name: msvcrt.dll
        DLL Name: perl510.dll
        DLL Name: wxbase28_gcc_custom.dll
        DLL Name: wxmsw28_adv_gcc_custom.dll
        DLL Name: wxmsw28_core_gcc_custom.dll
[download]

or microsofts dumpbin /IMPORTS:msvcrt.dll

or depends.exe /c /f:1 /ot:temp.txt msvcrt.dll

Once you get a list , add each dll with pp -l option

Just lost my reply due to "Preview" ne "Submit". Oops. I'll keep it short:

Doing this kind of thing would be fragile if attempted for the "general case". I.e. all elements of the "platform X compiler tool chain" matrix. In particular, we'd need a blacklist of libraries to never package. Maybe an interactive front-end that prompts the user to select which of the detected dependencies he really wants, etc.

I'd love to have this even just for some platforms, but in a way that doesn't end up with users plastering "PAR is broken on platform X!" all over the internet if this particular bit of functionality is not available for their favourite OS.

Addendum re Module::ScanDeps performance. I just sped up the run time of the Module::ScanDeps tests by a factor of three. In a test with "pp -e 'use Padre'", this moves Module::ScanDeps down from being the slowest part of a "pp" run to making Archive::Zip-related operations the culprit.

This took half an hour. What I'm trying to say is that there are plenty of low-hanging fruit for everyone.

I have found Perl2Exe to be a very sane packager -- but if you're doing GUI, you need the Pro version at $149, instead of the Lite version at $49.

In any regard, the only problems I have ever had with Perl2Exe are these:

1) I had to upgrade Perl2Exe when I upgraded Perl to v5.8.9, meaning another license fee. Since upgrading to v5.8.9 solved a slew of problems I was having with getting modules installed, I considerd the upgrade mandatory. (I held out as long as I could.)

2) I get eggs thrown at me every time I mention Perl2Exe on Perlmonks.

I can live with those two issues. :-)

- Steve M.

P.S. Thanks for the tip about Cava Packager. Though it's apparently less than graceful in its deployment strategy, it sounds functional, and that's the first requirement. "Ugly but functional" is fine with me.

I would also advise looking at the "webapp" route, for the following reasons:

• Everyone already has a web browser - so there's nothing to distribute/install.
• The browser becomes your interface/GUI - everyone is already familiar with this stuff, so there's no need to document/explain basic stuff.
• You only have to install/maintain one version of your app - the one on the web server. If you need to fix a bug, add a new feature, etc. you can do it in one place and all users instantly benefit from the change. Otherwise, you have to worry about pushing out the new version, dealing with users who won't upgrade, etc.
• Documentation can be centralized to the web also - no need to distribute doc files, worry with old versions, etc.

I realize that not every desktop utility can be converted into a web app. Some things are easier to do than others, some are hard, some impossible. But if there's anyway to make it work, it's totally worth it.

I haven't done any development with wxPerl - but I've done lots of work with C++ using the wxWidgets library. The library is very large, and even a small "hello world" program results in a 15MB exe (but the overhead becomes less notable as your app gets larger). There are numerous DLL files that have to be installed along with the app. I've used something called "inno compiler" to bundle everything - but it's still a pain, especially if you have to support Win95, Win98, WinXP, Vista, Win7, etc. Some stuff doesn't work on all systems, some stuff doesn't work the *same* on all systems. It sounds like you're trying to do this PLUS bundle perl into the mix... not fun! Find a way to "webify" and I think you'll be much happier.

The bug tracker awaits you.

But surprise. A more helpful person has already filed the lib issue and it's been fixed in the meantime. (Thanks to Eric and Roderich.)

Clearly, reading up on bug reporting will also be of benefit to you.

A more helpful person has already filed the lib issue and it's been fixed in the meantime.

I would say an equally helpful person. ;-)

(I'm Eric. "Sue D. Nymme" is my main online alias)

Hey! That's great. You really got me there. I'll leave my original post uncorrected to get my deserved embarrassment.

What remains, though, is that I am not entirely happy with the tone of your post. If I didn't know who it's coming from, I'd put it down as whining and unproductive. The situation is not nearly as dire as you make it. Steffen

From the CPAN page it looks to just be a front end to pp.

I haven't been able to get pp to compile, so a front end won't do much for me. But when I do get time to fix pp, I will keep tkpp in mind. Thanks for the tip!

Consider this another vote for the 'make it client/server' argument.

Every workstation, no matter what OS, has a browser, and a browser's really just a general purpose GUI application. Get a server capable of running Apache (or any other web server), build a web application, and use that instead of trying to fight with packaging something to be installed on Windows.

And what if the application requires access to the local file system? Or large volumes of data? Or large amounts of cpu? Or all three?

Why advise a course of action that requires a complete re-write of an already working, existing application, just in order to avoid packaging that application? Especially when there is no need to package it in the first place.

So now I add the libraries to the pp command line:

Next time, you could try just adding the specific modules via the command line, not the whole libraries?

pp -M Math::BigInt::GMP -o test.exe test.pl
[download]

With regard to the Cava Packager section of your post:

You can package any number of executables to use the same modules and libraries. This is part of the build process covered extensively in the help. You are right to say that overwriting one set of files with another will cause the first set to malfunction.

The 'stunning' number of files is probably due to the inclusion of unicode / encoding support. I never really considered the absolute number of files to be an issue. It is a core feature of Cava that files are not compressed and packed at the end of an exec file so you will get a number of files that is roughly equal to the number of files your script may access.

With regard to distribution of Wx based code in general - as already pointed out - why not distribute Perl and use ppm or PAR::Dist to distribute additional code? For cases where you don't wish to do this, for whatever reason - I maintain the Wx::Perl::Packager module and can confirm that complex Wx apps can be wrapped and distributed successfully using

PerlApp
PAR::Packer (using wxpar)
Cava Packager

As noted in a previous reply, the slow running of pp may well be caused by your AV product - I experience this when testing Wx::Perl::Packager against PAR::Packer.

Regards, Mark.

Newsflash

This is going to be a big pain, and will never end.

#1 - When coding for Windows - use .Net - otherwise why are you using Windows?

#2 - The hours/days/weeks you have wasted/will-waste pining away for a workable Perl solution on windows could have been applied to a finished product in C#. Get Over It - your time (and your clients'/boss' time) would be best spent on something that will actually work.

#3 - The free version of Visual Studio will probably do everything you need, for free. You can package up your program as a normal installer (*.msi or *.exe) and it will look just like any other normal Windows program. No more arm-wrestling, no more banging your head against the wall.

WTF?

I know this is PerlMonks, but sheesh - TMTOWTDI, right?

I hate Windows too but it's definitely in every Perl hacker's interest for Perl on Windows to be working and getting better.

I applaud everyone who uses Perl on Windows and encourage them to go for it no matter what the task is. No tools get better on any platform until a dev faces some problem using them and addresses it.

I hate Windows too but it's definitely in every Perl hacker's interest for Perl on Windows to be working and getting better.

I neither have a love nor a hate for Windows. I just never use it. And I would really like to know why it's in my interest (as I'm a member of the set of Perl hackers, and you're making a statement about each and every member of that set) Perl on Windows is working and getting better.

When coding for Windows - use .Net

No!

otherwise why are you using Windows?

Because I prefer windows to the alternatives. (And perl to its alternatives!)

The hours/days/weeks you have wasted/will-waste pining away for a workable Perl solution on windows could have been applied to a finished product in C#

Utter bollocks.

Get Over It

Get over yourself!

Disclaimer - I completely HATE windows, use only Ubuntu for my desktop

So you're another 'me too *nix fanboi' who thinks that the ability to download a tar.gz, unpack it and type configure and make makes him a programmer.

And what about that makes you qualified to answer the OPs question?

So you're another 'me too *nix fanboi' who thinks that the ability to download a tar.gz, unpack it and type configure and make makes him a programmer.

Well it may not make you a programmer, but it sure makes you a better System Administrator. Even at the programming level, compiling your own programs DOES make you a better programmer because building an executable from the code, makes you aware of libraries and how they interact on your system. When you just install pre-built binaries, it's like being thrown a fish, instead of learning how to fish.

---

I'm not really a human, but I play one on earth.
Old Perl Programmer Haiku ................... flash japh

"So you're another 'me too *nix fanboi' who thinks that the ability to download a tar.gz, unpack it and type configure and make makes him a programmer."

I might not have an accredited Pope-ness degree from years of slacking off at PerlMonks (switched usernames a few times over time, hence my mere Sexton status). However, your excellency isn't exactly writing a How-To response either.

If you're going to call me a "fan-boi" then show what you've got. How would you, your supreme-ness, do this using Perl? How would you, your majesty, solve the OP's dilemma?

No answer?

No working solution? No "Hey look at that!" example? Then why even pipe up? Oh, and thanks for the down-vote.

why are you using Windows?

Because that's the system they give me to work on, and because, unlike you, I'm not man enough to bring something else in on my own expense, muscle my way past IT policy and protocols, and use a system that noone else at work can interface with.

The hours/days/weeks you have wasted/will-waste pining away for a workable Perl solution on windows could have been applied to a finished product in C#.

I've spent nearly a decade getting to know the ins and outs of Perl, and because of this I can write the script in a matter of minutes, flush out testing, package, and deploy in under an hour.

While I greatly appreciate your confidence in my skills to learn C# to the same level of competence in merely an hour, I'm not man enough to have that level of confidence in myself.

your time (and your clients'/boss' time) would be best spent on something that will actually work.

What I do works. In under an hour. Including testing. But I suppose I'm not man enough to properly assess what "actually works" and what doesn't.

The free version of Visual Studio will probably do everything you need, for free.

Wow, it compiles my Perl scripts and creates single-step remotely-deployable programs for remote systems that don't have Perl installed? Cool! I'll have to check this out. I hope I'm man enough to find the Perl packager in it. I haven't been doing too well in the manly department, by your standards, though, so I'm not so confident.

I could write the tools in C -- that's what I used to do -- and MinGW does a great job of giving me an easy-to-deploy executable. It's just...well, the development time's a smidge longer. Okay, I admit it -- I'm just not man enough to do it the hard way.

WTF?

Oooh! Oooh! I know the answer to this one! You're man enough to tell everyone else that they must do it your way, and man enough to use TMTOWTDI at the same time.

:: applause ::

Get Over It

I agree that there is one person in this conversation who has demonstrated a need to get over something.

So -- let's face it. You win. You've proven you're better than everyone else here. You can leave, smug in the self-assured knowledge that you are superior, that you have all the right answers, and that you are better than me.

Congratulations.

What I do works

Except it doesn't work, as you found out when you tried to package it. A good programmer considers the whole "development lifecycle", from helping his customer (or employer) to create the spec in the first place, all the way through to deploying it (which you appear to have buggered up) and maintaining it afterwards.

why are you using Windows?

Because that's the system they give me to work on

I'd quit if that ever would happen to me. I've never taken, and will never take, a job that involves "do this task on an OS I tell you to, and you don't know".

It's unlikely to happen in my current gig though. All production machines (1000+) run some form of Unix^† and for dev machines, they just give us the choice of hardware (x86 or apple), and freedom to run whatever we like. (So we have devs running MacOS, Windows, a bunch of Linux distros, a few BSD boxes, and one guy running OpenSolaris).

^†We may have a few non-client facing, non-Unix systems. Like the SAP boxes. But they run bought, commercial software, not something we develop in-house. But they may run Unix as well (or something completely different) - I just do not know.

If the question were, instead...

"How do I make this completely Microsoft-dependent software system work on Linux?"

...my response would have been basically the same, but in reverse - Use Perl. Sure, there's Mono (which does work fairly well) but for something like this - a piece of software with a GUI that must run on users' desktops - you are asking for trouble if you do anything outside of Microsoft's preordained canon.

If you don't believe me - that writing GUI code on Windows is a pain with Perl - ask the nice folks who have been working on "Padre" for the last few years. Combine a simple language (comparatively) like C# and a drop-dead-simple IDE like Visual Studio and, well, basically anyone capable of right-clicking and typing "Hello World" can make a network-deployable windows GUI application. That bar is set pretty high (I know) but I suppose the line has to be drawn somewhere.

"So -- let's face it. You win. You've proven you're better than everyone else here. You can leave, smug in the self-assured knowledge that you are superior, that you have all the right answers, and that you are better than me."

Smug? Maybe popping one's bubble for their own good will be misread as smug. Your skills as a competent Perl programmer put you in a great position to learn C# (enough, anyway) quickly - very quickly. In fact most of the "innovations" I've seen in C# over the last few years have been in Perl since version 5.0 came out or earlier. To me, C# seems to be stuck in catch-up mode, trying to mimic what's going on in Perl and Ruby.

And what's with all this "Oooh I'm not man enough to xyz" - popping this perceived vibe of "Perl is the only tool in my box so it's the only tool I'll use" in the OP - however rough and bruising to your ego it might have been - was probably necessary.

Sheesh.

When coding for Windows - use .Net - otherwise why are you using Windows?

There's some truth to that.

I have been holding out for Perl, because so many data-oriented things are just plain easier in Perl. Connecting to data sources, collating data (push @{ $group{$row->{key}} }, $row; is a beautiful thing), dealing with NULL/undefined values, pattern matching, and so on. Perl makes the easy things easy.

GUIs are more work in Perl than in .NET, sure. But WxPerl is quite good if you can work with the documentation (which is slowly getting better).

But when it comes to getting Windows system information, networking to Windows services, and packaging final products for delivery, .NET wins hands down. Perl is stuck in Unixland, with assumptions about where libraries are going to exist and what sorts of things users are expected to have installed.

I would far and away rather be developing on Ubuntu or some other *nix variant than on Windows. I had hoped that Perl would make Windows programming less painful. And in part, it does! But only so long as you have a full Perl distribution installed and don't have to mess too much with C compilers. (Ever try getting Curses.pm to work on Windows?)

I've been resisting giving in to the Dark Side and going over to C#.NET, but maybe it's time.

Resist the urge. It's still a Dark Side after all. There's no coming back and sooner or later you're going to find yourself on the wrong side of a Death Star explosion.

giving in to the Dark Side and going over to C#.NET

It is possible to make a Perl module available to the .NET framework so that any language in .NET can use it. It is also possible to use a .NET object from a Perl script.

This sounds as bizarre as mating a giraffe with a turtle, but evidently ActiveState has figured out how to do it. This link ActiveState PerlNET Overview shows an example of shows an example of a Perl module (WWW::Babelfish) being called from within a .NET C# program.

Anyway, it would seem that it would be possible to say build a GUI within .NET and use Perl for say the DB code or use some other kind of functionality provided by an existing CPAN module.

I have never personally used PerlNET. But if some mixed Perl and .NET implementation were desired, then PerlNET seems like something to consider. Of course this isn't freeware and you would have to have an AS PDK license.

I don't know why this is getting downvotes, for some problems this is certainly true.

Perl is simply not optimized for GUI programming, and the tools for creating standalone executable perl packages, especially ones that can deployed remotely, are simply not on the same level as ones for some of the other technologies mentioned.

I think this is because most perl programmers don't do a lot of work in this area. Perl is indispensable for systems or web programming, but there are just much better solutions out there for Win32 GUI apps. I would applaud the original poster if they set about attempting to correct this imbalance, but I wouldn't blame them if they tried an easier route.

I am primarily a perl programmer working on web applications. Perl/Catalyst/Moose is the best of the options I've tried for that type of development. But it's not the only programming language out there.

C#/Visual Studio is a viable option for this kind of project. If you really don't like Microsoft products, there are many other options like Qt/C++, or Eclipse/Java that are well suited for this sort of problem(both are multiplatform to boot).

Perl has some advantages(CPAN, powerful regular expressions, flexible syntax) and it may provide nicer glue for all the technologies you need for your application, but often installing CPAN modules on windows is an exercise in frustration. And I think you'll find that Java, C# and other languages have ways to glue things together.

I like perl, I know it well, and I like to solve problems with it. However, that doesn't mean it's the optimal tool for every job.

You know Qt, Wx, Gtk, Gtk+, Tk, Fltk, SDL, and Prima work with Windows and Perl, right? Win32::GUI is meant specifically for native graphical Windows programs.

If you're a Perl web developer you've learned more ways to do that than Catalyst and Moose or you haven't been doing it very long. New ways to address problems come along all the time. There are plenty of ways to address graphical applications on Windows using Perl, and many of them keep getting better over time.

Perl isn't indispensable for web programming or systems programming. Plenty of people use PHP, Python, Ruby, Java, JavaScript (yes, even on the server side), or other languages for web work, and some of them never use Perl. The only systems language I know about that could really be called indispensable is C, or maybe Forth on really small systems. I don't even know that Perl should be classified as a systems language. It is general-purpose, but I think its strength falls more in applications. People program in Perl because it fits their needs well enough and they prefer it to some other language that would also meet their needs well enough.

For someone to just flat out say that some other language's benefits and drawbacks will always win out against Perl on a particular platform takes some qualification at least.

There's no way C# can be said to have a smaller framework footprint than Perl, with 3.5 being nearly 200 MB. Not all versions of Windows come with that, you know. Perl's footprint is 74 MB for 5.12.2-RC1 on my Linux box, admittedly without Wx or any of the other graphical toolkits. I think a few might fit in the other 123 MB. Many of the core Perl modules don't have to be left in place if they are sure never to be used on a particular system, but care really needs to be taken with that idea.

C or C++ development typically takes much longer than Perl or Python development for the same complex task. You can statically link libraries in most cases, but that doesn't make for small executables in most cases. Those programs are counting on some framework being in place if they are doing something fancy without linking a lot of static libraries into themselves. If that framework isn't the stock libraries in a particular version of Windows, then the framework footprint and the issue of separate file installation still apply.

If you're going to recommend someone move to C++ from Perl to solve a problem on Windows, you might as well have them solve whatever problem you're having with one of the graphical toolkits for Perl on Windows. That will be much more useful in the long run than writing a one-off application in C++ instead of Perl.

I don't know why this is getting downvotes, for some problems this is certainly true.

At a guess, probably because of the condescending one-true-way attitude and the fact that he didn't address the OP's actual question.

I chuckled when I found it was sitting at -7. I figured it would take a hit or two but I didn't realize the number of people who would even bother to vote on it would actually outnumber the number of people who agreed with the technical merits of the post.

I am not disappointed, mind you. Just surprised. Apparently, people on Perlmonks want this to be a place for friendly and useful dialog.

Go figure.

I like perl, I know it well, and I like to solve problems with it. However, that doesn't mean it's the optimal tool for every job.

++thunders

Have a great evening!

For what ever reason, the OP wrote his stuff in Perl. Good for him. Maybe it was the right tool when he started and maybe it's the wrong tool for what he's trying to do now. Maybe he should have just started in .net, or C# or any number of more Windows friendly choices from the get go. I hear even PHP is getting strong support in Windows these days. Regardless that was OP's choice at the time.

The question was not 'should I use .net instead' the question is 'how do I make Perl work in this situation'. We should support that effort, expand the boundaries, look for solutions and encourage the use and knowledge of Perl that it may help others in similar situations. Not troll some hyper marked up 'you idiot' message proclaiming the futility of using non Windows applications in a Windows world.

On a nix system we wouldn't be arguing about how installing CPAN modules is an exercise in frustration (OK we might, but we'd probably be arguing about the different ways it could be done). If installing CPAN modules on windows is ever going to become easier it will only be because brave mis-guided souls dared to buck against flippant advice and find ways to make it work anyway.

Anything else is just walking into a weight watchers meeting and calling everyone fat because they eat too much.

I work for the ligiation field, which is dominated by Windows environments as that is what most laywers are using as are their clients. All of the tools we use are also written and and for Windows. We use windows, because it is whatever one is else is using and we cannot force the rest of our industry to change OS because it would make our lives simplier.

I've been mulling over a similiar problem, and after reading these posts think I'll go with the browser solution, since most of our applications are written that way as well, so my users will be able to stay in app they spend most of the time in anyways.

Yes Windows sucks, but I work at a company where all of its' clients, and their clients use Windows so what would be my incentive to even attempt to get IT to give me a *NIX box? I don't see much benefit there, if I have to interface with Windows all the time anyways. All the data I use would be NTFS, so seems kinda pointless to bang my head against the wall instead of just using Windows.

Not trying to cause any waves here, but thought I'd mention there are legitimate reasons for working in Windows. I'm pretty sure most ppl wouldn't quit a good paying job working perl in windows just because it was windows and not *nix. Would you?