Note that the designated save to path always looks like lib/foo/bar or something similar. The starting location of lib/ could be any place that Perl might search when looking to load a module. Thus, in theory, you could type the following into a CLI (aka command line instruction) window...

perl -e "use Foo;"

...which would fail with a complaint telling you all the places Perl looked for the non-existent module Foo and locate your modules starting in any one of those instead of starting in lib/. In fact, one of the listed directories will be the acutal lib/ which we seek. Alternately you could just browse the varied Perl directories in search of one named similar to either of the following...

C:/Perl/site/lib ...such as for ActivePerl on Win32 or...
/usr/pkg/lib/perl5/site_perl/5.8.0/lib ...such as for Perl 5.8.X on NetBSD UNIX or...

...whatever similar path your own Perl installation uses for modules downloaded from CPAN. You must also, of course, name each file as recommended at the download link when saving them. And, of course, if a module path is described as lib/foo/bar.pm yet directory foo does not already exist in lib/ then you will have to create that directory.

Since this is not CPAN, module dependencies do not auto-install themselves. Any module having another module as a dependency will be so noted in the module's own POD (acronym forPlain Old Documentation) which you may view from this site as HTML. And, of course, you could find that out almost as easily by looking for a statement like use Foo::Bar.pm or similar near to the top within the Perl code itself.

The vast majority of all such dependencies will be either Perl core modules (pre-installed when you built Perl) or CPAN modules installable in the regular way. The very few others, if any, will all be available here. A single, partial exception exists. This has to do with one module's CPAN version not being the latest. That single case, although minor, is noted as a "Caveat:" at the top of its explanitory section on this page.

I design for and test on both NetBSD (a UNIX) and WinXP. Thus, accordingly, all but one of these modules work cross-platform. The single exception is due to its own CPAN dependency, Device::LabJack, not being available (yet) for NetBSD. Reportedly, though, they do have it for LINUX. And its author has offered to make it available for Mac OS X. But I have no means for testing those.

Version numbering is for tracking purposes only. It is not a judgement upon the worthiness of said software. Commercial vendors regularly employ it thus...it in the sense of a pre/post beta-release numbering sequence. But after then commercial version 2.0 only means they were short on revenue and need an excuse to pick your pocket once again. I observe that many a writer of open source software ignores that framework. Those who don't, like the early releases of LINUX sometimes end up with a zillion sub-relases between 0.9 and 1.0 for no better reason than an excess of optimism in guessing the illusive 1.0 benchmark. Meanwhile they will have hopped and skipped forward such that from 0.04 to 0.20 there may have been no releases at all in between. This is irrational. I elect to follow rather more sane examples.

So you should not hold your breath in hopes of a release labled $VERSION = 1.00;. With luck it will never happen because that would be a very bad thing. I choose to follow the more rational example of a wholly sane numbering scheme, one which mandates that the first, plural-copy distribution (hopefully already fit for public use) will be issued as 0.01 on account of said software having existed as but a single copy. I will have kept it under wraps until completely satisfied. Only thereafter does there arise any motive to duplicate it for distribution. And only then, with multiple copies strewn about does it become problematic to know which is which. Prior till then it needed no version number at all. But from that point forward version numbering becomes crucial.

Accordingly, none of my efforts will enter into public awareness as versions higher than 0.01 except for in a very few cases where I may have circulated them privately for some reason or other. Up until then I will not have allowed for multiple copies (other than backup) to exist. Only then will it have become needful to track them. And only after then, should I find occasion to make improvements will they obtain higher version numbers. No matter how vastly improved, the next circulation will be innumerated 0.02 and so forth. Such a new release as 0.02 might include whole new additional features but none of the prior ones will be thereby broken.

Never until such time as I make nasty and dramatic changes which break the original API (requiring users to change the way in which they employ said module) will it be re-released as version 1.00. Withdrawl of a previously existing feature would constitute such an API fracture. Big, ugly things like that... Minor changes after then will be numbered 1.01 and so forth. Not until I cruelly abuse my users again will the release number rise to 2.00.