The aim of this ticket is to create a library for console output/input functions, last-error messages display, etc. to be used for all of our internal command-line utilities. Indeed, after close inspection of our code in trunk, I noticed we are duplicating such code, then fixing a bug in it for some utilities while leaving it in the others, or sometimes, writing variations around it so that at the end one utility ends up using a better version of one of such function while the others keep the old version. To avoid that I propose we write such a library for those functions and we use them everywhere instead.
This library allows the win32 console applications to remove any useless dependency to user32.
A native NT version of this library might be developed in the future...
EDIT (21 Oct. 2016):
I plan to architecture the library as follows:
- Core stuff: console streams (CON_STREAM) API (init, ConStreamRead/Write) ; plus Stream utility functions (ConResPuts/Printf, ConMsgPuts/Printf, possibly the more fundamental ConPuts/Printf, or those latter two might go into the Stream API);
- "Console" Screen (CON_SCREEN) management API, wrapping around the streams, being able to give console/terminal screen metrics for win32 consoles and TTY (serial; this is currently in progress into my local copy of cmd.exe ) ; plus Screen utility functions (more functions for console+TTY);
- "Pager" (CON_PAGER) API, using console screens and offering functions for displaying stuff by screen pages (basically, the MORE.COM functionality is there);
- Finally, a "ReadLine" console/TTY API, that either wraps around the ReadConsole function from kernel32 (or use ReadFile for reading from serial ports, for TTYs), together with an auto-completion interface (this would be used by cmd.exe; I am currently modeling it based from cmdinput.c + filecomp.c ; this would also be inspired by the GNU ReadLine library);
- Additional wrapper functions around the console aliases and history APIs, with additional functionalities like saving / restoring aliases & history contents inside files (both cmd.exe and doskey.exe would use those functions).
NOTE: For the latest two new features, see sub-task CORE-12270.
About interdependencies: the core of this library is the CON_STREAM api. Then comes the CON_SCREEN api that uses CON_STREAM.
CON_PAGER is built on top of CON_SCREEN . Finally the "ReadLine" api (NOTE: I want to find another name for this API) would use CON_STREAM and CON_SCREEN functionalities (and maybe CON_PAGER too). The aliases & history api would be something separate, that "ReadLine" could use.
These different parts of the library could be compiled and used separately, respecting those dependencies.
- Most of our current console applications could be transformed to use only the core of the library (CON_STREAM), as I have already done for few of them.
- Console applications that need a concept of screen (amongst those, MORE.COM), would use CON_SCREEN and CON_PAGER.
- DosKey.com (aliases & history management) would use the aliases & history api wrappers.
- CMD.EXE would use everything.