I try to write something similar using NSIS.

I've considered that, too, for a more recent project. But that lovely coding experience with elements of PHP and assembly looks more like Brainfuck. In fact, they should have better written "with the worst parts of assembly, PHP and the C preprocessor". Funny for golf and JAPHs, but not maintainable. InnoSetup is much cleaner, using a very nice Pascal implementation for scripting.

How did you cope with errors during the installation of Perl?

"Errors? What errors?" -- Well, I simplified the description of the installing process a litte bit. The installer explicitly warned that you need Administrator privileges. It invoked a batch file checking for an available perl before installing AS Perl. It refused to work with anything else, so we could not get errors due to other perls. The AS Perl setup was quite simple, just unpacking the ZIP was nearly sufficient, setting the few registry values luckily never failed (I think there was something like or die in the code), and after that, we had a known environment. Everything after that, including installing AP packages, could be handled by eval {} and Win32::MsgBox. In the worst case, you had a directory tree full of files that could not be installed properly. Removing that tree was sufficient to start a new, clean installation.

To test the installer, I had a VMWare installation with Win2K in a VM, with a snapshot taken right after having set up Windows, Service Packs, and Databases. I copied the installer candidate into the VM, ran it, damaged a lot of stuff trying to imitate the worst possible user, and finally reverted to the VMWare snapshot. Wash, rinse, repeat until most bugs are gone.

Strawberry Perl, I might consider that approach if my schedule allows for it. It looks promising as far as a brief overview can tell.

It is. Really. Imagine you have a working CPAN right out of the box. And a sane C environment including compiler, linker, and a make variant. You can install any package from CPAN, including those with XS parts, without searching days for a PPM. The only little annoyance is that the standard installer has to install to a fixed path (C:\strawberry). There are variants of the installer for D:\strawberry and for a portable strawberry, but I haven't tested them. The standard was sufficient. :-)

Oracle installing Perl. Cool. Thanks for sharing. :-)

Not cool. At best, it's old and smells a little bit funny. But generally, it disturbs any other perl you want to use. And some parts of Oracle depend on scripts that were once generated by Perl scripts, so Oracles perl becomes part of the dependencies for a surprisingly big part of Oracle, just because you could want to re-generate those scripts. That's why it's very hard to get rid of Oracles perl using Oracles installer.

We usually got away by having a big iron running Oracle and a rather small NT box running our application with just the bare Oracle client installed. And at that time, when Oracle delivered fast native applications instead of tons of Java junk, Perl wasn't bundled with Oracle, or at least not so much packages depended on it that it needed to be installed by default.

Later, our clients demanded a cheeper server, that's when MS SQL Server support was forced into the application (and PostgreSQL was sorted out, because you could not pay for a license ...). But that's a different story, hard to tell without swearing and cursing. But practically, having MS SQL Server on the machine instead of Oracle solved the problem of Oracle's own perl.

Alexander