OT: Windows console history?

  • This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn more.
#1
Maybe I should have known this, or did know it at some time in the distant past, but ...

If, in the same Windows console (TCC, CMD, PS), I run FTP.EXE ... close FTP.EXE ... run FTP.EXE again, the commands entered in the first FTP.EXE session are remembered in the second and can be recalled with Up/Down. The same goes for PowerShell and interactive NSLOOKUP.EXE sessions. So it seems that any given Windows console (regardless of who started it) has an app-specific history. Is this documented ... customizable? Does anything in the Win32 API relate to it?
 

Charles Dye

Super Moderator
Staff member
May 20, 2008
3,427
40
Albuquerque, NM
prospero.unm.edu
#2
Check out the properties for the shortcut you use to start your console session, specifically the "Options" tab. GetConsoleHistoryInfo() and SetConsoleHistoryInfo() are probably relevant too.

TCC maintains its own separate history, of course.
 
#3
Yeah, I saw those. I had never paid much attention to them. The two functions you mentioned are only for set-up. Do you know an app actually uses the mechanism ... or how TCC manages not to use it?
 

Charles Dye

Super Moderator
Staff member
May 20, 2008
3,427
40
Albuquerque, NM
prospero.unm.edu
#4
Don't really know, but I think I can guess. That console history mechanism probably only applies to apps which use ReadFile() to get lines from the console. TCC doesn't; it reads individual keystrokes and assembles lines itself.
 
#5
Don't really know, but I think I can guess. That console history mechanism probably only applies to apps which use ReadFile() to get lines from the console. TCC doesn't; it reads individual keystrokes and assembles lines itself.
NSLOOKUP doesn't import ReadFile. FTP does, but I'll bet only for reading scripts. I was thinking (maybe) data gets into the history via gets/wgets and (again maybe) it's those functions which are processing Up/Down. I'd like to know more about it.
 
#6
Some of it is spelled out here: http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/doskey.mspx?mfr=true
I think it applies to the "doskey" mechanism itself rather than to DOSKEY.EXE.

Certain character-based, interactive programs, such as program debuggers or file transfer programs (FTP), automatically use Doskey.exe. To use Doskey.exe, a program must be a console process and use buffered input. Program key assignments override doskey key assignments. For example, if the program uses the F7 key for some function, you cannot get a doskey command history in a pop-up window.

With Doskey.exe you can maintain a command history for each program you start, repeat and edit previous commands at the program's prompt, and start doskey macros created for the program. If you exit and then restart a program from the same Command Prompt window, the command history from the previous program session is available.
 
#8
NSLOOKUP doesn't import ReadFile. FTP does, but I'll bet only for reading scripts. I was thinking (maybe) data gets into the history via gets/wgets and (again maybe) it's those functions which are processing Up/Down. I'd like to know more about it.
You were correct. I tried a few ways of getting a string from the keyboard in a console app ... wgets, _wgets_s, ReadFile, ReadConsole. The all put the string in the console's history (to be available to the next instance). No doubt those, and others, ultimately call ReadFile. It's no surprise I didn't see NSLOOKUP importing ReadFile; it uses fgets and is dynamically with MSVCRT.DLL.