Foreword


Monad is a next generation shell or command interpreter that embraces traditional shell concepts by providing interactive and simple scripting experiences. However, Monad breaks new ground by leveraging the power of objects, providing a full-featured language with native support for rich data types, and refactoring the shell, commands, and utilities. The result is a shell that supports a wide range of users from interactive command-line users to the most sophisticated scripters.

I started the Monad project with the intention of rewriting WMIC, the command-line interface to Windows Management Infrastructure, in C# (WMI is one of the primary APIs used to manage Windows). WMIC proved to be a very successful endeavor; it has a common command-line engine to do parsing, error handling, and object manipulation; and it uses small amounts of metadata to drive the engine to manipulate WMI objects. This architecture provides some important economic incentives:

  • Every improvement made to the engine benefits every command, providing an economic incentive to improve the engine.

  • Users have common syntaxes and semantics to all commands, providing an economic incentive to learn how to use the tool.

  • Only a small amount of metadata is required to create commands, providing an economic incentive to generate commands.

While the power of WMIC is awesome, it has a syntax that many find awkward. It is completely dependent on WMI coverage, which is good for Windows but troublesome for third parties. While developing the architecture, Bill Gates beat me up regularly because our management technologies did not provide adequate support for .NET programs. I decided it was time to find out what had him so excited.

I learned .NET by rewriting WMIC in C#, fixing up its syntax, and adding support for XML. During the process, I found .NET Reflection. I was delighted to discover that it provided about 70 percent of what was needed from WMI (e.g., the ability to ask any object to state its properties/methods, get the property values, and invoke the methods). At that point, I realized that the architectural power of WMIC could be applied to any .NET object, and that's when things took off.

We formed a team and fleshed out all of the details. We transformed the core concepts into a full-fledged automation environment that included an interactive shell, a powerful scripting language, a rich set of utility functions, a set of commands, and an SDK. We envisioned a program that would make it as easy to interact with data stores as it is to interact with the filesystem. Our vision was to produce something that would be as interactive and composable as KSH or BASH, as programmatic as Perl or Python, as production-oriented as AS400 CL or VMS DCL, and as embeddable as TCL or WSH.

Most of the people on the team have extensive experience working with COM and Unix. COM scripting is powerful, but it requires you to work at a programmer's level of abstraction. The Unix composition model is also powerful, but it provides an escape valve that relieves you of any pressure you might feel to go back and refactor the tools. When SH didn't support what you needed to do, you just wrote a new tool such as AWK; and when AWK didn't meet your needs, you had to write yet another tool. Each of these tools required a new learning curve (and sometimes a new set of books). While the Monad team has enormous respect for these programs, we knew we had some improvements to contribute.

Jim Truher, our shell program manager (PM), is experienced in working with Unix scripting. His input was invaluable in preserving the essential semantics of the Unix model, while reframing them in a way that led to a more consistent syntax and improved user experience. Bruce Payette, our development lead, is a walking encyclopedia of languages and was able to educate us about the outcome of just about every good, bad, and wacky idea that has ever been tried out in a language. Kenneth Hansen, our SDK PM, has an extensive background working with provisioning systems. He crafted a namespace model that allows you to interact with all the data stores (e.g., the Registry, the Certificate store, andin the futureActive Directory, SQL, etc.) the same way you interact with the filesystem. In addition to Unix and system/network management, I have developed and used VMS systems, the operating system of the DEC VAX minicomputers. Also, I am a big fan of the IBM AS400 and its command language (CL). Both of these environments have a strong focus on production qualities and naming/syntactic consistency.

Together, we felt that it was time to step back and perform a "grand refactoring" among the shell, the utilities, the language, and the commands. Our goal was to incorporate the best of these environments into a single cohesive program.

The result is Monad. Whether you are looking for a better Windows command-line shell, a simple environment to crank out ad hoc scripts, or a hardcore scripting language to generate and publish sophisticated production scripts, Monad should meet all of your needs. We think you'll like it.

Monad Architect

Jeffrey P. Snover




Monad Jumpstart
Monad Jumpstart
ISBN: N/A
EAN: N/A
Year: 2005
Pages: 117

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net