I want to create a generic logging application (Windows), which shall be able to execute an arbitrary executable as a child process and log the complete standard streams of a specific to a file (stdin, stdout, stderr).
Further, this logging application shall be acting like a kind of a "Man-in-the-Middle" application completely transparent, so that for user who is calling either the original executable or the wrapper logging application, there is not difference.
This functionality is somehow similar to the UNIX command line tool "tee", but as far as I found out, this tool is unfortunately not be able to log also the stdin (only stdout and stderr are supported). In addition, I want to log some more information e.g. who was the calling parent process, timestamps...
I want to use this especially for the command prompt: "cmd.exe" and rename the original and replace it with my own "cmd.exe" to automatically get a history file of all entered (stdin) commands, with its outputs (stdout, stderr).
Does someone have a good idea how to get this easily realized, perhaps with C# and pipes?
Best Regards,
Andreas
A simple version would indeed use pipes. In a native win32 app you would create some inheritable pipes and set them and the STARTF_USESTDHANDLES flag in the STARTUPINFO struct passed to CreateProcess. There is example code for this on MSDN.
You cannot however use this to replace cmd.exe because cmd.exe also uses the special Windows console API in interactive mode to implement features like the F7 history "dialog". You could take a look at some of the free terminal replacements like Console2 to see how they do it.
Related
I have a long script that runs many commands. These commands print text to the screen via standard output and standard error. I want to add some logic at the end of the script that takes all text printed to the screen (standard out or standard error) and saves it to a text file.
However, I do not want to redirect standard output and standard error to a text file because I want the user of the script to be able to see all the text getting printed to the screen in real time as the script runs. Indeed, at some points in the script, some of the commands may ask for user input. Instead, I want to be able to "GetScreenContentsText()" and then write the output of this to the screen.
Is there a way to do this in PowerShell?
As Mathias points out in a comment, the Start-Transcript cmdlet (followed by a matching Stop-Transcript call) is generally the right tool for creating session transcripts.
However, Start-Transcript doesn't capture everything and has general problems and limitations (written as of PowerShell [Core] 7.0):
Interactive prompts (Read-Host, [Console]::ReadLine()) are not transcribed - you'll see neither the prompt string nor what the user typed.
Even output can situationally be missing from the transcript, as discussed in GitHub issue #10994.
Error messages can be transcribed twice and using transcription can change the script's behavior - see GitHub issue #4645.
VT sequences (ANSI escape codes) are not captured, so any coloring shown in the console is lost.
The former of the two linked GitHub issues prompted the following response from the PowerShell committee, which reflects the status quo as of PowerShell 7.0 (emphasis added):
#PowerShell/powershell-committee reviewed this, we believe a complete solution for transcription (like the unix `script command) [is called for;] would love to see the community build a new cmdlet (published to PSGallery) that uses ptty or on Windows grabbing the screen buffer, but the ask is out of scope for the current transcription framework.
Speaking of the script utility on Unix-like platforms: while it is a superior alternative to Start-Transcript in general there (though not designed to be used from inside scripts), PowerShell's PSReadLine module, which is also used for prompting users via Read-Host, doesn't play nice with it.
As for a possible workaround: Unfortunately, it sounds like you'll have to manually duplicate prompt strings and user input in your script's output in order for them to be captured in the transcript - if modifying the script is an option.
this is not yet another "I need a console in my GUI app" that has been discussed quite frequently. My situation differs from that.
I have a Windows GUI application, that is run from a command line. Now if you pass wrong parameters to this application, I do not want a popup to appear stating the possible switches, but I want that printed into the console that spawned my process.
I got that far that I can print into the console (call to AttachConsole(...) for parent process) but the problem is my application is not "blocking". As soon as I start it, the command prompt returns, and all output is written into this window (see attached image for illustration).
I played around a bit, created a console app, ran it, and see there, it "blocks", the prompt only re-appears after the app has terminated. Switching my GUI app to /SUBSYSTEM:Console causes strange errors (MSVCRTD.lib(crtexe.obj) : error LNK2019: nonresolved external Symbol "_main" in function "___tmainCRTStartup".)
I have seen the pipe approach with an ".exe" and a ".com" file approach from MSDEV but I find it horrible. Is there a way to solve this prettier?
This is not behaviour that you can change by modifying your application (aside from re-labelling it as already discussed). The command interpreter looks at the subsystem that an executable is labelled with, and decides whether to wait for the application to terminate accordingly. If the executable is labelled as having a GUI, then the command interpreter doesn't wait for it to terminate.
In some command interpreters this is configurable. In JP Software's TCC/LE, for example, one can configure the command interpreter to always wait for applications to terminate, even GUI ones. In Microsoft's CMD, this is not configurable behaviour, however. The Microsoft answer is to use the START command with the /WAIT option.
Once again: This is not the behaviour of your application. There is, apart from relabelling as a TUI program, no programmatic way involving your code to change this.
Maybe write a console-based wrapper app that checks the parameters, prints the error message on bad parameters, and calls/starts up the actual program when the parameters are correct?
Folks,
Is it possible to create a bat file that launches an executable and waits for a pre-determined string in the standard output. When that string is found, the batch file will exit (the exe can continue running). How could this be accomplished?
In short, no.
Note that originally MS-DOS was an operating system in which Windows ran. Now it is an application that simulates the earlier OS. The way to solve your would possibly involve using an application called from within MS-DOS, that will perform this kind of logic (i.e. IF(file_is_present_with_string)THEN {...}) in the MS-DOS command library.
Powershell is a powerful scripting language allowing you to perform many operations previously unavailable in MS-DOS, such as take the output from one MS-DOS command (e.g. ipconfig /all) and reformat it into a different layout, possibly using it as another command's input parameters (e.g. select a value from ipconfig and use it in another command). Although it supports MS-DOS command execution, it does so through the use of CMDLETs (pronouned command-let) which is a self-contained application designed to run inside Powershell. There are many other CMDLETs out there that might be able to help solve your problem.
When a console application is started from another console application, how does console ownership work?
I see four possibilities:
The second application inherits the console from the first application for its lifetime, with the console returning to the original owner on exit.
Each application has its own console. Windows then somehow merges the content of the two into what the "console" visible to the user
The second application get a handle to the console that belongs to the first application.
The console is placed into shared memory and both applications have equal "ownership"
It's quite possible that I missed something and none of these four options adequately describe what Windows does with its consoles.
If the answer is close to option 4. My follow-up question is which of the two processes is responsible for managing the window? (Handling graphical updates when the screen needs to be refreshed / redrawn, etc)
A concrete example: Run CMD. Then, using CMD, run [console application]. The [console application] will write to what appears to be the same console window that CMD was using.
None of your four possibilities is actually the case, and the answer to your follow-on question, "Which of the two processes is responsible for managing the window?", is that neither process is responsible. TUI programs don't have to know anything about windows at all, and, under the covers, aren't necessarily even plumbed in to the GUI.
Consoles are objects, accessed via handles just like files, directories, pipes, processes, and threads. A single process doesn't "own" a console via its handle to it any more than a process "owns" any file that it has an open handle to. Handles to consoles are inherited by child processes from their parents in the same way that all other (inheritable) handles are. Your TUI application, spawned by CMD, simply inherits the standard handles that CMD said that it should inherit, when it called CreateProcess() — which are usually going to be CMD's standard input, output, and error (unless the command-line told CMD to use some other handles as the child's standard input, output, and error).
Consoles aren't dependent upon CMD. They exist as long as there are (a) any open handles to the console's input or output buffers or (b) any processes otherwise "attached" to the console. So in your example you could kill CMD, but only when you terminated the child process too would the console actually be destroyed.
The process that is in charge of displaying the GUI windows in which consoles are presented is, in Windows NT prior to version 6.1, CSRSS, the Client-Server Runtime SubSystem. The window handling code is in WINSRV.DLL, which contains the "console server" that — under the covers — Win32 programs performing console I/O make LPC calls to. In Windows NT 6.1, this functionality, for reasons covered by Raymond Chen, moved out of CSRSS into a less-privileged process that CSRSS spawns.
My guess is somewhere between 3 and 4. The console is a self-standing object, which has standard input, output and error streams. These streams are attached to the first process that uses the console. Subsequent processes can also inherit these streams if not redirected (e.g. running a command with redirect to a file.)
Normally there is no contention, since parent processes usually wait for their child process to complete, and asynchronous processes typically start their own console (e.g. try "start cmd" in a command prompt) or redirect standard output.
However, there is nothing to stop both processes writing to the output stream at the same time - the streams are shared. This can be a problem when using some runtime libraries since writes to standard output/error may not be immediately flushed, leading to mixed garbled output. In general, having to processes actively writing to the same output stream is usually not a good idea, unless you take measures to co-ordinate their output through concurrency primitives like Mutexes, Events and the like.
The way the SDK talks about it strongly resembles 1. It is an option with CreateProcess, described as follows:
CREATE_NEW_CONSOLE
The new process has a new console, instead of inheriting its parent's console (the default). For more information, see Creation of a Console.
Output however happens through handles, you'd get one with GetStdHandle(). Passing STD_OUTPUT_HANDLE returns the console handle, assuming output isn't redirected. Actual output is done through WriteFile() or WriteConsole/Output(). If both processes keep writing output to the handle then their output will be randomly intermingled. This is otherwise indistinguishable from what would happen when two programs write to the same file handle.
Logically, there's a screen buffer associated with a console. You can tinker with it with SetConsoleScreenBufferXxx(). From that point of view you could call it shared memory. The actual implementation is undiscoverable, handles abstract them away, like any Win32 API. It is sure to have changed considerably in Vista with the new conhost.exe process.
CMD 'owns' the console. When it creates a process for an app, that app inherits handles to the console. It can read and write those. When the process goes away, CMD continues ownership.
Note: I'm not entirely sure that 'ownership' is the right word here. Windows will close the Console when CMD exits, but that may be a simple setting.
Each application will run in it's own AppDomain. Each AppDomain should be running it's own console.
Ah, you're right. I was thinking about running executables within a process and forgot they start their own process - I didn't drill down far enough.
I think it's spelled out fairly well in the documentation.
Background: We develop win32 applications, and use the "Thompson Toolkit" on windows to give us a unix-like shell that we use as our command-line.
We have a GUI program (with a WinMain and message loop) that we want to write to the console, but printf and so on don't work, even when we launch the program from the console. How can we write to the console from a GUI program? We need to print text there so that an automated build system can display error messages and so on.
Thanks.
In short, you need to attach a console. For details and ready to use code, see http://www.codeproject.com/KB/dialog/ConsoleAdapter.aspx.
Basicly you have to create a console by your self with AllocConsole, AttachConsole. After that you have to get standard handles with GetStdHandle and "associates a C run-time file descriptor with an existing operating-system file handle" with help of _open_osfhandle.
The returned handle can be used to overwrite crt stdin and stdout. After that all crt methods like printf should work.
Instead of logging to the console, log to a file and then track the file with a separate gui application. This keeps the console uncluttered and gives you a more persistent record of your log, which occasionally is extremely useful. There are various libraries which will do most of this for you, or you can keep it simple and just do it yourself.
somewhere in the Visual Studio Project Settings you can switch on having a console, assuming you are using VS. (Can't say where because I currently don't have it)