In short, unless you test it yourself, there is not much telling of whether any given module will work as expected under Win32 or not.

As a rule of thumb, if a module has a Pure Perl implementation, it will most likely work, if it makes no stupid assumptions about the file system and does not rely itself on platform specific modules or relies on sufficiently many and diverse platform specific modules, one for each platform.

Modules are distributed for Win32 in the normal CPAN fashion, but it is common for binary modules to be distributed prepackaged in ppm files plus archives, because relatively few installations of Win32 have a C compiler available.

cygwin is no cure here, as the cygwin Perl only works well with the other cygwin programs, and the predominant method of getting Perl for Win32 is to compile a native Perl for Win32 instead some crutch that ports over the GNU utilities and a badly done vestige of Unix.

Most of the problems of installation can be solved by installing the proper make program, for most cases, this is nmake.exe, from Microsoft.

If you plan to distribute to users on Win32, plan to have at least one machine in your test setup to be Win32 as well.

Your specific choice of modules seems a bit narrow-minded to me, as Term::Readline is a module which uses whatever readline functionality is available on the system, whereas Term::Readline::Gnu requires the GNU Readline library to be installed. In most cases, going with the less specific alternative or providing an adequate fallback if a module is not available will be a good way to get your program to run on a platform.

PodMaster has been, for a long time, providing Win32 ports, and I am quite sure he will share his knowledge of porting libraries and producing PPM files with you if you ask him.

I've never had any luck getting the CPAN module itself to work on Win32 or under Cygwin, but you might take a look at Module::MakeDist. It is designed to make distributions for multiple platforms. If it works, you can create a repository for PPD packages and script an installation for your users. I used to know more about this, but it's been a while. You might poke around something like this. Basically a PPD package is a standardized way of telling Perl Package Manager (PPM) how to install a module. After your create a PPD you tell PPM about your repository (once), then have it search for and install the module. You can run it interactively or from a command-line for easy scripting. For example, to add your repository of PPD files, run

  ppm repository add "Spiffy Perl Pkgs" http://spiffy.com/win32/pkgs
[download]

  ppm install foo
  ppm install bar  etc.
[download]

Basic Term::Readline with the default stub works fine in the Win32 shell window for me. Make sure extensions, history, and command-line completion are turned on. Vanilla Win32 systems may not have this, so consider running this registry script, or something like it (you can break it out as several scripts if you like):

  Windows Registry Editor Version 5.00

  [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Command Processor]
  "CompletionChar"=dword:00000009
  "EnableExtensions"=dword:00000001
  "PathCompletionChar"=dword:00000009
[download]

History is enabled through DOSKEY, which is a basic macro program. Consult the help (doskey /?) for more info. The easiest way to auto-enable it is to put the line "doskey" in c:\autoexec.bat. It will be run when a shell window is opened.

Cheers!
Marmot

Update: A quick look see at CPAN of the source of the two modules appears that to these highly untrained eyes to be pure Perl modules. so just nmake should be all that is necessary to build them

I found it necessary to mention, that cygwin DID do the job great. Everything works like a charm. It even works so good, that I wouldn't talk of a port.

True, one had to install about 300MB of software under cygwin (gcc, perl, base system, make, ...) and then some

perl -MCPAN -e shell

but from the scripts side, the system is nearly undistinguishable from linux (except $^O :-)).