Microsoft and Perl

What is Microsoft's attitude to Perl?

Recently (at time of writing), Microsoft have decided that they like Perl. This is shown by an article that appeared on one of their sites saying that they thought Perl was a good language with lots of adherents (and fanatics...), and that Microsoft believe that you should be able to use Perl anywhere you can use another scripting language, using Microsoft's Windows Scripting Host. This trumpets the ability to embed Perl fragments in HTML code. This is going to lead to something that won't run anywhere that doesn't support WSH, but there you go.

The article also clearly states that Microsoft have no intention of doing their own version of Perl. Oh good.

Does this mean that IIS5 will support Perl?

I wouldn't like to say, but it might hint at a change in direction. Or it might mean that Perl becomes really easy to use, providing you're using it in a Windows-only manner. If I can take my scripts and run them unchanged, I'll be happy.

As an example of this, my application is tens of thousands of lines of perl. It's run on three operating systems (Solaris, Windows NT, Windows 95), with three databases (Oracle, SQL Server, Access), and five web servers (Apache, Oracle WebServer, IIS3, IIS4, Lotus Domino). The perl scripts don't need to change. That's why I use perl.

What are the alternatives?

I've been looking at Apache on Windows NT, recently. I'm an old Apache fan, having been using on UNIX for a long time. We dug out the Win32 port because we had problems getting PWS to run perl scripts on a Win95 laptop.

Apache ran fine, with the only problem being that in order to invoke a perl script, it uses the bang-hash convention from UNIX: the script must start with

#!c:\perl\bin\perl.exe

or your moral equivalent. After that, it flew.

The current versions of Apache support ISAPI executables, but not ISAPI filters, which means no Active Server Pages. Chili!Soft do ASP support for Apache which appears to be quite good.

If it were up to me, I'd move to Apache today. It's not, so I'm still on IIS4, but I'm intrigued as to what problems IIS5 is going to cause me, since now I have a convincing alternative if IIS5 does cause problems that take too long to fix.

Steve Kilbane. Whitecrow home.