Re: [MSH] MSH Not So Great For Interactive Users

On Mon, 23 Jan 2006 16:17:16 -0000, Jon Forrest <forrest@xxxxxxxxxxxxxxx> wrote:

Thomas Lee wrote:

First, remember that the way MSH is hosted limits MS's flexability. There is some tab completion, but the limitations of the MSH host for V1 leads partly to what you suggest. 

Several people have mentioned this, but I don't understand
what they mean. I can understand that MSH doesn't have the
kinds of features I was talking about because the developers
just haven't gotten around to adding them, but I don't
see any technical obstacles to adding them just because
MSH is a console application or because of "the way
MSH is hosted".

Any app in windows that opens a console (a tty) and uses the high level IO functions gets basic commandline editing features. They don't have to implement it themselves. The functionality is implemented within the Win32 API itself, not in an add on library or in the application. The keystrokes involved date back to the earliest versions of DOS in some cases, but primarily aim for compatibility with DOSKEY, which dates from DOS 5.0 iirc.

There is nothing to stop an app implementing vi, emacs or CUA keystrokes, and in fact some (such as *sh ports) do. http://www.coldie.net/project/jamsh is a MSH host that uses the GNU readline library and is probably a lot closer to what you are looking for - MSH with vi or emacs keystrokes.

The Monad Team had to make a choice, integrate and ship in Exchange 12 with the current cmdline UI, or improve the cmdline UI and hope for another ship vehicle. I think they made the right choice.

I think we're all hoping V2 will include an improved cmdline experience, both for cmdline editing and also output - and other posts from team members indicate these are areas they intend to address after V1.

Its my personal hope that when they do improve things for V2, that they will actually improve the Console (tty) itself, rather than just the MSH application. That way other console applications can benefit from the improvements.

Keystroke schemes, 32-bit colour and alpha support, an additional output compositer (cell buffer rather than char buffer), intellisense; these could all be implemented at the Win32 Console API level.
Cmd, IronPython, netsh, etc, would all benefit somewhat without doing anything extra.
I think MSH is still best placed to make use of a new API, after all, its designed to support an advanced UI, rather than having one grafted onto an existing toolchain.

The biggest problem of course, is that the new Console API would ideally be in Vista, but the boat has presumeably sailed on that one. Maybe the Vista Server/Vista Client SP1/XP SP3 round of releases? I'd hate to have to wait for Blackcomb/Vienna.

If extending the Console API is ruled out, my second preference would be a library third parties can use in their apps like setargv.obj was for wildcard expansion.

Just my 2c,
Neville.
.

Loading