* On the main (C:) OS drive, create the directory \usr\bin
* In that directory, create a Junction aka Symbolic Link named perl,
  pointing to C:/strawberry/perl/bin/perl.exe

Related links:
Unix Shebang on Windows
perl under Win apache

I often forget what I have to change in transfering such code from one site to another so I have an "export" script which takes in templated code and substitutes the variables with site-specific values based on a config. It saves me time and mistakes and satisfies my natural aversion to masochism.

In your case, for example, one could use Template::Toolkit. The templated cgi input file (ABC.in) would be like:

#![% SHEBANG ]
# eventually file ABC.cgi
use [% LOCATION_OF_VARIABLES_CGI_FILE ];
...
[download]

And this script (verbatim copy from the doc) does the substitutions:

# WARNING: simplistic work flow for demo purposes

# create Template object
my $template = Template->new({
  INCLUDE_PATH => '/search/path',
  # ...
});
 
# define template variables for replacement
my $vars_for_windows = {
    # whatever a windows path looks like
    SHEBANG => '#!\...\straw...\perl.exe',
    LOCATION_OF_VARIABLES_CGI_FILE => 'c:\abc\xyz\variables.cgi',
};
my $vars_for_linux = {
    SHEBANG => '#!/usr/bin/perl',
    LOCATION_OF_VARIABLES_CGI_FILE => '/usr/xyy/abc/variables.cgi',
};
 
# specify input filename, or file handle, text reference, etc.
my $input = 'ABC.in';
if( $target_is_windows ){
  # process input template, substituting variables, final output filen
+ame
  $template->process($input, $vars_for_windows, 'ABC.cgi')
    || die $template->error();
} else {
  $template->process($input, $vars_for_linux, 'ABC.cgi')
    || die $template->error();
}
print "$0: do you want me to ftp it to remote site?...\n"
[download]

bw, bliako

It appears as though you're trying to work on a copy of a production website on your localhost using a different Operating System platform. Is that correct?

If so, I would highly recommend you spin up a virtual machine within Windows, and install the exact same OS with the same version that's in production, and get everything set up as close to the same as possible. Then, do your development on there.

To develop on one platform then attempt to implement on another one in a production migration without a staging setup is asking for severe headaches.

If your goal is cross-platform support, that's one thing, but you still should have a production replica environment to ensure everything works on the platform you're dumping into in your prod environment.

...and please, when starting new threads, use a more logical question title that reflects the problem you're facing or the question you want answered. The title used here doesn't give readers any context whatsoever.

++ however all of this advice has been given several times now, over the last dew days :/

Sorry for my ignorance. Thanks very much for the suggestions. I'll try to get this resolved before I ask the next question.

there are many pages and I don't want to have to change them all.

Why not? Now you know Perl, making the same change to many files is a simple matter, no?

I have had to change the hash-bang line to #!C:/strawberry/perl/bin/perl.exe from #!/usr/bin/perl. ... I don't want to have to change them all.

This is one of the things I meant when I wrote this about using a virtual machine instead of Windows.

The shebang issue has a workaround, as explained in this StackOverflow answer: In the Apache config, use ScriptInterpreterSource Registry-Strict, and in the Windows Registry, set HKEY_CLASSES_ROOT\.cgi\Shell\ExecCGI\Command to the path of perl.exe.