[yourapostasy]

Somewhat sadly, it doesn't look like businesses are commissioning such character terminal interfaces any longer. Certainly not in sufficient volumes to support the few boutique shops that published and maintained text window libraries that some developers would use to insulate themselves from the insanity of supporting multiple terminal types on different systems. As far as I can tell from some Google searches, Vermont Creative Software's Vermont Views and Oakland Group, Inc.'s C-Scape are both no longer sold or even have a web presence. If it is true both went out of business, it would be a pity that such codebases are languishing in bit rot hell and could possibly disappear from the historical record. There were and are no comparable open source text window libraries with the polish these products had.

[cturner]

Putty is fine though.

Something that would be useful but which I don't think exists at the moment is a multiplexor. Like GNU/screen, but properly sandboxed. When the user logs in they get a menu program running on "tab 0". This program would spawn perspectives on new tabs.

[cturner]

(Follow-up post after re-read.)

Actually, maybe these things have features that I wouldn't know of being only a curses person. I'd be interested to know more if you wrote up a blog post. Email cratuki at the google mail server.

[yourapostasy]

I'm prone to Yegge-length expositions in a blog, so the HN format might be better. These libraries could be thought of kind of like extensions to curses. In some cases, they actually depended on curses, in others, they did the work curses did and then went beyond that. You could typically draw into a defined buffer that represented a window, then have that window blasted onto the terminal replete with the character ASCII art that decorated the window borders without having to work out the arithmetic drudgery to put the right spaces and characters to draw the borders.

More elaborate libraries let you overlap the windows and would optimally redraw them when you moved the windows. They simply let you avoid having to roll your own text user interface starting from curses and building from there. Open source equivalents never approached the comprehensiveness or polish of these commercial libraries, though the open source ones are pretty good. Now that the commercial libraries appear to have dropped off the face of the earth, the open source ones seem to be all that is left. CDK [1] and NDK++ [2] on Unix and DFLAT [3] on DOS are examples of the open source libraries. I just felt the commercial libraries were interesting pieces of software history that should be preserved.

I personally feel that the kind of high-speed manual data entry optimization that these libraries facilitated is likely on its way out with advances in machine learning and the self-service customer culture of ecommerce. Certainly nothing prevents someone from using a standard web browser to present a user interface that responds entirely from keypresses, should the need for a highly optimized data entry-oriented Javascript library become necessary (something I've looked for but haven't found either for sale or open source). You would need to come up with a way to buffer up all the keypresses locally on the browser and ensure they all make it to the server, but it's doable.

If someone really had a burning desire to have some kind of in-house application presented through a character terminal interface via PuTTY in today's world, then they can still fall back to curses I suppose. Though I sometimes wonder if it would be faster to just write something in Emacs Lisp and autostart that when the user logs in.

[1] http://invisible-island.net/cdk/cdk.html

[2] http://ndk-xx.sourceforge.net/

[3] http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/deve...