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  
this.

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...

---

http://tfl09.blogspot.com/ 
2003_11_01_tfl09_archive.html#106769921834716276

#####
MSH Rocks

MSH Rocks!!!
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  
inter-command processing.

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
foreach ($p)
{ $p.FileName.ToString()
}
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  
cmdlets.

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  
domain

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 mailing list