Several months ago, I implemented a named pipe server in a GUI using the example code from MSDN -> https://msdn.microsoft.com/en-us/library/bb546085.
The named pipe server seems to work well, and I've used it to control my GUI with other programs written in various Visual Studio languages.
Today I have been trying to interact with the named pipe server with a Python script. On the web, it was simple to find sample python code, using the ctypes library, that opened up the named pipe with the windll.kernel32.CreateFileA() method and wrote ASCII bytes to it with the windll.kernel32.WriteFile() method.
The problem is that the MSDN example uses a format where the first two bytes written to/received from the pipe represent the size of a string that is to follow in the pipe. While I can write strings to the pipe from Python with no problem, I can't seem to pass any binary data into the WriteFile() method.
Questions about ways to solve this problem:
1. Is there any way to write raw bytes of binary data to WriteFile()? Is there another method I could be calling to handle this?
2. Is there any way for me to encode the binary number into a string as raw bytes? For example, if I knew the bytes I wanted to send ahead of time (0x1234 for example) then I could just send create_string_buffer("\x12\x34"). The bytes have to be determined at runtime, however, and I haven't found a way to create a string out of the raw bytes.
Related
I'm having a bit of a problem. I have been working on making a printer driver for a laser my company owns. The laser came with proprietary software that allows it to be controlled by an API. I thought it would be a good idea to allow any program to "print" to the laser. So far, I have made my own customized Postscript printer using Redmon. My custom application so far can handle the output from Redmon, capture it via standard input, and post it to a file. The next step in the process is to have ghostscript turn the file into a BMP. I can manually use Ghostscript to convert the file I created with my application and make a bmp. I would like to avoid temporary files wherever possible, though, and want to direct the input from Redmon into Ghostscript directly. I followed Microsoft example http://msdn.microsoft.com/en-us/library/windows/desktop/ms682499%28v=vs.85%29.aspx. I altered it to take the input I captured earlier that I put into a string and apply it to the buffer instead of reading into the buffer and writing out. Ghostscipt does, on every 5th try or so, capture some of the data, but usually only the first 4096 bytes. Other times it gets nothing. The problem is that Ghostscript can only read once from stdin (upon first executing), expecting the data to be there already. If I follow Microsoft's example, it will only work if, by some chance, I write all that data before Ghostscript executes. I tried to reverse the process and write the data before spawning the process, but it fails completely.
Any suggestions? Thank you.
I have been trying to figure out how installers work and how they bundle everything into one executable file and how to create my own. I have tried using a hex editor called HxD which allows you to export the current hex-dump of a file into a .c source file with an array containing the hex dump that looks like the below.
Excited, I tried to write the file using some simple C++ code:
ofstream newbin("test.exe", ios::binary);
newbin << hex << rawData;
newbin.close();
... and then tried to run it.
After some further research it turns out that my little program is only writing the MZ. header which PE files use in windows and excluding the rest of the code. The executable that is created has a hex-dump of 4D 5A 90 or in ASCII MZ.. Is this a fault in my coding? Why won't it write the hex data? Would I need to use some lower-level writing tool or assembly? If so, are there any C/C++ libraries that allow me to write at such a level? Thanks!
rawData is a char* and is interpreted as a character string by the streaming operator, which is terminated by the first 0x00 byte it encounters.
For binary writing, you are best off using the
ostream& write(const char*, int);
method, leading to
newbin.write(rawData, 65536);
Assuming 65536 is the actual used size of the buffer.
Hope this helps :)
A better approach to storing binary data is to use resources. Menus, icons, bitmaps are stored in resources.
You can create a custom resource and use FindResource function, LoadResource, and then LockResource to map it into memory.
Then you can do whatever you want with the data, and of course write it to a file.
Installers usually use something like this rather than embedding lots binary data in the source code. This approach has other advantages:
You don't have to re-convert your data into source code and then recomplile the whole application when the data changes. Only resources have to be recompiled and re-linked.
The resources are not loaded into memory until use the functions above, what means until you need them. Thus the application loads faster into the memory. (Resource data are actually mapped into address space right from the file.)
With your current approach, all the data are loaded into memory, therefore your application requires more memory.
Additionally, you should better use specialized tools for creating installers.
There is a program in java (Minecraft) and for the server part of it, it opens up in a terminal and prompts the user for commands, as well as give feedback for loading progress and other stuff. How can I make a c++ "wrapper" to automatically send commands to the terminal, and receive the response?
I could automate commands such as say and kick with GUI elements. I am running a mac with OSX Lion.
It presumably reads and writes stdin/stdout. You should look up executing a binary (in this case java.exe) in c++ and how to read and write to it. Alternatively, you could write a wrapper in Java that gives you control without having to parse the text output.
The answer to this question would depend on the operating system as different systems use different approach how to deal with the standard input and output channels. On a UNIX system you'd create a pipe(2) (or two if you want to capture standard output and standard error separately), fork(2) the "server", use close(2) and dup(2) to put the various file descriptors into place, and then execve(2) the actual program. After this you can read/write to various descriptors.
I have a c++ program (very complicated, and lengthy both in code and execution time).
Once in a while this program stops and calls a user-specified shell script.
Before calling the script, my program creates a .out file with current data. I call the script via system() command. The script then reads the .out file, and creates its own script.out file and exits.
Then the system() function call ends, and my program reads and parses the script.out file.
Question: is there a better way to execute communication between my c++ program and a random shell script?
My intent is to have full communication between the two. Script could virtually "ask" the program "What data do you have right now?" and the program would reply with some strict convention. Then the script could say "Add this data...", or "delete all your previous data" etc.etc.
The reason I need this is because the shell script tells the program to modify its data. The exact data that was put in the original .out file. So after the modification is done -- the actual data held by the program does not correspond to the data written in the .out file.
Thanks!
P.S.
I swear I've searched around, but everyone suggests an intermediate file.
There are certainly ways to do that without intermediate files. The most common approach is to use command line arguments for input, and pipes for standard output; others also use pipes for input. The most straight-forward alternative to system then is to use popen.
On a unix-like system? Perhaps pipe (2) will work for you?
From the man page (Mac OS X 10.5 version):
SYNOPSIS
#include <unistd.h>
int pipe(int fildes[2]);
DESCRIPTION
The pipe() function creates a pipe (an object that allows unidirectional
data flow) and allocates a pair of file descriptors. The first descrip-
tor connects to the read end of the pipe; the second connects to the
write end.
You will, of course, have to follow the creation of the pipes with a fork and exec pair. Probably this has already been answered in detail, and now you know what to search on...
It's been a while since I did this, but:
In the main process, before forking the sub-process you call pipe twice. Now you have two pipes and control both ends of both of them.
You fork.
The main process will read from one pipe and write from the other. It doesn't matter which is which, but you need to be clear about this.
The child process will call one of the exec family of function to replace it's image with that of the shell you want to run but first you will use dup2 to replace it's standard input and output with the ends of the two pipes (again, this is where you need to be clear about which pipe is which).
At his point you have two processes, the main process can send things into one pipe ad they will be received on the standard input of the script, and anything the script writes to it's standard output will be sent up the other pipe to the controlling process. So they take turns, just like interacting with the shell.
You can use pipes or (maybe more convenient) sockets - for example frontends to gdb, or expect do that. It would require changes to your shell scripts, and switching from system() to more low-level fork() and exec().
It's rather complicated so please, be more specific about your environment and what you need to clarify.
You are asking the question on Interprocess Communication (IPC).
There are a lot of ways to do that. You can do a simply search and Internet will return you most answers.
If I am not wrong, Google chrome uses a technique called Named Pipe.
Anyway, I think the most "portable way" is probably a file. But if you know you are working on which operating system, you can definitely use most of the IPC techniques.
I have a project that I thought was going to be relatively easy, but is turning out to be more of a pain that I had hoped. First, most of the code I'm interacting with is legacy code that I don't have control over, so I can't do big paradigm changes.
Here's a simplified explanation of what I need to do: Say I have a large number of simple programs that read from stdin and write to stdout. (These I can't touch). Basically, input to stdin is a command like "Set temperature to 100" or something like that. And the output is an event "Temperature has been set to 100" or "Temperature has fallen below setpoint".
What I'd like to do is write an application that can start a bunch of these simple programs, watch for events and then send commands to them as necessary. My initial plan was to something like popen, but I need a bidrectional popen to get both read and write pipes. I hacked something together that I call popen2 where I pass it the command to run and two FILE* that get filled with the read and write stream. Then all I need to do is write a simple loop that reads from each of the stdouts from each of the processes, does the logic that it needs and then writes commands back to the proper process.
Here's some pseudocode
FILE *p1read, *p1write;
FILE *p2read, *p2write;
FILE *p3read, *p3write;
//start each command, attach to stdin and stdout
popen2("process1",&p1read,&p1write);
popen2("process2",&p2read,&p2write);
popen2("process3",&p3read,&p3write);
while (1)
{
//read status from each process
char status1[1024];
char status2[1024];
char status3[1024];
fread(status1,1024,p1read);
fread(status2,1024,p2read);
fread(status3,1024,p3read);
char command1[1024];
char command2[1024];
char command3[1024];
//do some logic here
//write command back to each process
fwrite(command1,p1write);
fwrite(command2,p2write);
fwrite(command3,p3write);
}
The real program is more complicated where it peeks in the stream to see if anything is waiting, if not, it will skip that process, likewise if it doesn't need to send a command to a certain process it doesn't. But this code gives the basic idea.
Now this works great on my UNIX box and even pretty good on a Windows XP box with cygwin. However, now I need to get it to work on Win32 natively.
The hard part is that my popen2 uses fork() and execl() to start the process and assign the streams to stdin and stdout of the child processes. Is there a clean way I can do this in windows? Basically, I'd like to create a popen2 that works in windows the same way as my unix version. This way the only windows specific code would be in that function and I could get away with everything else working the same way.
Any Ideas?
Thanks!
On Windows, you invoke CreatePipe first (similar to pipe(2)), then CreateProcess. The trick here is that CreateProcess has a parameter where you can pass stdin, stdout, stderr of the newly-created process.
Notice that when you use stdio, you need to do fdopen to create the file object afterwards, which expects file numbers. In the Microsoft CRT, file numbers are different from OS file handles. So to return the other end of CreatePipe to the caller, you first need _open_osfhandle to get a CRT file number, and then fdopen on that.
If you want to see working code, check out _PyPopen in
http://svn.python.org/view/python/trunk/Modules/posixmodule.c?view=markup
I think you've made a very good start to your problem by using the popen2() function to abstract away the cross-platform issues. I was expecting to come and suggest 'sockets', but I'm sure that's not relevant after reading the question. You could use sockets instead of pipes - it would be hidden in the popen2() function.
I am 99% sure you can implement the required functionality on Windows, using Windows APIs. What I cannot do is point you to the right functions reliably. However, you should be aware the Microsoft has most of the POSIX-like API calls available, but the name is prefixed with '_'. There are also native API calls that achieve the effects of fork and exec.
Your comments suggest that you are aware of issues with availability of data and possible deadlocks - be cautious.