I'm working on a simple installer that needs to check the presence (accessible in current path) and version level of some dependencies. 32-bit Windows platform is the target. I've already been able to launch the external applications via invoking crt_system. What I'm not sure on is the best way to capture output from those applications for processing inside mine. I'll be launching from CD, so writing to a temp file in the current directory seems to be out. I suppose I could check the environment for TEMP and use that, but I'm not sure if that's appropriate. How do you all handle this situation?
Thanks,
Brian
GetTempPath
Hi Brian - welcome to the forum :U
Dave - K7NL
The WM_COPYDATA (http://msdn.microsoft.com/en-us/library/ms649011%28v=vs.85%29.aspx) message is good for interprocess communication, if you just need to make sure the child process exited properly GetExitCodeProcess along with a waitable object is the usual method.
invoke WaitForSingleObject,[hProcess],[dwTimeOut]
; check to see if the wait was abandoned here
test eax,eax
jnz BADEXIT
invoke GetExitCodeProcess, [hProcess], offset Exitcode
For console applications you can use named pipes (http://msdn.microsoft.com/en-us/library/aa365590%28v=vs.85%29.aspx) to get the output.
you might also want to use GetTempFileName
GetTempPath
http://msdn.microsoft.com/en-us/library/aa364992%28v=vs.85%29.aspx
GetTempFileName
http://msdn.microsoft.com/en-us/library/aa364991%28v=vs.85%29.aspx
i'm not sure what output you are attempting to capture but it's trickier if you are only invoking that child instead of it being your own code. as donkey said, pipes are fantastic for capturing console output. however i believe piping simply redirects a particular IO stream (in this case STDOUT) so you may end up losing the original output..
setwindowshookex will be very ideal if it is a windowed application. you effectively have access each windows message before it hits the target window proc if you so choose. not sure the forum rules allow too much discussion of this though :/
Quote from: Slugsnack on February 10, 2011, 01:49:37 PM
i'm not sure what output you are attempting to capture but it's trickier if you are only invoking that child instead of it being your own code. as donkey said, pipes are fantastic for capturing console output. however i believe piping simply redirects a particular IO stream (in this case STDOUT) so you may end up losing the original output..
setwindowshookex will be very ideal if it is a windowed application. you effectively have access each windows message before it hits the target window proc if you so choose. not sure the forum rules allow too much discussion of this though :/
Just trying to capture STDOUT from an application that's not my code, so I can parse it for versioning information. I'm not real clear on the named pipes concept, but it sounds interesting. So far, I've been attempting to launch the application with a redirect to a Windows temp file since that seems simpler. Unfortunately, I keep running into problems with the Windows API functions I want to use not seeming to be defined in MASM32 (specifically string handling). I also can't seem to get the MASM32 string handling functions to work either (doesn't seem to recognize them). Do I need another include to add string handling support? I'm not having any problems with any of the file handling functions/macros...
**EDIT** I was finally able to use the cat$ macro to do the string manipulation that I needed. The ones that I could not get to work were sz series of library routines and the Windows API lstr / StringCch calls.