(The following article was originally written for the .Net Developer Journal where it featured in the Nov 2003 issue. This was co-written by Pooja and me and basically serves as an intoroduction to our DDL language. The original language was co-written by us and two of our friends Rakesh Nandakumar and Tony Sakariya as our final year college project. The DDL in its present .Net avatar is work by Pooja and me. The copyright perios of this article has expired, hence this post. You can find the article hosted on the magazine website here: http://www.sys-con.com/dotnet/article.cfm?id=460. I hope Pooja will be mirroring this article too)

 

Enter the Data Definition Language: a developer perspective

Roshan James & Pooja Malpani

(Authors of the DDL)

 

Greetings, In this short write-up we are going to discuss our new language for the .Net platform called the Data Definition Language (DDL). We hope that by the time you have finished reading this, you will want to log onto the internet, download the DDL and try it for yourself (and drop us mail about it).

 

The DDL is a unique language that aims at solving a common problem. We all would have faced situations where we needed to read data from a file of some given format and there are no real library routines for this purpose, other than the standard file handling libraries. In such cases, we would have to develop code that will calculate the addresses of various values that we want to retrieve from the file and write file handling code that will retrieve the data. While this is probably feasible for simple file types, the need to support a complex file type, or multiple file types or a changing file type can easily become a development bottleneck.

 

Once, we had to work with a development team that was creating an application for analyzing data collected in aircraft black boxes. Data dumps from black boxes have very complex formats. The team needed to read values of various aircraft parameters such as left-aileron-angle, right-engine-exhaust-temperature etc, which were scattered across various bits that seemed to have no respect for word boundaries or any such thing. To add to the fray there was no apparent standard between black box formats of the same manufacturer, version of the same aircraft or any such thing. The team needed to have their product support multiple black box formats without a huge development cycle between these. A little thought made it apparent that there was no real solution to supporting data retrieval from arbitrary file formats. This is the problem that the DDL was designed to solve.

 

How does the DDL understand the format of the file I want to read data from? The DDL is a language. It is designed to be simple and intuitive for expressing data formats. To develop a solution with the DDL a developer needs to first write a DDL script that represents the file format. Once the script is developed, you can run the DDL engine/interpreter on the script, provide the engine with your data file and you are ready to start reading information out of the file.

 

So how can I use the DDL in developing an application? The DDL engine is designed to be an interpreter that be hosted by any .Net application – which means that your VB.Net or C# programs can act as hosts for the DDL. A typical DDL solution would consist of your parent application that does all the UI and has all the business logic. This would host the DDL engine with which you can programmatically interact. The DDL engine simply acts as a substitute for your complex file handling code; it does not dictate what you do with the data that you have retrieved.

 

Hosting the DDL.

 

Once you have hosted the DDL engine, you tell it to do tasks such as ‘load this ddl script file’, to make it understand your file format. Then you tell it to ‘use this data file’ so that it can apply your ddl script (which defines the data format) of the actual data file. Then you tell it ‘give me the value of left-aileron-angle’ and the DDL engine looks at the script, understands where in the data file ‘left-aileron-angle’ would exist and reads out the value for your host application.

 

What are the DDL script files like? The DDL language provides you with primitive types that represent bits – these are available from single bit definitions to 32 bit definitions. These are named i1 i2, i3 etc to i32. Variables can be declared to represent any of these types.

            i16 width

This represents a 16 bit value called width.

 

Now declarations like this should be grouped into DDL structures. Structures would look like this:

 

struct Window

{

i16 width

i16 height
}

 

A DDL script file can contain multiple structures like the one above. Similar to the declaration of primitive bit types you could also define a structure to contain a member of another structure type.

 

struct Bitmap

{

      i8 BitsPerPixel

      Window w

}

 

The DDL script requires that you mark one structure in the script file as the ‘init’ structure. The DDL uses the “init” structure as the first structure of your data file – the init structure is mapped to offset zero of your data file. The init structures and its members (which maybe instances of some of the other structures declared in the script file) are expected to represent the entire data file.

 

The tree-like structure formed by structures in a DDL script file.

 

The DDL structures are different in concept from structures in languages such as C. The first difference is that a DDL structure can contain members depending on conditions. Secondly, a member in a DDL structure simply represents a region in the data file; an i8 type member would represent a byte-sized region. Members in a structure have their offset addresses from the base address of the structure automatically calculated or can have explicit addresses provided. This little script demonstrates both of these.

 

 

 

struct EmployeeData

{

      i32  empNumber

      i1   fPhoneNumberProvided

      i7   fUndefined

      when( fPhoneNumberProvided == 1 )

      {

            i8[10]      phoneNumberString

      };

      @ 0,0 i24 empSerialNumber

      i8 empDesigCode

}

 

This simple script demonstrates some interesting things. An instance of the EmployeeData structure will contain a member called phoneNumberString of 10 bytes, only if the fPhoneNumberProvided flag bit is set. Similarly the notation “@ 0,0” is an explicit address specification that causes the address of the declaration immediately following it to fall at an offset of 0 bits from the start of the structure. Thus, with respect to little-endian Intel architecture, the lower 3 bytes of empNumber are the empSerialNumber and the most significant byte stands for the employee’s designation code.

 

Layout of the structure with respect to the bits of the data file.

 

The script also demonstrates a simple array of i8 (or byte) type of ten elements. Unlike C, the size of an array can be specified via an expression. To illustrate the power of arrays consider the following snippet that uses the above employee structure.

 

struct EmployeeHeader : init

{

      i16 empCount

      EmployeeData [empCount] emps

}

 

The first member decides the number of employees whose data is provided and ‘emps’ represents as array of EmployeeData types. You can now ask the DDL engine for the designation code of the 5^th employee and DDL engine sets about to determine the location of the 5^th employee and retrieve its ‘empDesigCode’ value for you. Now remember that the EmployeeData had a member that would occur conditionally – this means that the size of each EmployeeData instance can be different. The DDL engine internally determines that there is a dependency and checks the flag in each of the preceding EmployeeData instances to determine the actual location of the 5^th instance that you requested.

 

The ddl script provides only a minimal set of programming constructs whose purpose is centered on being able to define data formats. The present ddl language is rich enough to support a wide variety of common file formats. There may however be some format types that may not be expressible in the ddl or are hard to express.

 

The DDL language has constructs for representing address specs, size specs, conditional dependencies, different kinds of array constructs etc. This is a just a brief description of the language, the complete language description document is available from the homepage.

 

Hosting the DDL Interpreter: This is probably the simplest part. Imagine that EmployeeHeader and EmployeeData together formed a ddl file called employee.ddl and that we had a data file in this format called empinfo.bin. The following C# snippet is all you will need to start off using the DDL.

 

using System;

using System.DDL;

 

class DDLTestClass

{

       static void Main()

       {

              //initialise the DDL

              ManagedDDLEngine ddl = new ManagedDDLEngine();

              ddl.LoadSourceFile("employee.ddl");

              ddl.OpenDataFile("empinfo.bin");

              ddl.InterpretData(); //this call is needed to map the scoure to the data

             

              Console.WriteLine("No of employees = {0}",

                     ddl.GetValue("empCount")); // GetValue() read the value of a variable

             

              //contents of emps[0]

              ddl.Seek(".emps:0"); //seek changes path into a member

              Console.WriteLine("Data of 0th Employee \n\t "+

                     "empNumber={0}",

                     ddl.GetValue("empNumber"));

             

              //contents of emps[5]

              ddl.Seek(".emps:5");

              Console.WriteLine("Data of 5th Employee \n\t "+

                     "empNumber={0} \n\t "+

                     "empDesigCode={1}, \n\t "+

                     "empSerialNumber={2}",

                     ddl.GetValue("empNumber"),

                     ddl.GetValue("empDesigCode"),

                     ddl.GetValue("empSerialNumber"));

 

              ddl.Dispose(); //clean up

 

       }     

}

 

This little snippet loads the ddl with the script file and a data file and reads values from it. This snippet does not show any of the error handling code that would be required in a production quality application. One concept you need to be familiar with is that of path.

 

The init structure is represented as “.” (dot). Any member under it is represented using its member name. Any child of that member is separated by a dot, and so on. If there is an array in the path, then the array instance is separate by a “:” (colon).

Ex

init.emp[0] will be represented as “.emps:0”

 

At any point the GetValue() call will return the values on any of the variables in the current path. The Seek() is used to set the current path to another location, subsequent GetValue() calls will read values from that location. Bit values that are read are treated as unsigned integer types. All values are returned as ‘double’ type.

 

A document describing the API exposed by the DDL is available on the homepage for details.

 

What is available? The DDL engine itself is currently for download as System.DDL.dll. This is a mixed mode .net assembly developed in Managed C++ and can be hosted in any .net application. The entire source code of the DDL is also available for download. The DDL is offered for use free of cost and is currently not under any licensing or royalty restrictions. We however expect that in return we get feedback that can help improve the DDL. If the DDL is used for commercial purposes we hope that the authors drop us a note and possibly give credit where credit is due – this would help in popularizing the DDL. You are however not required to do any of these and are free to use the DDL without any acknowledgements at all.

 

Also a console program is available which can be used to test-run DDL scripts that you are developing. This is also available in source form as an example of hosting the DDL. The site also has tutorial material about the DDL console as well as documentation about the language, API, internal algorithms and such.

 

Present and Future: The DDL in its .Net avatar is presently in Beta 1 status and is the work of two people. We believe that the idea of a generally useful DDL system has substance and are hoping to work towards it.

 

For future development we are hoping to strengthen to the DDL language so that the language can be used to express data formats that are currently not expressible or are hard to express. Also plans are underway for a compiler for the DDL language. The compiler is expected to take a .ddl file as input and generate a .net assembly as output that will be code streamlined for your ddl script, rather than be a general purpose ddl interpreter.

 

We are hoping to build a community around the DDL and would like to invite you to join the DDL development project. Inputs for future design aspects, known issues etc would be appreciated.

 

The DDL project homepage is http://ddl.sscli.net .

Contact us: spark at sscli dot net, dolly at sscli dot net.

 

(Download the article and related code sample here

The homepage for the DDL project remains http://ddl.sscli.net

You may also want to visit: http://www.thinkingms.com/pensieve/homepage/work/system.ddl/index.htm

And http://www34.brinkster.com/mpooja/work/Other/ddl/index.htm

A complete description of the language is available at http://www34.brinkster.com/mpooja/work/Other/ddl/html/DDL-Language.htm)

 

Please give us feedback about the language and what you would like to see implemented. One of the plans we have for the future is a compiler for the DDL – this has been postponed because various other projects kept getting in the way.

 

Antonio pointed me to one of his projects called ObjShell. It was little shocking – in objShell were the basic ideas of Monad, in a sense. ObjShell was research project done at the University of Pisa and was once present at MSR Cambridge.

 

This is the project page:

http://medialab.di.unipi.it/Project/ObjShell/

 

ObjShell isn’t very complete and requires much work before it is usable, but the core idea is that it wraps is a valuable one. Let me quote from the docs (added later: Antonio has a follow up post to this one and on reading it one may have a different perspective - I must say ObjShell could use some more documentation).

 

Shells issues discussed above may be addressed by component technologies leading to a new generation of shell that allow to access components that support arbitrary interfaces. Next generation shells must allow to combine system components that expose different interfaces. Moreover there must be the possibility of separate process and components having one process that executes methods of several components.

 

Figure 2. A new shell that allow combine general components.

 

Figure 2 shows the new role of the shell: instantiating and linking components to obtain an assembly that is able to solve a problem. The goal is to provide a suitable language that is able to offer such generality and at same time offer a convenient syntax for expressing components' composition.

 

ObjShell has been designed for supporting a new archiecture that offer both generality and flexibility of syntax for expressing commands.

 

The central idea behind ObjShell is that there can be a better model of composition than stringing together processes bound by text streams. ObjShell aims to have the shell provide an environment that allows plugging together of components. In the present build of ObjShell, it allows the usage of COM components over which the shell acts like the glue.

 

So the user of the shell uses the shell as an environment to plug together components to get a task done. You might have heard some of the old unix docs describing text as the universal interface – shells like this one try to replace that with a more programmatic interface and thus provide a better model for composition.

 

Monad is similar in this respect that it tries to provide a better model of composition – however Monad is closer to traditional shells in that it does not directly leverage a component model like COM or .Net, instead leverage components called Cmdlets which are .net components which follow certain rules (by rules I mean then inherit from a certain class / implement a certain interface / have certain attributes etc). Also Monad provides for glue between components by providing streams of .Net objects, to replace text streams in the old world.

 

(rewritten:) ObjShell interacts with users using 'Readers'. A reader reads an input stream and manipulates it into valid jascript that is executed internally. The jscript in turn makes teh calls on the objects and returns results. You coudl think of it being similar to intercative shells of languages like Python and Ruby where the shell displays a prompt at which you could type instructions of the language and the shell responds. ObjShell is different in that it goes a step further and allows you to type commands in a more shell-like syntax instead of compelling you to write javascript and  make method calls. (/rewritten)

 

There is a discussion with Jeffrey Snover, Architect of Monad on the MSDN show. There is this interesting part in the show (other than all the other cool things) where he calls Monad the third great pillar of composition. That is an episode worth watching.

 

Thinking of composition and command lines I have been thinking of my own work with Netshortcut. While the initial release of NS (which is what is available now for download) is on a different tangent, the plans for the new NS bring it close to the world of command shells. It however takes a different approach from Monad and ObjShell.

 

I do wish Antonio and team continue work on ObjShell to create a .Net version. It is will be a nice future where windows has different command shells to choose that offer different fundamental models of abstraction and composition built around the same object model called .Net.

 

Prev:

Msh/Monad: Cmdlet parameter binding
Introductory entry about Monad

 

Other:

Pooja: Monad Session at Bangalore User Group Meeting (lots of examples here)
Pooja: On getting the Monad installer to work on Win2k

Almost every macro demonstrates a flaw

in the programming language,

in the program, or in the programmer.

        - Bjarne Stroustrup

 

I find it unbearably restrictive

to program in languages without macros ...

        - Paul Graham

       

It took me some good time today getting my mind around macros in scheme. The discussion in Dorai Sitaram’s book is a not very descriptive. I had a look at Prof Kent Dybvig’s chapter about syntax and figured that that is something I want to look at only later.

 

However after a bit of mucking up I think this would work.

 

(require (lib "defmacro.ss"))

 

(define-macro let* (lambda (args . code)

        (if (null? args)

                `(begin ,@code)

                `(let

                        ,(list (car args))

                        (let*

                                ,(if (null? (cdr args))

                                        ()

                                        (cdr args))

                                ,@code)))))

 

(display

        (let*

                ((a 2)(b (+ a 10)))

                (+ a b)))

               

 

Thinking in scheme needs some getting used to.

 

I have been looking at a bit of scheme in my free time. Not strangely, most of the code I seem to write seems to be very C like.

 

(define rev1 (lambda (ls)

        (let loop ((res ()) (ls ls))

                (if (null? ls) res

                        (begin

                                (set! res (cons (car ls) res))

                                (loop res (cdr ls)))))))

 

(define rev2 (lambda (ls)

        (let loop ((left ls)(right ())(temp ()))

                (cond ((null? left) right)

                        (else

                                (set! temp (cdr left))

                                (set-cdr! left right)

                                (loop temp left ()))))))

       

 

(print (rev2 '(1 2 3 4 5)))

 

I understand that learning the language is very different from learning to program with it. For now I am learning the language from Dorai Sitaram’s “Teach Yourself Scheme in Fixnum Days”

 

Annie’s song is playing right now.

The sky looks gray now, like the color of old memory.

 

Annie's Song

 

You fill up my senses

Like a night in a forest

Like the mountains in springtime

Like a walk in the rain

Like a storm in the desert

Like a sleepy blue ocean

You fill up my senses

Come fill me again

 

Come let me love you

Let me give my life to you

Let me drown in your laughter

Let me die in your arms

Let me lay down beside you

Let me always be with you

Come let me love you

Come love me again

 

You fill up my senses

Like a night in a forest

Like the mountains in springtime

Like a walk in the rain

Like a storm in the desert

Like a sleepy blue ocean

You fill up my senses

Come fill me again

 

John Denver

 

 

A few days back I found what seemed to be a book about Ruby. This was being discussed on the Ruby mailing list. It’s called “A Little Ruby” or more precisely “A Little Ruby. A Lot of Objects”. You can find it here:

http://web.archive.org/web/20030618203059/visibleworkings.com/little-ruby/

(Someday it will be available here: http://www.visibleworkings.com/little-ruby/ )

 

Instead of writing the whole thing myself or copy paste it, I ask you to simply go read the book. That is my blog entry for the day.

 

The “Little Ruby” book is a conversation between two people where some sublime ideas about the design philosophy of the Ruby language are discussed. The book itself is a pleasure to read and more importantly, to think about. (It is an incomplete book, only 3 chapters – the author Brain Marick said on the Ruby list that he hopes to complete it sometime).

 

Reading “Little Ruby” put in a phrase in my thinking – “Model of Computation”, I don’t know if this sounds sober, but I think this is what I am really looking for.

In all my tinkering around languages, compilers, runtimes and other things – I am looking for a Model of Computation, a fundamental set of programmatic thought abstractions that are beautiful and can encompass various forms of programming.

 

The Little Ruby book talks about a model of computation where all computation is simply built around the idea of passing messages to objects. It is a simple concrete idea with which the rest of the Ruby world is built (apart of syntactic sugar). I don’t know if you are used to thinking in this way – but it is a powerful form of thought.

 

Let me quote from one of the conversation toward the end of the third chapter (the last chapter that is written so far):

 

“A language that provides lots of features

will always be missing that one feature you

need.”

 

“But a language that chooses the right

simple rules for you to combine lets you

build the features you need.”

 

This is the basic idea of composition – small integral units that compose to produce powerful behavioral entities. Have you ever thought why a unix command shell guy never really thought much of a Win/Dos user – because somewhere the way the shell forces you to thinking terms of composition of small do-one-thing-well tools and create powerful meta-tools, is a greater thought pattern.

 

You might have heard this being said about tools in the old unix culture (I say ‘old’ because I have different opinions of ‘unix’ culture as it is now)

 

"This is the Unix philosophy. Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface."

--Doug McIlroy

 

The “Little Ruby” book is inspired by the old book “The Little LISPer”. Something that is now on my reading list – I can’t seem to get a copy of this anywhere. The present edition of the book is called “The Little Schemer”. The book is co written by Prof Daniel P Friedman of Indiana University and Prof Matthias Felleisen of Rice University. The Little Schemer discusses a different model of computation from what the “Little Ruby” describes.

 

I did not know this then, but sometime last year I was in email correspondence with Prof Friedman. That time, had I known that he is author of a respected LISP text book, I might have been frightened off the prospect of asking this -  but in one of the mails I had asked “why Lisp?”

 

Roshan,

 

The most fundamental building block of computation is composition. If the language does not support composition in a trivial way, then I have no use for it.  ML, Haskell, LISP, and Scheme each give a kind of composition.  Composition is the building block of Category Theory, which is a unifying tool that helps clarify much of mathematics. and logic.  So, thinking that it would be okay to use a language that does not support composition is impossible for me.

 

(I quote this here presently without his permission, I believe he would be ok though).

I didn’t understand him then. But now after a year, I think I am closer to understanding him.

 

What would a unified model of computation be? Can such a thing exist? Can we think of all computation using a set of minimal and powerful abstraction such that every other form of computation can be built out of it. Can this be one that is easy and fun to use that we could interact with this force on a day to day basis.

 

And what forms the underlying foundation for computation then might also form the underlying basis for other systems of organized thought as well. This is like the dream of Grand Unified Field Theory in physics. Can something like that exist in the computational systems as well?

 

I don’t know enough to guess. But however I believe that as long we keep pursuing computing in a way that is fun and simple, we are probably on the right track.

 

 

To end this entry I want to quote from the preface of the little ruby:

 

Welcome to my little book. In it, my goal is to teach you a way to think about computation, to show you how far you can take a simple idea: that all computation consists of sending messages to objects. Object-oriented programming is no longer unusual, but taking it to the extreme - making everything an object - is still supported by only a few programming languages.

 

Can I justify this book in practical terms? Will reading it make you a better programmer, even if you never use "call with current continuation" or indulge in "metaclass hackery"? I think it might, but perhaps only if you're the sort of person who would read this sort of book even if it had no practical value.

 

The real reason for reading this book is that the ideas in it are neat. There's an intellectual heritage here, a history of people building idea upon idea. It's an academic heritage, but not in the fussy sense. It's more a joyous heritage of tinkerers, of people buttonholing their friends and saying, "You know, if I take that and think about it like this, look what I can do!"

 

As a closing note, sometime last year I was looking to do research under someone working with the SSCLI code base and work on virtual machines and runtimes. I wanted to do my Masters.

 

At that time the best way I could describe what I wanted to do was to say that I was looking runtimes and virtual machines research with a specific interest in SSCLI. Now, maybe I can describe myself a little better.

 

The only way I could think of doing this that time was to ask around in online forums and mailing lists about universities doing work with Rotor. That accompanied by a barrage of mails to everyone who I thought might know, or point me in the right direction. One name that came up was of Prof Ralf Johnson of UIUC. Right now I was looking for Brian Marick (author of little ruby) on Google, Brian is research student doing his PhD under Prof. Johnson.

 

India Advocates Day(s) 2004 happened a few weeks back (29 and 30th May) – MVPs, Microsoft Regional Directors and a select few Student Champs are invited. The event this year was at the luxurious Park Hyatt at Goa.

 

 

  

 

Images from the Park Hyatt - IAD 2004 venue.

 

Pooja at IAD.

 

Me - Self picture at the Hyatt beach

 

 

MVP crowd - also (first from left) Abhishek Kant - India MVP lead and
(fourth from left) Shu-Fen Cally Ko - Regional Director for MVP Program and Community - Asia Pacific and Greater China Region

 

IAD conferencing

 

 

  

Churches of Old Goa - Bom de Jesus

 

I just had to drop these links at the expense of a separate entry, for them.

http://primates.ximian.com/~miguel/archive/2004/Jun-08.html

http://primates.ximian.com/~miguel/archive/2004/May-31.html

(The Marcelo in the last picture on this entry is Marcelo Tosatti – Maintainer of the Linux kernel)

 

There are reasons why many of my friends who work non Linux technologies are generally treat work on Linux as user hostile and generally immature. I personally think that while the majority of the Linux crowd may have their head in the clouds, the serious programmers are the same sort of the free style systems hackers that we idealize – despite the difference in technologies. I appreciate these folk for their spirit and sometimes for sheer smartness.

With some things cleared up and some ground work done, here is one of the first the things I want to talk about in Monad – the new Microsoft Command Shell(msh).

 

In my first article I talked about ‘cmdlets’ and that they return .Net objects. Here is one other smart and subtle thing they did with Monad – Parameters to cmdlets come not only on the command line but can also come from objects in the input object pipeline.

 

Some basic stuff on cmdlets and parameters which might help set the stage for understanding things. A command-let can define fields/member variables as part of the command let class. These fields can then be decorated by attributes so that they can be treated as parameters to the commandlet.

 

In code it actually looks like this:

 

[CmdletDeclaration( "demo", "cmdlet" )]

public class HelloWorld : Cmdlet

{

        [ParsingPromptString("Enter a string to echo: " )]

        [ParsingParameterMapping(0)]

        [ParsingMandatoryParameter]

        [ParsingAllowPipelineInput]

        private string message;

(This snippet is a modified version of code from the beta documentation)

 

Now this might look a little over decorated with attributes, but the thing I want you to notice is that that is a member called ‘message’ which simply has a few attributes applied. Applying those attributes causes ‘message’ of type System.String to be a parameter required for our command let.

 

Unlike traditional command line exes, the responsibility of parsing the command line options and assigning them to internal variables is not the responsibility of the program but is automatically done for you by the Monad shell.

 

Which is to say that by the time code that you write in the cmdlet is executed, values are already assigned to the parameter variables by the shell. (Not strictly, but almost).

 

The shell can let you assign parameter values either by specifying them at a certain postion in the command line – for example argv[1] will be the value for ‘message’, argv[2] will be the value for something else and so on. Or the shell lets you  specify the parameter name and then the value

> demo-cmdlet –message “hello world” -< parameter name >  < value >

 

The other good thing (which is new and what this log entry was about) is that the value for a parameter can be extracted from an object on the pipeline if the object has a field/member of the same name. (The types have to be consistent)

 

So if I have a command let that generates an object of type foobar that has a member of name ‘message’, I can pipe the output to the commandlet that required a parameter of name ‘message’ and it would all work.

> create-foobar | demo-cmdlet

Would create foorbar instances that get piped to demo-cmdlet which uses the ‘foobar.message’ as its message parameter.

 

Where would this be used?

 

For an example there is a command-let called ‘get-process’. It lists the running processes on the system. To be more precise it returns a collection of process instances which get standard formatted to the console.

MSH 5 C:/>get-process

 

ProcessName                  Id   HandleCount   WorkingSet

-----------                  --   -----------   ----------

CcmExec                     288           480     14008320

cmd                         804            22      1421312

csrss                       464           669      4743168

dfssvc                      316            70      3260416

DWRCS                      1444            44      2560000

explorer                   3520           366     20926464

FrameworkService           1544           303      9367552

Idle                          0             0        16384

 

Similarly to see all the instances of notepad that are running I would simply say

MSH 16 C:/>get-process note*

 

ProcessName                  Id   HandleCount   WorkingSet

-----------                  --   -----------   ----------

notepad                    3912            16      1912832

notepad                    4044            16      1912832

notepad                    3056            16      1912832

 

Now there is a cmdlet called stop-process which can terminate a process if you pass it the process id as a parameter. The parameter name that stop-process expects is called ‘Id’.

MSH 11 C:/>command stop-process

 

Command: stop-process

Command Parameters:

        Id                    : Int32[]         : Optional

        ProcessName           : String[]        : Optional

 

So with all the earlier talk you can conclude that if I simply wanted to kill all the instances of notepad that are running I could type

MSH 11 C:/>get-process note* | stop-process

 

Now isn’t that clean? Just to add a bit of garnishing to that, Monad defines ‘ps’ as an alias to get-process and ‘kill’ as an alias to ‘stop-process’.

So now you can say

MSH 11 C:/>ps note* | kill

 

Cool? This works on Monad today.

 

Prev:

Introductory entry about Monad 

 

Next:

ObjShell: A precursor of Monad?