I read about standard streams. My understanding is old fashioned programs that don't have GUI need some kind of user interface, too. So Operating System provide each of them with a console window, and the console window's out/input/err stream was mapped to the program's standard input/output/error stream. And thus these programs are called console application. And this mappings couldn't be modified by the programmer.
I am wondering, if my understanding above is correct, does GUI program have these standard streams also? I don't think it's necessary since GUI itself is a good user interface.
I'm quoting the bottom of the article you linked to:
Graphical user interfaces (GUIs)
rarely make use of the standard
streams.
Some GUI programs, primarily on Unix,
still write debug information to
standard error.
Others may take files to operate from
standard in, for example many Unix
media players do so.
Therefore from the above quotes, you can see that yes they do, although they're rarely used.
"And this mappings couldn't be
modified by the programmer."
This is incorrect - certainly on UNIX they can be - not sure about Windows. For example, you can close the standard output stream and redirect it to a file stream to get the output written to a file.
This varies a lot based on your OS. Some will create a console if you run a "command line" app, some will connect the standard streams to the same streams as the process that started the program had.
You typically can change the stdout/in/err streams, it's very common to connect them to something else than the console in which they were run, like a pipe or file.
GUI programs typically have the stdout/err/in streams as well.
GUI programs rarly use those streams, perhaps except for debugging printfs during development.
GUI programs might redirect those streams to /dev/null or something similar that just discards data written to it.
Related
Hi according to this post, unbuffer connects to a command via a pseudo-terminal (pty), which makes the system treat it as an interactive process, therefore not using any stdout buffering.
I would like to use this function on Windows. May I know what is the equivalent of unbuffer program on Windows? Thanks.
I spent some time on this and succeeded. I found this blog during research, and decided to return and provide my solution to save the next guy some time. I'm responding as a guest with a false email so I won't be interacting, but no further information should be required.
On Jul 18 '12 at 19:41 Harry Johnston wrote:
"In principle, if you know how much data to expect, you could use the console API functions to create a console for the application to write to, and then read the output from the console. But you can't do that from Java, you would need to write a C application to do it for you."
Thing is, there is already a utility that does this. It's written for a slightly different use, but it can be coxed into providing the desired result. Its intended purpose is to enable a windows console app to interact with a Linux style tty terminal. It does this by running a hidden console and accesses the console buffer directly. If you tried to use it – you'd fail. I got lucky and discovered that there are undocumented switches for this utility which will allow it to provide simple unbuffered output. Without the switches it fails with the error – the output is not a tty – when trying to pipe output.
The utility is called winpty. You can get it here:
https://github.com/rprichard/winpty/releases
The undocumented switches are mentioned here:
https://github.com/rprichard/winpty/issues/103
I’m using the MSYS2 version. You’ll need the msys-2.0.dll to use it.
Simply run:
winpty.exe -Xallow-non-tty -Xplain your_program.exe | receive_unbuffered_output.exe
-Xallow-non-tty , will allow piped output
-Xplain , will remove the added Linux terminal escape codes (or whatever they’re called)
Required files are:
winpty.exe
winpty-agent.exe
winpty.dll
msys-2.0.dll
winpty-debugserver.exe – Not needed
The behaviour you're describing is typical of applications using run-time libraries for I/O. By default, most runtime libraries check to see whether the handle is a character mode device such as a console, and if so, they don't do any buffering. (Ideally the run-time library would treat a pipe in the same way as a console, but it seems that most don't.)
I'm not aware of any sensible way to trick such an application into thinking it is writing to a console when it is actually writing to a pipe.
Addendum: seven years later, Windows finally supports pseudoconsoles. If you are running on Windows 10 v1809 or later, this new API should solve your problem.
On older versions of Windows, if you know how much data to expect, you could in principle use the console API functions to create a console for the application to write to, and then read the output from the console. But you can't do that from Java, you would need to write a C application to do it for you.
Similarly, in principle it should presumably be possible to write a device driver equivalent to a Unix pseudo-terminal, one that acts like a pipe but reports itself to be a character-mode device. But writing device drivers requires specific expertise, and they have to be digitally signed, so unless there is an existing product out there this approach isn't likely to be feasible.
Disclaimer: My answer only deals with executables compiled using MSVC.
The buffering policy is coded inside Microsoft C Runtime (CRT) Library. You can learn the details here. This article suggests using console handles and manipulate console buffers to receive unbuffered output.
However, there's an undocumented feature inside Microsoft C Runtime to inherit file handles with some internal flags directly from its parent process using lpReserved2 and cbReserved2 fields of STARTUPINFO structure. You can find the details in the crt source code provided by Microsoft Visual Studio. Or search for something like posfhnd on GitHub.
We can exploit this undocumented feature to provide a pipe handle and specify FOPEN | FDEV flags to the child process, to fool the child process treat that pipe handle the same way as a FILE_TYPE_CHAR handle.
I have a working Python3 script to demonstrate this method.
It is a trivial matter of redirecting a console program's standard input/output, but what about if the program uses advanced console functions? Like outputting colored text, throwing the cursor around and manipulating the console buffer directly? Can that also be captured and redirected to my own program for processing?
Note: I'm talking about the scenario where my app (not necessarily a console app) runs a console app and redirects its input/output to itself.
Note 2: In the end I'll want C# code, but for now let's stick to bare Win32 API and C or C++. I don't think it will be possible without PInvoke anyway, so let's get the basic principle down first (if at all possible).
Unlike Linux, all color IO is not going to be captured with simple redirecting, so the only way to capture it is to hook on WinAPI calls (i.e. you will need to intercept system calls), which require administrative privileges, fragile and suspicious.
I am trying to port my screensaver from windows to mac and one of its features was reacting on system sound output. On windows it was easy using Direct Sound, but I can't find any example of capturing sound output on mac. Is it possible even possible without writing something like kernel extension? Using flash it is also very easy — it even gives computeSpectrum method to get raw data or even fft transformed data.
All programs that I have already found use Soundflower or their own kernel extension. But I don't think that asking to install separate program or using kernel extension is a good way.
One thing you can do, considering that Soundflower is open source, is take a look at how they did it. You can't copy & paste GPL code, but you can surely study the techniques used and create your own solution (point you in the right direction).
You won't find Apple being very helpful here. Sound capturing, in this manner, can be used for all kinds of nefarious purposes. I'm not even sure if Core Audio lets you do this without hacks. In any case, you have a working implementation of what you're trying to accomplish. I'd take advantage of it.
I'm not on my Mac right now, but I'm pretty sure that Quartz Composer has a patch for just this thing. Depending on what language you're writing your screen saver in, it may be fairly easy for you to port your code into a QC patch. Well... it probably won't be easy, but it may be doable.
Simple question here (though perhaps not such a simple answer):
Is it possible to specify a path for an (existing) named pipe that can be used by programs as if they were opening on a normal file?
According to this MSDN page, name pipes on the local computer can be referrenced using the following path syntax: \\.\pipe\PipeName, yet I'm having no luck using this from standard Windows programs.
As a side point, if anyone has any suggestions for interfacing with programs that are only capable of using the file-system in a more efficient manner than physical I/O (e.g. named pipes), I would be glad to take them.
It would only work if the programs are using the Win32 API CreateFile() function to open the files.
I am in the middle of solving a problem which requires me to do the following in my 64-bit Cocoa application:
Spawn a 32-bit Cocoa helper tool (command line tool) from within my application. This helper will open a file (a quicktime movie to be precise) and access information about that file using 32-bit only APIs (Quicktime-C APIs)
The data gathered from the 32-bit process needs to be passed back to the 64-bit application.
The 64-bit app should wait until the 32-bit process completes before continuing
There are many ways to accomplish this in Cocoa, but from what I gather these are two approaches I could take.
Option 1: NSTask with Pipes
Use NSTask to spawn the 32-bit process
Redirect the NSTasks stdoutput to a pipe, and read data from that pipe in the 64-bit process.
Parse the data from the pipe, which will involve converting strings from stdout into data (ints, floats, strings, etc.)
Option 2: NSTask with NSDistributedNotificationCenter
Use NSTask to spawn the 32-bit process
When data is ready in the 32-bit process, send an NSNotification to the Distributed notification center, and inlude a dictionary in the event with all of the pertinent data.
In the 64-bit app subscribe to the same NSNotification
So my question for StackOverflowers' is, which option is "better"?
Which is a better practice?
Which is more efficient?
I'm leaning towards Option 2 because is seems like there will be less code involved. If these two approaches aren't great, is there a better way to do this?
You say that the subprocess will be an application. Don't use NSTask for that—it confuses Launch Services. (If you mean it's a helper tool, such that a curious expert user could run it from the command line, then NSTask is OK.)
The DNC will work either way, but if the subprocess really is an application, don't use NSTask+NSPipe—use distributed objects.
NSDistributedNotificationCenter will work okay, but keep in mind your application isn't "guaranteed" to receive distributed notifications by the OS. I haven't actually seen this in practice, but it's something to keep in mind when you're choosing a technology.
The other option you didn't mention is distributed objects. Distributed objects is made exactly for this purpose. It handles either serializing or setting up proxy objects that work between processes or over a network. The documentation is a bit lacking, it doesn't support some newer parts of Cocoa like bindings, it's not exactly easy to use, but I still prefer it when I'm working two processes that work together in a complex way.