As I mentioned last time, this series of articles will introduce you to some of the features of Monad’s hosting model.  Before we get into the details of hosting Monad, though, we need to first lay out our conceptual framework.

Our application is a simple WinForms control.  It displays a small triangle (of Logo fame,) and users control movement of the turtle through a small set of commands.  The turtle supports the following:

Do you have an awesome little script that you want to share with the world?  A Monad administration technique so slick that you want everyone to know about it?

Here’s a great chance - the opportunity to include your work in a forthcoming O’Reilly “Monad Hacks” book.

As you might know, one of the great hallmarks of this series is that it includes contributions from enthusiasts worldwide.  I’m continually amazed at the techniques that you all come up with.  It will be great for those techniques to help jump-start the learning process of countless future administrators and power users.

A while back, I wrote the article, “A Web-enabled, Monad front end: Monad hosting.”  It was in reference to WebCmd, a neat little Javascript application that emulates an interactive terminal.

I also talked about the fact that it wasn’t really an interactive terminal. 

This falls quite short of the infrastructure required to support an interactive program such as VI. Let alone Emacs :)  There’s no support for cursor positioning, keyboard polling, and much more. For the Unix world, take a gander at the feature set of the VT100 Terminal Emulation Requirements. For the Windows world, look at the Win32 Console API. To make a fully interactive web-enabled front-end, you would need to implement the equivalent of cmd.exe in Javascript. The performance would be atrocious. So in the end, it’s attainable – but at a very large cost. Once you’re done writing that much Javascript, you’re likely to start rocking back and forth, whilst arguing with yourself.

There are some very useful parts of the .Net framework (ie: System.Web and System.Windows.Forms) that Monad doesn’t load into its AppDomain by default.  In order to use them, you first load them with one of the Load() methods from the System.Reflection.Assembly class.

At first, the easiest approach seems to be LoadWithPartialName.  You can simply request “System.Windows.Forms” and be done with it:

MSH:73 C:\temp > [System.Reflection.Assembly]::LoadWithPartialName("System.Windows.Forms")

GAC    Version        Location
---    -------        --------
True   v2.0.50727     C:\WINNT\assembly\GAC_MSIL\System.Windows.Forms\2.0.0.0__b77a5c561934e...

(you can cast the result to [void] if you don’t want your script to belch the loading information.)

You might remember a recent obfuscated Monad script that Adam wrote.  It’s impressive, but not as obfuscated as this one! 

This turned up in a search I was doing – feed2podcast.com looks like an interesting idea.  Thank goodness they don’t index the comments, because the spam sure is piling high there, Adam :)

[Edit: Monad has now been renamed to Windows PowerShell. This script or discussion may require slight adjustments before it applies directly to newer builds.]

A topic came up on the newsgroup today that I thought was a good segue into a series of posts that I’ve been working on.  Paraphrased, the question was, “How do I get Monad to do stuff from another .Net language?”

There are two ways to go about this, depending on the requirement.

The first is to cleanly separate your object model from your cmdlet implementation.  You write a class that does what you need it to.  You can invoke that class from .Net like any other class, and write your Cmdlet as a thin wrapper to interact with that same object model.  Think of this as the business logic / UI separation that is so important in designing a good application.

I had a phone interview with Michael Brick at the New York Times a few weeks ago about the problems I (and others) have had with certain shady online camera dealers.

His article on that just got printed, and it’s a good read.

Especially interesting is the various official quotes that explain how difficult it is to solve the problem.  Our collective internet rage takes place in a thought-based medium, where anything is possible.  We CC company CEOs on complaint emails, conduct virtual letter writing campaigns, and many other grand schemes for enacting change.  The transition to reality isn’t nearly as high-fidelity, and illustrates a sharp contrast:

The microsoft.public.windows.server.scripting newsgroup has really blossomed into a useful community for Monad users.  When I post lengthy responses to the newsgroup, I very rarely post them to this blog as well.

So the question is – how many of you do not read the newsgroup?  Feel free to post your response in either email, or a comment below.  If many of you read only the blogs, then I’ll start posting more entries based on newsgroup threads.

I’m rebuilding my computer, so I don’t have access to anything I have been planning to blog.  So instead, I thought I’d write about something that is commonly considered difficult – but is actually quite within the reach of most of us.  Adding a high-fidelity music input source to your car.

If you have an MP3 player (or portable satellite receiver,) the first thing most people try is adding broadcasting the signal to their car stereo via an FM transmitter.  Transmitters designed for personal use are terrible, even under ideal conditions.  When I tried this, I managed to improve reception somewhat by placing the transmitter at the end of a long headphone extension cable.  This lets you place the transmitter as close to the car’s antenna as possible, and also acts as an antenna to increase the signal strength of the FM transmitter.  Doc Searls talks a little bit more about that here.

Howard van Rooijen, who works for Conchango, just posted a neat integration of CodeSmith, MSBuild, Monad and Windows Workflow for his company’s Community Day.  We spoke about integrating MSBuild with Monad during the Hands on Labs at the PDC (and a few times since,) and it’s cool to see what’s come of his tinkering.

His Congestion Charge Demo simulates London’s Vehicle Congestion Charging System – the automated system that charges a premium for driving within central London during peak hours.