Beefy Boxes and Bandwidth Generously Provided by pair Networks
more useful options
 
PerlMonks  

What Does Microsoft Think of Perl?

by Gurr (Novice)
on Jul 19, 2002 at 15:22 UTC ( #183268=perlmeditation: print w/ replies, xml ) Need Help??

I got this article from Microsoft MSDN web site. It is interesting!

Editorial note: This article is copied without permission from the original MSDN article. Attempts have been made to retain the spirit of the original formatting (if not the precise appearance) and content; however, some mistakes may have been made in translation. If such mistakes have been made, we apologize for the inconvenience.

Perl of Wisdom
Andrew Clinick
Microsoft Corporation

January 22, 1999

  • Contents
  • What Is Perl?
  • What Does Microsoft Think of Perl?
  • Where Can I Use Perl?
  • Where Can I Get Perl for Windows?
  • Internet Explorer
  • Internet Information Server
  • Using the <SCRIPT> element
  • Using the <%@ LANGUAGE %> directive
  • Calling ADO with server.createobject
  • Calling AD rotator using the <OBJECT> tag
  • Windows Script Host
  • Should I use Perl instead of VBScript?
  • Summary

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.

Editorial note: Original diagram is not repeated. Please see the original source

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.

Edited>: ~Mon Jul 22 03:49:07 2002 (GMT/UTC)
by footpad: Replaced initial use of <CODE> tags to somewhat reflect the original formatting of the original post and added editorial notes near the beginning of the node. Per Consideration.

Comment on What Does Microsoft Think of Perl?
Select or Download Code
Re: What Does Microsoft Think of Perl?
by dragonchild (Archbishop) on Jul 19, 2002 at 16:32 UTC
    They're saying that Perlscript is to be used client-side?!? Forgive me for being presumptuous, but isn't that how the vast majority of web-hacks occur, because developers put too much control client-side? So, now they want to give hackers the capability of doing all their client-side hacks, but allow them to have the power of Perl. This is not a "Good Thing"(tm). This is a "Bad Thing"(tm).

    <CYNICAL>Plus, even though they say it's open-source right now, they'll eventually say "Well, we had so many people begging for a MS-approved version, so we just went ahead, bought the rights, and made one." I don't like that route. Anyone will cave with M$100 thrown at them. I know I would.</CYNICAL>

    ------
    We are the carpenters and bricklayers of the Information Age.

    Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

      ObUsageFlame: s/hacker/criminal/g;

      Don't forget that Perlscript's probably going to end up in the HTML renderer, which makes the problem infinitely worse (in that everything using that component will be vulnerable, not just IE). On the other hand, it'd be a smart move on Microsoft's part, because features sell, and client-side Perlscript has a rather high shiny! coefficient. Throw together some slick demos, impress the lusers convention-goers, and add another bullet point to the back of the box. (Then sit back and watch BUGTRAQ go fucko bazoo.)

      Microsoft doesn't care about security, just about profits. Unfortunately for many of us, most of Microsoft's client base doesn't care about security, either.

      --
      The hell with paco, vote for Erudil!
      :wq

      dragonchild with all due respect, I would disagree and assert that there's no inherent ill in using client-side Perl script, as compared to any other scripting language. Perlscript is no less secure than Javascript, or VisualBasic for that matter.

      But I concur with your point that putting too much client-side code up may be a dangerous thing. There are a couple home-nodes here were you can find javascript that steals your cookies and reveals a bunch of other JavaScript holes. In the end however, the choise of proper balance is all left to developer(s) involved. There are a lot of cases where you simply can't go by without client-side scripting. Things that spring to mind are form input validation (prior to the form being submitted), some DHTML stuff, and so forth. These things are hardly prone to any exploits. The worst one could do with them is mess up webpage appearance... However, if I was presented with a choice, I'd go for PerlScript vs Javascript. ;-)

      Update 1: In a gesture that could be deemed as self-defense, let me clarify that I think client-side perl is going to be somewhat limited in it's faculties than it's server-side equivalent, just as is the case with Javascript now. So, there's no reason to be panicky about PerlScript being so immensely powerful as to open ways for new creative hacks ;-).

      _____________________
      # Under Construction
        (I am not a JScript or VBSCript guru, so I may be wrong in a few assertions below.)

        Perl isn't less secure. Perl is more powerful. You cannot access the operating system with JScript or VBScript. You cannot (easily) initiate a download from some other server and execute that code.

        Even more importantly, Acme::Bleach doesn't exist in anything but Perl. That alone makes security checking through regex impossible.

        My concern is that the increased power of Perl will not come with increased safeguards on the part of the browser manufacturers or the plugin manufacturers or the OS manufacturers. THAT is what I am scared $h!tless about.

        ------
        We are the carpenters and bricklayers of the Information Age.

        Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

      Having used PerlScript on windows as they have mentioned, the article glosses over just exactly what steps are required to get PerlScript onto a Windows machine and of course, not everyone is going to go and download and install it.

      This article is really about trying to win more converts to its way of doing things by winning over elements of the Perl community. However considering the articles age (January 22, 1999) I think its clear to see it didn't (or wouldn't :P ) happen.

      Showing client Perl is not a way of making friends and influencing people and so I'd just ignore it for the futile feature it is. As for the whole document, who honestly read it and though - wow, maybe Microsoft like Perl after all! And who can honestly argue that point when there are so many arguments against it?

      Personally I've written a Perl ASP page and went back to plain Perl - there was just no point to it. I have to write ASP at work and using PerlASP is like buying a guard dog and neutering it with a hammer just before it goes on duty. The only use I, personally, can see is machine automation with WSH and thats exactly what I have done and will stick to.

      But of course thats just my opinion :)

      Update: added document age etc
Re: What Does Microsoft Think of Perl?
by rbc (Curate) on Jul 19, 2002 at 16:55 UTC
    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!

    Unfair! You can write unintelligible code in any language!
    It is just easier to write unintelligible code in Perl,
    just as it is easier to write readable code with Perl.

      There are also Obfuscated C Contests.. and if you want hard to read code, just try soaking up the swathes of gunk the MSVC++ wizards generate.

      A tool not useable for nonsense is a tool not useable for anything.

      Makeshifts last the longest.


        i think that they just talk about perl that way ...
        (they don't think so) that it's good (not great)
        programming language...

        strange that they don't talk about asp
        (how it's great ;) (for them))
Re: What Does Microsoft Think of Perl?
by theorbtwo (Prior) on Jul 19, 2002 at 20:05 UTC

    If you'd prefer to read this with less copyright infrigement and more formatting, see the original.


    Confession: It does an Immortal Body good.

Re: What Does Microsoft Think of Perl?
by abstracts (Hermit) on Jul 20, 2002 at 01:58 UTC
    Perl is a great language, and it's an asset to Windows that we want to continue to improve. ... 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.
    Who are "we" in the first sentence there? And I don't think this article would "assuage" anybody's fear given Microsoft's well known "embrace and extend(tm)" tactics.

    May the GPL protect us all from all evel. Amen.

Re: What Does Microsoft Think of Perl?
by trs80 (Priest) on Jul 23, 2002 at 04:54 UTC
    Didn't the NT 4.0 Resource Kit ship with the HIP distro of Perl?

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://183268]
Approved by dragonchild
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others drinking their drinks and smoking their pipes about the Monastery: (3)
As of 2014-07-24 02:40 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite superfluous repetitious redundant duplicative phrase is:









    Results (156 votes), past polls