cmdEX.exe - augmenting the existing CMD.EXE

[Stu Carnie]

Hi all,

I have been working on some 'extensions' to the existing Windows NT
command shell / console API (specifically 2000, XP and 2003).

It is different from replacement shells, like Take Command or WinOne,
in that it will actually augment the existing shell (and STDIN / OUT /
ERR) by 'injecting' itself into the console process.

My motive for extending the shell has been
1. Replacing the very limited editing features of the existing console
input APIs in Win32.
2. Not wanting to engineer another shell
3. Wanting all existing console apps to inherit this enhanced editing
functionality, such as FTP, NETSH, TELNET, or the many others out
there.
4. Persisting the history across sessions!
5. Providing standard windows editing features like CUT (SHIFT-DEL) /
COPY (CTRL-INS) / PASTE (SHIFT-INS)

Let me explain further.

A number of you are aware of the existing shell functions like F7 to
bring up the history list, F8 to search the history list and tab-key
directory / file completion. This not only works with cmd.exe, but
other command line tools like FTP, NETSH and TELNET. In fact any
console app that uses the ReadConsole kernel32 API has this
functionality.

You will even see this in .Net if you use the Console.ReadLine.

I have been writing a DLL, that when injected into a CUI (console)
process, replaces certain kernel32 APIs to enhance their current
features, such as the ReadConsole API.

I already have a working prototype that is stable and successfully
injects itself into the console process. It will also attach to all
spawned CUI process from this process.

I'm curious how many would be interested in such an enhancement. I'm
not planning on charging for it, but perhaps 'donation ware'..

V1.0 will be a public version, but will not support user enhancements.
V2.0 is planned to allow 3rd parties to customize their own shortcuts,
allow context sensitive user defined command completion (like zsh),
..Net plugins and many others.

This is not like MONAD / msh. msh is a new command shell, whereas
cmdEX sits under the shell to enhance the interactivity.

I will be creating a home page for it soon and providing a forum for
discussion in the next 2 to 3 weeks, and I will post back when it is
available.

Cheers,

Stu

 

[Walter Briscoe]

In message <[email protected]> of Mon, 23 Aug 2004
15:02:50 in microsoft.public.win2000.cmdprompt.admin, Stu Carnie

A number of you are aware of the existing shell functions like F7 to
bring up the history list, F8 to search the history list and tab-key
directory / file completion. This not only works with cmd.exe, but
other command line tools like FTP, NETSH and TELNET. In fact any
console app that uses the ReadConsole kernel32 API has this
functionality.

I don't think I knew that but use none of them interactively.

[snip]

I'm curious how many would be interested in such an enhancement. I'm
not planning on charging for it, but perhaps 'donation ware'..

I am sorry to see any reference to money.

V1.0 will be a public version, but will not support user enhancements.

I infer from that that you do not propose to release source code.
It makes the product much less attractive to some.

V2.0 is planned to allow 3rd parties to customize their own shortcuts,
allow context sensitive user defined command completion (like zsh),
.Net plugins and many others.

Immediately, I can only think of two applications of such a facility:
1) I have some commands which require DOS filenames (c:\foo\bar) and
some which require UNIX (c:/foo/bar). It would be nice to have something
which would take either and select the appropriate format.
2) ^<newline> handling. e.g. The following does one command but puts two
entries in the DOSKEY command history:
C:\) dir ^
More? /ad
3) Make that 3. It would be nice to be able to preload that history.

 

[Stuart Carnie]

In message <[email protected]> of Mon, 23 Aug 2004
15:02:50 in microsoft.public.win2000.cmdprompt.admin, Stu Carnie

A number of you are aware of the existing shell functions like F7 to
bring up the history list, F8 to search the history list and tab-key
directory / file completion. This not only works with cmd.exe, but
other command line tools like FTP, NETSH and TELNET. In fact any
console app that uses the ReadConsole kernel32 API has this
functionality.

I don't think I knew that but use none of them interactively.

[snip]

I'm curious how many would be interested in such an enhancement. I'm
not planning on charging for it, but perhaps 'donation ware'..

I am sorry to see any reference to money.

I'm sorry you feel that way. I don't expect anything - but if someone feels
they'd like to donate, it would certainly not go unappreciated.

I infer from that that you do not propose to release source code.
It makes the product much less attractive to some.

There is no suggestion I won't release the source code. I simply have a
vision for the product that it will support extensions via 'plugins', and
initially this won't be available in the 1.0 release. I am even considering
sourceforge. I have the infrastructure in place to hook the kernel32
functions, and have basic editing.

Immediately, I can only think of two applications of such a facility:
1) I have some commands which require DOS filenames (c:\foo\bar) and
some which require UNIX (c:/foo/bar). It would be nice to have something
which would take either and select the appropriate format.
2) ^<newline> handling. e.g. The following does one command but puts two
entries in the DOSKEY command history:
C:\) dir ^
More? /ad
3) Make that 3. It would be nice to be able to preload that history.

This will all be available. The history will also be persistent between
commands too, so CMD.EXE, FTP.EXE and TELNET.EXE will each have their own
command histories, just like today, but more powerful.

One of the major intentions is to provide more interactivity via shortcut
keys, just like the many other shells out there.

Enhanced globbing will also be a feature - but sensitive to context.

There is a LOT we can do with this framework to enhance the console
experience.

 

[Stuart Carnie]

I am going to open source it.

I have submitted a new project request to SourceForge, and will upload the
first alpha build when it is ready.

Project will be titled consoleEX.

Cheers,

Stu

 

[Bill Stewart]

I am going to open source it.

I have submitted a new project request to SourceForge, and will
upload the first alpha build when it is ready.

