I recently stumbled across something called pipe (all small letters) and fork (also all small letters). Apparently pipe "is a method of connecting the standard output of one process to the standard input of another". What I do not understand is what does standard input output of a process mean here. I already know that functions can call other functions and use the values returned by them so what is special about pipe, why do we need pipes? I have never come across these in my C/C++ books, what mystery is this? A simple way to communicate between two applications (I am not using the word process here) is that one application creates a file, calls another application and let it open this file and process its data and create a new result file and than terminate itself. Than the original application can continue processing and read from the result file and delete the file it created first. This is a simple way for two applications to communicate, I think that in the age of .Net framworks and complex operating systems, this must be even easier right?
Also, what is a fork? is it something specific to C++? I remember reading somewhere on internet that by using fork we can open another application from out C++ application. However, I do not know of the limitations and implications of this approach and any drawbacks that it may have. Why do we need fork? What does it do?
I do not wish that anyone has to write several pages of information. I just wish to understand what these things are, what do they do, why do we need them, and how come my C/C++ book did not cover these two?
These are unix system calls. They are not part of the C++ language or standard libraries, but are specific to unix-like operating systems.
fork creates a new process, and pipe creates a one-way communication channel. pipe and fork are often combined and used for inter-process communication.
Related
I'm implementing a COM shell-extension interface that may be instantiated by different applications. For example, File Explorer might call it during folder navigation, and then my own application might directly call it from an .exe. I was hoping to share some simple and temporary state information across all instances of the interface (perhaps just a string or a vector of strings). I was hoping it would be like a static member variable, except accessible across all applications.
So I was wondering if this is possible, and if so, how to go about doing it. I've been reading about Windows inter-process communications, and it seems like having simple clipboard functionality might suffice, such that each instance could read or write information to a known memory location. But I wouldn't want to use the clipboard specifically, since that's supposed to be called by the user, and I wouldn't want to interfere with the standard copy-and-paste. Also, I'd like to avoid writing to a file because I think that would slow things down too much. Is there another type of IPC that's suited to sharing a variable across all COM instances? Thanks in advance.
There are many methods to choose. Refer to this. You can try to implement the function of simple clipboard. And other methods refering to this.
This is question is about the general architecture, I do not require anyone to solve this little hack for me, although I won't be angry if someone does ;).
Suppose I have a web app that spawns standard unix processes (like Travis CI). While it seems simple enough to pick the stdout of such a process, I'd rather like to make the whole thing asynchronous (like e.g. Travis). So I thought of passing the whole output through a websocket and into some web-based terminal emulator.
However, the only emulators I could find were fully interactive (i.e. they allow for user input and thus have some custom server-side component). My goal would be to have a piece of client side code and just stuff the output into it.
So what is necessary to create a websocket, attach it to the stdout of a server-side process (preferably emulating a tty for colors and fancyness) and display a terminal client-side? I recon there are control codes to distinguish a tty from a text file and these control codes need to be encoded on the websocket somehow, but is there some documentation on this?
I have done this for .NET applications. I think this may be worth for you as example.
I have a small .NET project named NLog.Contrib.Targets.WebSocketServer that is a log watcher with WebSocket and AngularJS. Basically, it broadcasts the data that is being logged through a WebSocket, and there is an AngularJS directive that shows the data. How to highlight data is more a presentation stuff, so it will depend on the framework you use. Basically, this component attaches to whatever .NET application that uses NLog as logging framework, so you can try to find some extensibility point in Travis yourself and attach your thing there.
About attaching to stdout, I have a proof of concept about a web interactive CMD.exe also in .NET, although you can disregard the stdin part. If you use Mono, probably is the same thing than in Windows.
I think this is very similar to what you are looking for. If you have a more specific question let me know.
You can use STDWebsocket in order to achieve this. For examples, simply read the index.html script tag. It should solve your problem (or anyone that go through this question)
Is it possible to write to a 3rd output stream? My situation is that I have an a number of scripts that execute various commands, remotely across a grid of machines. Those commands result in stdout and stderr. I would however like to feedback progress to the central controlling machine, without cluttering it with the interlaced stdout and stderr of the various machines in the grid. I was thinking that if it is possible to write to a 3rd output stream, that I could use it for specific status events from the grid, that the controlling script can report on, meanwhile stdout and stderr can remain redirected to log files for debugging should something go wrong.
For what it is worth I will probably be implementing this in ruby, and the machines involved will be a mixture of windows and unix machines.
I don't think how you architect your logging is constrained by the language you're using, but log4r and syslog come to mind if you're set on ruby. If you need a truly multiplatform solution maybe you might consider some kind of message bus or ØMQ although this will incur an extra layer of complexity.
It sounds like common logfiles for info and errors that all your scripts write to might be the simplest solution. Seeing as you're managing lots of small processes rather than one big monolithic app, using a tool like Splunk might help to aggregate and analyse all the logged events.
Can anyone explain how does one program hook into and modify behavior of other programs in Windows?
How is it even possible? Don't windows programs protect themselves from other programs going into their memory, etc? (I don't know the internals how it works so I just said "into their memory" -- I bet it's more complex than that.)
Also does modern Windows like Windows 7 still allow it?
Thanks, Boda Cydo
There are several different ways to hook into and modify the behavior of other programs.
For example, you can directly write to another program's memory (WriteProcessMemory) or you can inject a thread into another program's memory (CreateRemoteThread). This presumes you have some rights to control that other program.
You can also inject a window hook via SetWindowsHookEx. This presumes you are running in the user's session at the same or higher integrity level of the program you are injecting into.
This is still allowed for several reasons. Without a way to modify behavior of other programs you would not be able to implement a debugger. Windows hooks are used by testing programs, accessibility programs, programs that change the look and feel of Windows, etc.
Imagine an application that saves data to file X.txt
you can grab the x.txt contents, and attempt to find a difference in the saved x.txt against the current x.txt, once it changes you can have an event fire knowing that program X modified its x.txt file.
You can do this on a lower level but the concept remains the same, (monitor something for change).
Is there anything similar on Windows what would achieve the same as the InputManager on OS X?
If you are looking to inject code into processes (which is what Input Managers are most commonly used for), the Windows equivalents are:
AppInit_DLLs to automatically load your DLL into new processes,
CreateRemoteThread to start a new thread in a particular existing process, and
SetWindowsHookEx to allow the capture of window events (keyboard, mouse, window creating, drawing, etc).
All of these methods require a DLL which will be injected into the remote process. C would be the best language to write such a DLL in as such a DLL needs to be quite light weight as to not bog the system down. RPC methods such as named pipes can be used to communicate to a master process should this be required.
Googling for these three APIs will turn up general sample code for these methods.
I'm pretty sure Windows has an API that developers can use to create new kinds of text input systems. I gather there are a wide variety of text input systems in use in non-Roman-derived markets, many of which are provided by third parties.
It's unclear if that's what you were really asking about, though, because you just assumed everyone knows what you would want to use an Input Manager for on Mac OS X.
If you want to create a new type of input method, ask how to do that.
If you want to get your own code running inside other applications, ask how to do that.
Don't just assume people can read your mind when asking questions, and don't assume that they have the same experience that you do and will recognize all the same platform-specific terminology.