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

Some history (sorry...)

Complete newb Perl user but 40+ years of software development (so I guess that makes me stupid AND dangerous).

I 'inherited' a Perl project (which works) but had to install it on different PC (that didn't have Perl). So I installed Strawberry + Padre combo, and that works very well. I am able to run simple scripts on this system.

(Strawberry perl v5.10.1 (loaded today 9/3/2010)).

But now, when I run the previously working (and very complex) script, I fight it one line at a time.

So I finally got Text::CSV, and a bunch of Win32::GUIs loaded successfully (DropFiles, Constants,BitmapInline) but Win32::GUI::DIBitmap stubbornly refuses to load for some reason I cannot decipher.

I've tried 'force notest' and that gets me further but now the error message is:

dmake: Error code 255, while making 'test_dynamic'
dmake.EXE: Error code 255, while making 'subdirs-test'

I fixed an earlier problem by adding a 'bin' sub to my path but the dmake above is on the path.

One response I googled indicated that the latest version of ActivePerl failed but the previous version worked OK with this, so now I'm wondering (and hoping it's not true) that Strawberryperl is the culprit.

So... any ideas?

Thanks.

Replies are listed 'Best First'.
Re: Win32::GUI::DIBitmap problem
by dasgar (Priest) on Sep 03, 2010 at 21:24 UTC

    I don't have any experience with Strawberry Perl, so I'll shy away from offering suggestions on what may be the source of the problem that you're experiencing.

    However, I do use ActiveState Perl, which comes standard with some Win32 modules. Among the included Win32 modules are Win32::GUI and Win32::GUI::DIBitmap.

    I'm not trying to advocate a move to ActiveState, but just wanted to share some information with you about that distribution.

[reply]
      Interestingly enough, I had just uninstalled Strawberry, and then did reinstall of v5.12 Active Perl, then did Win32::GUI install, and magically everything worked after that.

      Since then, some developers (?) indicated that the current build of Strawberry+Padre may need an update.

      So at least (currently) I have a version that works.

      *sidebar*
      Is it common that 'stuff' breaks when new versions of perl/libs/whatever come out?

[reply]

        It's uncommon that pure-Perl code that does common things within the mainstream of the language on common platforms would break after an upgrade. There are things that can cause some breakage, though. I'll stick to the convention here of "Perl" meaning the language and "perl" meaning the executable to avoid repeating distinctions over and over.

        • Things can seem broken when using modules with some portion of them written in C that are compiled against a version of perl that is not binary compatible. Binary incompatibilities can be caused by differences in the data structures of perl between versions. They can also be caused when different compilers were used to build perl and the module in question. The happens with any compiled language when libraries get out of sync, but people often overlook it for Perl. I think that's since the main application logic is usually fed to perl as source.

          This is fixed by compiling the module against the newer perl or getting a copy that has been.

        • Programs that used barewords that are now reserved by Perl or that are suddenly methods of a class or object that's in use can break things. Following best practices this should definitely be rare, but it could happen in legacy code.

          This is fixed by taking out the offending barewords and making them properly quoted strings, proper function calls, or proper direct object notation, whichever fits.

        • Modules on CPAN may get bugs when they are updated. There's no mandatory formal pre-release test enforced by CPAN itself. The authors and maintainers of the modules typically test before upload, then there are automated testing systems with reports for the code once it's uploaded, and users can make bug reports. This is rare (especially on common platforms), but it does happen.

          I have encountered it when someone did a module upgrade on a production server and my code no longer worked. It was fixed so quickly that by the time I tracked down the problem there was a new version out for me to point out to the server admin, complete with change logs explaining the bug.

        One thing you may want to be careful about on Windows is sharing modules between ActiveState's Perl and Strawberry Perl. Sometimes it works, and you can save disk space by doing it. Sometimes you run across issues and are better off keeping separate module directories for the two installations. It's entirely possible to have AS Perl, Strawberry Perl, and Cygwin (which has its own perl) installed on the same Windows box and not interfering with one another. I've one box here that has two AS Perls, three Strawberry installations of different versions, Cygwin with its perl, and the perl from Microsoft's resource kit, all churning away tests wonderfully. I try to keep all production code on one installation, though, for my own sanity. These issues aren't unique to Windows, actually, but Strawberry Perl and ActiveState Perl are even more different than two perl installations on some other OS are likely to be.

        I do most of my Perl (and most of everything computer-related) on Linux, so there are probably several people here who can give you better Windows-specific advice than I can. I know Perl on Windows is fraught with a few corner cases since it's so unlike other platforms (Perl is originally from the Unix world). In general Windows is a nice enough platform for Perl programming and the tools for Perl on Windows keep improving. I think you're probably running into a more general problem that applies to

[reply]

Back to Seekers of Perl Wisdom