Project will be titled consoleEX.

Hi Stu,

Your project sounds really interesting. Thanks for posting the info.

Regards,

Bill

 

[Ndi]

Compiler? Version?

As a developer, I was thinking about a DLL export or import that would
allow people with different compilers/version (say ... Delphi?) to add code
to them.

Perhaps an addon system would be great. Like the user adding his own dll
to a list (ini file?) and publishing events to be called (Init, KeyPressed,
LineChanged, etc). That would allow people (like me to add their own
functionality (which would spare you the trouble of me bugging you to "bind
me this to that". STDCall undecorated functions would be just perfect ...

I currently use a service in background that binds keys to applications
(and globally) and I use that to make my day (like Shift+PgUp and PgDn for
console scroll, a Unix feature that is *really* useful). However, enhanced
functions from outside the shell are a complete pain since it takes some 100
lines just to get the window, buffer, scroll positions and such. You can
imagine what Shift+arrows selecting can do to code... Also, you need to do
that only when in command input mode, otherwise you grab critical input from
DOS and console applications.

 

[Stuart Carnie]

There is going to be a myriad of ways of implementing the plugins...

I have been reviewing the code, and I expect I'll provide some COM
interfaces to get to the edit buffer. This will make it easy for code
written in Delphi, C++ or .Net to interact with the environment.

I envisage providing a simple interface to an 'device' that abstracts it
from the underlying I/O device for drawing simple popup boxes, drawing text,
receiving input, etc. The reason for this is I have also hooked all the
console output APIs, so we can redirect this anywhere, in real time.
As an example, by providing your own implementation of this abstracted
device, the console could be redirected to a Unicode graphical shell.

There will be a few different 'layers' of plugins..

Shortcut - your plugin will bind to a key combination to perform some
action in the console. This could be as simple as inserting some text to as
complex as you want to get.

Completion plugin - (typically bound to the TAB key) this plugin will
provide extended command line completion for the current context. Not
entirely sure of the implementation details yet, but I see this operating
two ways.
Firstly, your plugin registers itself against a command, such as the
ROUTE command. Lets go through a use case

Now if you type ROUTE on the command line and press TAB, your plugin
will cycle through the keywords 'PRINT, DELETE, ADD or CHANGE'. Much more
intelligent than cycling through the current directories or files. zsh can
do this. Now, we stop on CHANGE and press the TAB key again. A standard
'list' text dialog pops above or below your command line, and highlights the
first IP in the ROUTE table, and as you continue to press the tab, it
changes the selection. How cool is that?

I want to come up with a generic way for plugins to be able to be
given the current context, and a way of returning the appropriate options..
There is so much that could be done with this...

NET START is another good example - imagine getting a list of the
services available and selecting the one you wish to start.. Very
productive..

The other option is the plugin registers for ALL completions, and
must parse the commandline itself to determine context and the appropriate
input.. Much more involved.

This is not to be confused with the extensions ability to do basic
completion. Like zsh, you can register simple context sensitive completion,
where it just selects from a list of available switches. I expect to add
this also, but it will not be able to discover dynamic content.. ...unless
we allow you to script it in some way to parse out stdout

Anyhow, enough for now

It will probably take a couple of weeks to get to the basic shell, but it
has a lot of potential I think.. As long as Longhorn has the same kernel32
APIs (which is almost guaranteed for backwards compatibility), this should
work with msh / Monad too!

Cheers,

Stu

 

[David Candy]

Number 5 is attractive. Also changing the default taskbar button menu (or System menu) to put close where it in on normal programs. I am really sick closing windows but finding myself in Properties and two dialogs to get out.

 

[Ndi]

I have been reviewing the code, and I expect I'll provide some COM

interfaces to get to the edit buffer. This will make it easy for code
written in Delphi, C++ or .Net to interact with the environment.

I hate COM. But then again we all need to face our fears, right?

Now if you type ROUTE on the command line and press TAB, your plugin
will cycle through the keywords 'PRINT, DELETE, ADD or CHANGE'. Much more
intelligent than cycling through the current directories or files. zsh can
do this. Now, we stop on CHANGE and press the TAB key again. A standard
'list' text dialog pops above or below your command line, and highlights the
first IP in the ROUTE table, and as you continue to press the tab, it
changes the selection. How cool is that?

As cool as implementing a command parameters list for each case. Since
there is no way of getting available commands or parameters, someone needs
to implement completion for each and every extended command.

Also, for those who have many options (like devcon), It's easier to type
than to tab it.

I guess it could help people who issue the same command over and over
again ...

NET START is another good example - imagine getting a list of the
services available and selecting the one you wish to start.. Very
productive..

Someone needs to actually have a NET plugin, or, even worse, a NET START
plugin. But one could do something like implement c:\options.txt as tab
options and then NET start > c:\options. That way TAB would complete started
services.

I currently use an interfaced version (it has this GUI that hogs stdIN,
stdOut and stdErr) but there's this limitation on using -say- Telnet where
you type at certain positions on the screen. Having a GUI means always
making input line-by-line... But certain thigs ar cooler, Ctrl+` popping in
and then out so you'd get

Ctrl+`
ping localhost
Ctrl+`

 

[Stuart Carnie]

Actually, zsh has a generic plugin to just complete based on context, no
special logic. I plan on including the same thing. It will just be an XML
file, containing all the command line options.

If you want to get fancier, one can write a plugin to enhance the command
list.

Cheers,

Stu

 

[Ndi]

Then, internal commands should be the manifest of cmd.exe. You could write
it yourself (it's not all that large, there are some 20 commands) and
distribute as an example.

-sigh- MORE help to write.