Sign up for the ITPro Today newsletter
Stay on top of the IT universe with commentary, news analysis, how-to's, and tips delivered to your inbox daily.
Rem: Comparing Perl and VBScript
Which scripting language you should use largely depends on the tasks you're automating and the target Windows platform.
Bob Wells
March 12, 2002
3 Min Read
Do you have a scripting-related question or problem? You can send your question or problem to [email protected].
I just started using Perl and recently discovered VBScript. Should I switch to VBScript, or can I use Perl's Win32 modules to script most tasks?
The answer largely depends on the tasks you're automating and the target Windows platform. In my opinion, the most important Win32 Perl module is the Win32::OLE module because most of the Windows platform is exposed through COM automation interfaces rather than command-line tools (although support for command-line tools improves significantly in Windows .NET Server—formerly code-named Whistler—and Windows XP). By learning how to use Perl's Win32::OLE module and several COM automation libraries, you can perform a wide range of tasks on the Windows platform without depending on additional Perl modules. Popular COM automation libraries include
ActiveX Data Objects (ADO) for database-access and database-management tasks
Microsoft Active Directory Service Interfaces (ADSI) for tasks involving directory services, such as the SAM database and Active Directory (AD)
Collaboration Data Objects (CDO) for messaging tasks
Windows Management Instrumentation (WMI) for systems-management tasks (e.g., managing event logs, the Performance Library, the registry, and Win32 system settings)
the Microsoft Office object model for tasks involving Office applications
You can use other Perl modules if you prefer. However, your scripts will be limited to the capabilities that the modules provide and the command-line tools that your scripts use.
VBScript relies exclusively on COM automation, which means you must use the COM automation libraries I just mentioned. You can also use command-line tools by way of Windows Script Host (WSH) 5.6. Specifically, you can use the WshShell object's Run and Exec methods.
If your Windows platform requires that you use COM automation libraries, such as ADSI and WMI, what aspects of Perl and VBScript might lead you to choose one over the other? Here are a few advantages and disadvantages to consider for each scripting language, followed by some practical advice based on my experience.
Perl. Perl's advantages and disadvantages include the following:
Perl is available on more platforms than any other scripting language, making Perl particularly well suited for multiplatform scripts.
Perl is a more powerful language than VBScript, which means you can use Perl to accomplish tasks that you can't perform with VBScript alone. For example, you can use Perl's unpack() function to read binary data, but you can't use VBScript to read binary data without the aid of a custom component or utility.
Perl can be more obtuse (i.e., more difficult to read, comprehend, and maintain) than VBScript.
Perl isn't part of the Windows platform, which can lead to additional management overhead, depending on how you choose to distribute the Perl runtime and associated modules.
The Perl Win32::OLE module's support for events is limited.
VBScript. VBScript's advantages and disadvantages include the following:
VBScript's native COM support makes working with COM objects as easy as COM gets.
WSH, which includes VBScript and JScript, is a core component of the Windows platform.
You can sign WSH 5.6 scripts and control their execution through policies.
VBScript is a small, simple, and easy-to-read language, which can make it less intimidating to nonprogrammers.
VBScript is a subset of the Visual Basic (VB) language, which means you can leverage your previous VB experience—and improve your VB skills in the process.
VBScript lacks support for some data types, which makes it unsuitable for some tasks (e.g., reading AD attributes of type octet string).
These lists are by no means exhaustive, but they point out some of the more important language and environment characteristics to consider. In the end, I advocate that you don't limit yourself to one tool or technology. Analyze the task at hand, evaluate your options, and select the right tool for the job.
About the Author
You May Also Like
.jpg?width=700&auto=webp&quality=80&disable=upscale)
