The incompatibility is only for v2.x of PGP. For v5.x, the GPG (not PGP as you state) needs to have more options.
If the problem with PGP 2.x is truly an issue, then you will probably have to shell out for the PGP command-line version. Note that PGP v5 appears to have been released in 1997 and PGP v2 was in 1992-ish, so unless you are dealing with recipients that do not upgrade, you will probably have good coverage.
Import your key and others:
gpg -v --import c:\pgp\my-pub-and-priv-pgp-key.asc
Import each recipient key
gpg -v --import c:\pgp\pub\recipient1.asc
...
gpg -v --import c:\pgp\pub\recipientN.asc
For some reason the command-line options are really hard to find in the locally installed Windows manual; here they are.
Now use --batch for batch mode, --passphrase-file to have your private key unlocking phrase read from the given file instead of from the keyboard via the gpg-agent*, and always trust the recipient keys. If you don't need to have the output signed, then obviously you won't need to use or unlock your private key.
Encrypt (-e) and sign (-s) a file
gpg -v --always-trust --batch --passphrase-file mypassphrasefile -se -r
recipient1 -r recipient2 ... -r recipientN -o output-file file-to-encrypt
Files should be able to be decrypted and verified with PGP by the recipients.
*I don't think I have to say what kind of potentially bad idea it is to store your private key passphrase in a cleartext file. Note that on Windows, the gpg-agent will read your private key from the keyboard and cache it. The time period it caches it for can be set in the gpg-agent.conf file, though I've not tried this (see here for some potential pointers; the gpg-agent.conf resides in your home dir which is set using the GNUPGHOME env var or by setting the HKCU\Software\GNU\GnuPG:HomeDir string variable).
