6.2 Windows scripting environments

Under the current Windows Operating System platform, we have two important scripting environments implemented by CMD.EXE and WSH. CMD.EXE uses the old-fashioned CMD (command-line) commands, while WSH is purely COM/DCOM based. When looking at the Microsoft .NET strategy, how do the CMD and WSH environments fit into the .NET Framework, which uses a completely different run-time environment? This current .NET Framework run-time environment is currently not designed to support scripts, or at least in a way we know scripting today. This is where Microsoft is still determining many options they can pursue over the next two to three years.

We have a good realization about many of the shortcomings of the existing scripting environment. For the CMD environment, limitations exist, such as not being able to access system management data without the use of an external executable or script that acts as a "black box." For WSH, we have another set of limitations, such as the use of non-strongly-typed languages such as VBScript and the inability to invoke any .NET Framework features or Win32 APIs (unless you use PERL with a third-party scripting engine that supports Win32 API calls). Another confusing problem is the need to use different COM technologies to retrieve management data (i.e., ADSI, CDOEXM, WMI, to name a few). In addition, these COM technologies sometimes overlap each other (i.e., you can start and stop Windows services with WMI, but you can do this as well from ADSI), which creates additional confusion.

Although there is no concrete architecture or components today to address these limitations and leverage the actual scripting technologies via the power of the .NET framework, Microsoft would like to eliminate most of the limitations that exist in the current environments while maintaining the advantages that the scripting technologies offer today. In this respect, the golden rule is "simplicity"! In other words, the technology must be easy to learn and use.

Looking into the future, we could predict that Microsoft will get rid of the current CMD shell, since it is the origin of many limitations. A new CMD shell built on top of the .NET framework could replace the current version. This development may also imply that we will see a new WSH environment. Currently, WSH is based on a COM/DCOM-based architecture, but we know that Microsoft is basing any new development on top of the .NET framework, so it is clear that the "new" WSH will certainly not be the same as today. It is more than likely that a new shell will support a more powerful command-line language while supporting one or more scripting languages. It is also possible that the new shell will support both graphical and text interfaces to make script writing and execution easier. For instance, with WSH today, any administrator can start Notepad, write a few lines in Jscript or VBScript, and launch the script to begin executing. This is an ease of access to programmatic control that most programming languages don't support, and Microsoft is conscious of the advantages delivered by such an implementation. However, it will take time before we get to a Windows platform that is 100 percent .NET enabled, and, because of this, we can be almost certain that the current COM/DCOM WSH and WMI architectures will not vary enormously over the next two to three years.