Perl of Wisdom（reship）
Andrew Clinick
Microsoft Corporation
January 22, 1999
Contents
What Is Perl?
Developing a script platform for Windows is an interesting challenge; we have definite ideas of where we want to take the Microsoft script languages, Visual Basic® Scripting Edition (VBScript) and JScript®, we introduce new technologies, such as Windows Script Host (WSH) and scriptlets—yet the script world still appears to be dominated by Perl and its loyal army of developers. I thought I'd start the new year off with an article covering Perl, what Microsoft thinks about it, and how you might use it in your next Web project.
What Is Perl?
Perl actually stands for Practical Extraction and Report Language and was invented by Larry Wall to help him develop solutions on UNIX that C and Shell scripts just didn't address. You could say that he invented "scripting" as we know it today. I'm convinced that I'll get a ton of mail about that (from avid Rexx and TCL programmers, no doubt), but I think Larry deserves a lot of the credit for developing scripting into the vibrant community it is today. It's difficult to describe Perl; it's similar in syntax to C—but is much easier to learn and develop, because it was designed to give you as many shortcuts as possible. Ask Perl developers to do something, and they invariably reply, "No problem. I could do that in two lines of Perl," closely followed by a colleague claiming it could be done in one line! That's not to say that you can't develop large programs in Perl. It's just that a lot of Perl scripts are very small because the language gives you those shortcuts.
Sometimes, those shortcuts can be a little counterproductive, though. Perl is famous for its ability to create programs that are entirely illegible to everyone but the developer who wrote them. The Perl community even has obfuscation contests to see who can write the most unintelligible Perl code!
I won't attempt to point out all the features of Perl, but instead leave it to Larry Wall—after all, he knows it a lot better than me! There's a great interview with Larry on the virtues of Perl, and I recommend you read it for more info on what Perl is and what was going through Larry's mind when he started it up.
What Does Microsoft Think of Perl?
I can't talk for all of Microsoft, but certainly the script technologies group and a bunch of people in the Windows and BackOffice group think it's a fine language and certainly deserves a place in Windows Scripting. I've mentioned in earlier articles that language choice is a religious issue, and Perl is a great example of this. If you're an ardent Perl programmer, the chances of me (or anyone, for that matter) convincing you to use VBScript or JScript is pretty slim.
Perl does have some very powerful features—both in the language and from the myriads of modules that are available (modules are extensions to the core Perl language). One of Perl's key features as a language is regular expressions; in fact, Perl has probably done more to evolve regular expressions than any other language. If you are not familiar with regular expressions, think of them as the ultimate string manipulation tool for serious string processing. Regular expressions are to strings what math is to numbers. In addition to the language features, modules are a great asset to Perl; there is probably a module out there that will do what you need. For example, there are modules to talk to sockets, HTTP, and SMTP e-mail—making Perl a very useful language for Web server development.
We also recognize that a lot of people moving from UNIX to Windows have considerable investment in Perl—both code and expertise. As a result, it's very important that we have a great Perl implementation on Windows, and that you can use Perl everywhere you can use a Microsoft scripting language. This eases some of the pain of migration to Windows, since you can at least keep using a language that is familiar to you.
Where Can I Use Perl?
Pretty much anywhere is the simple answer. Windows has a technology called ActiveX Scripting that allows any script language to be plugged into any application that supports ActiveX Scripting. This was introduced way back with Internet Explorer 3.0 and is now a core feature of Windows.
As you can see from the above diagram, this means you can use Perl in Internet Explorer, Internet Information Server (IIS), WSH, and any application that supports the ActiveX Scripting Interfaces. All you need to do is set the language to be PerlScript, and you are done. The Windows version of Perl also supports the more traditional .pl extension for batch files and CGI scripts, if that's what you are used to. I'm going to concentrate on using Perl in applications via the ActiveX Scripting Interfaces, because CGI and batch file usage is covered pretty well by the Perl community.
Where Can I Get Perl for Windows?
The most common question I get about Perl is "when is Microsoft going to do a Perl?" Since it's an open source project and there is such a thriving community, Microsoft won't be doing a Microsoft Perl, but will work with the major implementers to ensure that the Windows implementation is as good—if not better—than the other variants out there. We feel this is the best way to ensure that Perl performs well on Windows, and so far it has worked out great, with good quality Perl implementations that take advantage of Windows in a way that makes sense to Perl developers.
Because Perl is an open source project, a number of different variants are available on Windows—but the top two are ActiveState ActivePerl and MKS PScript I will cover using these.
Internet Explorer
Specifying the script language in HTML is achieved by using the language or type attributes on the script element. Most Web pages use this to specify JScript or VBScript, but if you have ActivePerl or PScript installed on your machine you can change this to be PerlScript (ActivePerl) or PScript and Internet Explorer will load up the appropriate Perl engine and pass the Perl code into it to run.
Before you rush off to write the next killer Web app in Perl, you should be aware of some of the pitfalls of using Perl in HTML. The major one is that Perl is not installed by default by Internet Explorer or Windows, so the code you have in your HTML probably won't work on the majority of your users' machines. This obviously limits how useful Perl is in HTML if you are planning to use it for wide-scale distribution, and I would warn against using it for this reason. Despite this, it can provide an effective way for you to develop admin applications in HTML—assuming that the number of people who will use it will be relatively small, and they will have Perl installed on their machine
The following examples use PerlScript, but they could easily be PScript by changing the language attribute to be PScript.
<html>
<body>
<script language="PerlScript">
$window->document->write("Hello world!");
</script>
</body>
</html>
This example, the classic Hello World, shows that Perl deals with object model quite differently than VBScript or JScript. It uses -> rather than periods to delimit objects, methods, properties, and the top-level object is identified by $.
Because Perl is no different from VBScript or JScript in the way it is integrated into Internet Explorer, you can mix languages on one page. For example:
<html>
<body>
<script language="PerlScript">
sub foo {
# Write out the first argument passed to the document
$window->document->write($_[0]);
}
</script>
<script language="VBScript">
y=foo("Hello from VBScript")
</script>
</body>
</html>
You can also hook up Perl code to events on the Web page in exactly the same way as VBScript using the familiar object_eventname notation. For example:
<html>
<body>
<input type=button value="Click Me" id=btnClick></input>
<script language="PerlScript">
sub btnClick_onclick {
# Display an alert to the user
$window->alert("You just clicked me!")
}
</script>
</body>
</html>
These examples are pretty simple, but I hope they give you an inkling of how you could use Perl in your Web pages and shows the flexibility ActiveX Scripting brings to Internet Explorer.
Internet Information Server
Perl is probably most used to provide Web server functionality—and as such is a key feature that IIS must support in order to be an effective. IIS supports Perl in a number of ways:
- As a script language in Active Server Pages (ASP) files
- As plain old CGI
- As ISAPI applications if you use PerlISAPI from ActiveState
I won't cover CGI or ISAPI in this article but you can get more info from the Windows NT Server site and ActiveState. If you install the latest version of ActivePerl, it should do all the registry/mime-type setting for you.
Using Perl in ASP is very similar to using VBScript or JScript; you just need to create an ASP file and add a script block with a language attribute of PerlScript. Alternatively, you can use the @language directive and set the language for the page, so you can use Perl in <% %> blocks.
Using the <SCRIPT> element
<html>
<BODY>
<script language="PerlScript" runat="Server">
$response->write("Hello from Perl in ASP");
</script>
</BODY>
</HTML>
Using the <%@ LANGUAGE %> directive
<%@ LANGUAGE = PerlScript %>
<html>
<BODY>
<%
$response->write("Hello from Perl in ASP");
%>
</BODY>
</HTML>
Creating a useful ASP program almost always involves talking to an external object—for example, perhaps Active Data Objects (ADO) talk to a SQL Server database. Like VBScript, Perl can either use ASP technology's server.createobject, <object runat=Server> tag or the CreateObject function supplied in the COM module that comes with ActivePerl. (Perl knows nothing about COM inherently, so you need to include the COM module to access COM objects outside of the application that is hosting Perl).
I don't recommend that you use the Perl CreateObject function from within an ASP file, because the object will not be run in a Microsoft Transaction Server (MTS) transaction, and therefore can't get to the ASP intrinsic objects and doesn't retrieve user authentication details. The Windows Script Host uses the Perl CreateObject function—but for ASP scripting, stick with server.createobject. Even better, use the <OBJECT> tag, which can be significantly quicker than server.createobject.
Here are some examples:
Calling ADO with server.createobject
<%@ LANGUAGE = PerlScript%>
<html>
<head>
<!--
Copyright (c) 1996, Microsoft Corporation. All rights reserved.
Developed by ActiveState Internet Corp., http://www.ActiveState.com
-->
<title>Active X Database Object</title>
</head>
<BODY BGCOLOR=#FFFFFF>
<HR>
<H3>ActiveX Data Object (ADO)</H3>
<!--
<%
$ErrorNum = $!;
$ErrorStr = 'Err:'.$!;
if ($Conn eq undef) {
$val = 'undef';
} else {
$val = $Conn;
}
%>
$Conn = <%= $val %> <br>
$ErrorNum = <%= $ErrorNum %> <br>
$ErrorStr = <%= $ErrorStr %> <br>
-->
<%
$Conn = $Server->CreateObject("ADODB.Connection");
$Conn->Open( "ADOSamples" );
$RS = $Conn->Execute( "SELECT * FROM Orders" );%>
<P>
<TABLE BORDER=1>
<TR>
<%
$count = $RS->Fields->Count;
for ( $i = 0; $i < $count; $i++ ) {
%><TD><B><%= $RS->Fields($i)->Name %></B></TD><%
}; %> </TR> <%
while ( ! $RS->EOF ) {
%> <TR> <%
for ( $i = 0; $i < $count; $i++ ) {
%><TD VALIGN=TOP>
<%= $RS->Fields($i)->value %></TD><%
};
%> </TR> <%
$RS->MoveNext;
};
$RS->Close;
$Conn->Close;
%>
</TABLE>
</BODY>
</HTML>
Calling AD rotator using the <OBJECT> tag
<%@ LANGUAGE = PerlScript%>
<HTML>
<HEAD>
<!--
Copyright (c) 1996, Microsoft Corporation. All rights reserved.
Developed by ActiveState Internet Corp., http://www.ActiveState.com
!-->
<TITLE> Create a MSWC.AdRotator server Component</TITLE>
</HEAD>
<BODY BGCOLOR=#FFFFFF>
<!--
ActiveState PerlScript sample
PerlScript: The coolest way to program custom web solutions.
-->
<H2> Create a MSWC.AdRotator server Component
that can be used to automate rotation of advertisements
on a Web page. </H2>
<OBJECT ID="Ad" runat="Server" progid=" MSWC.Adrotator"></OBJECT>
<%= $Ad->GetAdvertisement("/AdvWorks/adrot.txt") %>
</BODY>
<HTML>
Just as in HTML, you reference the ASP objects using the object->method notation rather than object.method notation.
Windows Script Host
Windows Script Host was designed to allow VBScript and JScript developers to build batch files on Windows and UNIX in much the same way that Perl developers have using .pl files. So why should you use Perl in WSH when you can just use a plain old .pl file? The answer depends on what you are trying to achieve. If you just want to use Perl and its host of modules, staying with a .pl file will probably suffice. However, if you want to take advantage of the COM objects, which now ship with Windows, and the new Windows Management Interface, which ships with Windows 2000, then you will want to use WSH. Why? WSH helps you work with COM objects more than a straight .pl file does— and the improvements coming along in WSH 2.0 will take this even further (more on that in my next article).
Should I use Perl instead of VBScript?
If you've gotten this far through my column, you're probably thinking that Perl is a great language and perhaps you should consider using it for your next project. Should you consider moving away from VBScript—since Microsoft approves of Perl, and you can use it in nearly all their products? If you're starting out as a script developer then I think that VBScript will be much easier for you to begin with. BASIC was designed to be an easy language to pick up, and VBScript builds on this by providing significant features in the BASIC style. In particular, VBScript 5.0 has classes and regular expressions that provide the two main features that might lead you to Perl. The regular expression engine in VBScript uses the Perl syntax for its regular expressions, so you should be able to use the regular expression books out there to help you get going on the wonders of regular expressions. If you are a Perl developer already, then I think you already know the answer
Summary
Perl is a great language, and it's an asset to Windows that we want to continue to improve. The current Windows Scripting infrastructure allows you to use Perl pretty much anywhere script can be used, and I encourage you to try using Perl and VBScript/JScript in applications —and not only those that are Web-related. The Perl community is very active, and members are often vocal about their opinions (especially about Microsoft—but hey, perhaps this article will help assuage some of their fears!), but also very helpful to new Perl developers. So check out the newsgroups and Perl Web sites, and send the Script group e-mail telling us what you think about our Perl coverage and how we could make it better.
Andrew Clinick is a Program Manager in the Microsoft Script Technology group, so chances are, if there's script involved, he's probably had something to do with it. He spends most of his spare time trying to get decent rugby coverage on U.S. television and explaining cricket to his new American colleagues.