The Empty Shell Page


This will be a command shell for Win32, specifically NT4 and higher. That is, I won't put too much effort into making sure it works under Win95, but if anyone wants to lend a hand that fine with me.

The Shell will do one thing well: be extensible.

That is, the features such as the command set, new ideas on text-based command prompts, and GUI/text hybrids are all possible but not primary features. This will be a basic framework where people can experiment with these ideas, even mix and match the cool features made by others.

The Shell Engine will allow "commands" to be supplied via COM objects. A basic set (e.g. DIR, ChDir, running external programs) will be included in the main EXE, but even these are acessed as COM object which you could choose not to use in your specific configuration.

Suppose someone writes a cool suite of ChDir features, with a directory history, popping to previous directory, smart searching, etc. This module would concentrate on this one tightly-coupled group of related commands, and would supply commands named CD, POPDIR, DIRHIST, etc. when that module is loaded. If someone else produces a different, competing, smart directory system, you could use that one instead.

Besides primitive commands, you have "aliases" or "functions" which provide for simple extensions to the primitives. The Empty Shell does not have its own programming language. Instead, it does this by using any available Active-X scripting engine. Each function can be written in whatever language (e.g. JavaScript, VBScript, PerlScript) and they all play together.

Heavier duity is handled by "batch files". While "functions" are resident in the shell, batch files are separate files. The Empty Shell, lacking a programming language of its own, doesn't directly support batch files either. Instead, any program, scripted or compiled, can do. Traditionally, and batch file can do what a "program" can't because the program has its own context and a batch file can manipulate the context of the shell itself. But a program will be able to access the Shell instance that launched it, via COM interfaces. So a Perl script or C++ program could be written to implement something which changes the current directory of the command prompt, for example.


Totally free to anyone who wants to use it. Includes source. Contributions and tinkering is encouraged.

Ideas for a name

ShellFish? (IMO, it's all a fishing expedition...)
Rev. Jeff Russell


You could call it "conch," after the most famous command shell in literature.
JD Hildebrand

Sub-projects and byproducts

This is a large project, and I finally decided to tackle it when I realized I could have something useful with much less than the full amount of work. These parts can be created independantly.

Console Input Prompt

How's this for a "retro" idea: a nice editing blank for a Console (text) window! By making this a reusable component (via COM), I can harness it in any text program, such as simple utilities that write to standard output, Perl scripts, existing batch files, etc.

More interestingly, this is being designed along the same lines of the main project: a central engine with everything else being an extension that fits into the framework. You can add a module that does file-name-completion when you hit the TAB key, for example. The overall idea is the same, but somewhat simpler. So it's great practice for the main program, and we'll be able to use it elsewhere, too.

See the Console Input Prompt page.

GUI Console

Output doesn't have to be plain text. For a great example, look at Mathematica's "notebook" interface. Input and output are individual "cells", which can contain fancy formatting and graphics. When I say "DIR" I'd like to see little icons beside the names... Furthermore, I want each of those listed filenames to be an object that I can then manipulate using the mouse!

And even for plain text, handle full color and formatting abilities, and correctly handle international (Unicode) characters.

Piping-Hot Pipes

If command-line programs (those that write to standard output handles) have their output redirected, the run-time library (part of the program, not the OS) decides to buffer large amounts of output. So if you are sending it down a pipe, and the other end of the pipe contains a program which reads the output and immediatly displays it in a fancy window (other than the regular text Console, that is), you get an annoying delay effect.

What I need is a Named Pipe that looks like a character device rather than a file. This can be done with a device driver, or perhaps by intercepting the program's call to GetFileType when it decided whether or not to use buffering.

Anybody want to jump in on this one?


I'm discussing this project [insert newsgroup name here]

I'm writing this stuff for free; someone else can edit it for free.

Try it out, download the code (when some appears...), get involved!

Page content copyright 1999 by John M. Dlugosz. Home:,