Uploaded image for project: 'Core ReactOS'
  1. Core ReactOS
  2. CORE-10504

Create a library for console output/input functions, last-error messages display, etc. to be used for all of our internal command-line utilities



    • New Feature
    • Resolution: Fixed
    • Major
    • 0.4.3
    • Applications
    • None


      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.

      Planned usages:

      • 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.


        Issue Links



              hbelusca hbelusca
              hbelusca hbelusca
              1 Vote for this issue
              3 Start watching this issue