Big, big tech news / bits
jbone at place.org
jbone at place.org
Sun Nov 9 21:16:52 PST 2003
Okay, I don't know whether to be shocked or terrified or thrilled or
all of the above. Apparently, Microsoft is really innovating, and
mainstreaming that innovation rather than burying it under a crippling
legacy. Of course, that's just speculation --- the legacy burden is
probably much greater than betrayed here. But bottom line --- anybody
that's moving in the "deep language (CLI) interface to machine"
dimension is making good progress. And I worry that they might own
Of course, on the other hand --- how long will it take the open
sorcerers to rip off anything truly interesting in this?
Monad. What hubris in naming!
Caveat: M$ apparently still feels that passing structured / typed data
over generic interfaces is more powerful than passing e.g. raw NL text
with the "file / line" convention. I'm still skeptical, though this is
certainly in line with e.g. REST-like biases. Bottom line: I think
this is a finger-in-dike solution, one that forestalls the important
investment (figuring out implicit semantics automatically) and pushes
the burden out to the data-producer / data-marshaller...
One of the coolest things I saw at the PDC was Microsoft's new command
shell, code named Monad. Also known as msh, this new tool is possibly
the biggest advanced in scripting since Unix scripting was invented.
Yeah, I know, big words. But let me tell you about it!
Before getting into what Monad is, let's look at conventional unix
scripting. One of the real power features of unix (and here I include
Linux, BSD, etc, etc) is the ability to string along a bunch of tiny
commands via the pipe commands. This allowed you to crate truly useful
tools. This is something that was never really possible with Windows.
Possibly the very best thing about unix is the huge array of very
simple programs that can be strung together to do everything you need.
In the Unix world, you take tiny commands, cmdlets in MSH-speak, which
are either built in (eg ps, ls, cat, touch) or which you can easily
write, and let them communicate via the normal stdin/stdout/stderr
pipes. In the unix world, this works very well. However, there is one
fundamental obstacle here. Cmdlets communicate in the pipeline via text.
Now text input/output (stdin, stdout) is cool. BUT: the individual
cmdlets are written using absolutely no standard way of expressing or
mandating input and output data formats. Thus, in order to do good
shell programming, you also have to master grep, sed/awk/perl, etc. in
order to manipulate the various inputs and outputs. Unix scriptmeisters
will be familiar with the having to "drop the 1st two lines, then go to
col 34 and take the next 10 chars but if there were tabs instead of
spaces, etc, etc." Let's face it: text sucks as a method of
MSH takes the incredible power of the pipelined cmdlet approach of
Unix, but instead of passing raw text, MSH sends NET Managed objects
between cmdlets. That's right, objects, not raw text. Managed, type
safe, and easy to write/extend .NET Managed objects! Now with such .NET
objects, you get rich metadata available ot the cmdlets. The MSH shell
then uses .NET reflection to get this information into the cmdlet.
Now the format take a bit of getting used to, but you can type
something like: "get /process" to get a list of processes running. You
could string this together with the where cmdlet giving: get/process |
where "handlecount -gt 500" to print out a list of processes with large
handle counts. Now since you are passing .Net objects, the second
cmdlet (where) has the full metadata of the process objects create by
the process cmdlet. So it can do a 'where' based on all the processes
attributes such as handle count, memory usage, etc, etc. And of course,
there are a ton of formatting options since you know all about the
attributes of the passed objects.
You can also write more complex scripts, such as:
$p = get/process
This assigns the output of the get/process to an array then prints the
file name property of each array member (i.e. prints the file names of
the executables for each process in the process list) . At least I
think this is right! Apologies if the syntax is a big mangled
The next cool thing is how msh handles namespaces. In unix, cmdlets
essentially have just one namespace: the file system. MSH has this, but
also adds the registry, active Directory etc as namespaces. So you can
go: CD AD:\ and get into the AD, where you can type DIR and get a
listing of the top level objects. Or, type "CD HKLM:\" and be able to
see the top of the registry. And of course, you can write your own
namespace provider! MS plan to add a provider for SQL, and are open to
adding others. I want a DNS namespace provider!
Then there's all the cool output options. Builtin, MSH supports output
formats including HTML, XML, Excel, Word or even good old formatted
Text. If you want to output text, you have all the formatting options
you want, either from the shell, or in code if you write your own
Developers will love the cmdlets - they're incredibly easy to write -
and being .NET based, you can write them in any .NET language. Your
cmdlet class inherits from the commandlet base class. You just need to
add a few attributes and hey presto you have a cmdlet!. And since the
cmdlet has the full .NET namespace at its disposal, your cmdlet has
access to anything and everything you could possibly want!! There are a
bunch of simple examples in Jeffrey Snover's PDC deck.
Finally, the MMC will in future be based on this. So you can use the
MMC to do some command, then dump out the MSH script that would be
needed to do that action again. Then you can apply this to your entire
And as to the name. At first sight, it seemed odd, but Jeffrey Snover
told us that: "the name came from Leibniz's Monadology, a philosophy
which says that everything is a composition of smaller things (the
smallest being a Monad)". I could go on - but I was totally blown away
by the presentation and the demos. I'll post more details once I get
them! Watch this space!!
# posted by Thomas at 11/1/2003 03:06:58 PM
More information about the FoRK