I am trying to sandbox I/O with multiple composite windows and I need to pipe whole driver I/O of sandboxed application.
I know how to pipe stdout stdin stderr on Windows, but I want to Pipe all output input devices availible. In C/C++.
How do I list them?
Can I store the old device pipe end?
It is possible to list them by
DeviceIOControl in win32 API
or by
ioctl in unix-like OSes.
Related
I have 3rd party application, it launch ffmpeg with some parameters and output in named pipe. I have some copies and every copy must subscribe to their own child's (ffmpeg) pipe. But I'm suspect what some copies of app subscribe to neighbor pipe.
How I can see all clients of pipe?
I can PowerShell, C#, a few C++
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.
Is there any way to create a block device via user space in OSX (10.8+), without 3rd party libraries (FUSE, etc)?
I am trying to create a userspace tool. The idea is the user supplies a file to the tool and the tool creates a virtual interface. Whenever the interface is written to, the tool applies an operation to the data and then writes to the original file. Whenever the interface is read from, the tool reads from the original file and applies the inverse operation.
I don't necessarily need a block device. The tool needs to create some kind of virtual interface that can be treated as a file, i.e. it can be opened and saved to by another application.
I looked at the userspace routines of the I/O Kit, but nothing seemed aplicable, as creating a virtual USB/FireWire/MMC/SCSI device seems excessive.
The closest thing I can think of without going into kernel space is a fifo or named pipe - this is essentially a pipe with a file name. Unfortunately, being a pipe, you can't seek, etc. - you can just open the fifo for reading in one process and for writing in another. You create these either with the mkfifo command line utility or the mkfifo() C function.
There are also UNIX domain sockets, which are similar to IP sockets but again are identified by a file name, not a networking construct. These can be read and written from both ends, but again no seeking.
As for actually implementing the ops functions for a vnode (the in-kernel representation of a file in OSX) I believe you do have to drop to the kernel. Note that the I/O kit isn't strictly necessary for creating a block device - if the BSD device nodes are sufficient, and you don't need support for hardware or ejecting volumes etc. you can simply create a node with bdevsw_add(), supplying the ops vector as a parameter. (for an I/O Kit based storage device, the IOMediaBSDClient does this automatically, along with creating the character device with cdevsw_add_with_bdev()) Another, rather more elaborate option is to implement your own file system.
I have
int from_fd[2], to_fd[2];
BOOST_ASSERT(_pipe(from_fd, 256, O_TEXT) != -1);
to redirect standard input/output of a thread to a pipe. It works for a PC. Unfortunately, _pipe doesn't seem to be even defined for Windows Phone. The compiler reports the function can't be found. Is there any other alternative?
I'm trying to forward everything in standard output to a pipe that another thread in the process can read.
Windows RT do not support pipes. Use Windows sockets instead of pipes for IPC.
You can use command lsof to get file descriptors for all running processes, but what I would like to do is to close some of those descriptors without being inside that process. This can be done on Windows, so you can easily unblock some application.
Is there any command or function for that?
I don't know why you are trying to do this, but you should be able to attach to the process using gdb and then call close() on the fd. Example:
In one shell: cat
In another shell:
$pidof cat
7213
$gdb -p 7213
...
lots of output
...
(gdb)
Now you tell gdb to execute close(0):
(gdb) p close(0)
$1 = 0
(gdb) c
Continuing.
Program exited with code 01.
(gdb)
In the first shell I get this output:
cat: -: Bad file descriptor
cat: closing standard input: Bad file descriptor
I don't think so but lsof gives you the PID of the process that has opened the file, so what you can do is entirely kill the process or at least send a signal to let it exit.
In Windows you can use a program to do it because someone wrote a program that inserts a device driver into the running kernel to do it. By the way it can be dangerous to do this, because after you close a handle that a broken application was using, the application doesn't know that the handle was closed, and when the application opens some other unrelated object it doesn't know that the same handle might now refer to some other unrelated object. You really want to kill the broken application as soon as possible.
In Linux surely you can use the same kind of technique. Write a program that inserts a module into the running kernel. Communicate with the module and tell it which handles to close. It will be equally dangerous to do so.
I doubt it. File descriptors are process-local, stdout is 1 to all processes, yet they still reference unique streams of course.
Perhaps more detail would be useful, about the blocking problem you're trying to solve.
There is much less need to do this on Unix than on Windows.
On Windows, most programs tend to "lock" (actually deny sharing) the files they open, so they cannot be read/written/deleted by another program.
On Unix, most of the time this does not happen. File locking on Unix is mostly advisory, and will only block other locking attempts, not normal read/write/delete operations. You can even remove the current directory of a process.
About the only situation this comes up in normal usage in Unix is when trying to umount a filesystem (any reference at all to the mounted filesystem can block the umount).