I have one Win32 console application which will be independent EXE and I have front-end designed in MFC.
I want to get the results of the Win32 application to be shown on my GUI. I searched a lot and found some techniques:
Named pipe
DDE
Shared memory
Are any of these an appropriate solution to my problem? Does anyone know of any other solution(s) that might be easier than those I mentioned?
If the output of the console exe is machine parsable, you can use CreateProcess() with pipes for standard input and output which you then parse and display in your UI.
You send also message from one application to another, it's quite simple. Look into WM_COPYDATA
http://msdn.microsoft.com/en-us/library/ms649011%28v=vs.85%29.aspx
Related
I'd like to write a debugging/diagnostic tool which can call Windbg functions to examine a dump file, instead of writing a windbg extension. Is this possible and any references?
Thanks a lot.
Rather than WinDbg, you can use the Debugging API which is implemented in dbghelp.dll. It's documented on MSDN. That reference documentation is rather dry, but it should give you an idea of the capabilities of the API. For example, MiniDumpReadDumpStream is the gateway to examining dump files.
In addition to the existing answers, WinDBG is a GUI front end for the DbgEng API. You can use this API to write either WinDBG extensions or other standalone applications. The WinDBG SDK ships with samples of both, an example standalone application can be found in the \sdk\samples\dumpstk subdirectory of your WinDBG install.
For more information, I wrote an article about DbgEng to write extensions here:
http://www.osronline.com/custom.cfm?name=articlePrint.cfm&id=559
Most of that will also apply for how you write a standalone application as it mostly focuses on the programming pattern of the DbgEng interface.
here are some links that use dbgeng interfaces to make standalone executables.
a short summary of the process is to
call DebugCreate() to create a client
call QueryInterFace()
and call one of its methods
http://www.woodmann.com/forum/entry.php?252-Dbgeng-based-handles-(PART-2-)
http://www.woodmann.com/forum/entry.php?246-A-Simple-Dbgeng-Based-User-Mode-Debugger
http://www.woodmann.com/forum/entry.php?248-DbgEng-Based-Debugger-(PART2)
http://www.woodmann.com/forum/entry.php?249-DbgEng-Based-Debugger-(PART2-Contd-)
http://www.woodmann.com/forum/entry.php?250-DbgEng-based-Kernel-Debugger
http://www.woodmann.com/forum/entry.php?251-Dbgeng-based-Handles
You could make commands using powershell or to the command line version of WinDbg which is cdb and then parse the output from cdb which you interpret.
This would be similar notion to piping the output from cdb to your app.
There is post about using powershell in this manner: http://rkeithhill.wordpress.com/2006/08/14/minidump-crash-analysis-with-powershell/
It should be straightforward to pump commands to cdb and interpret the output for specific commands.
Python integrated with dbgeng:
pykd.codeplex.com
This project may be use as a demo for such integration
I am new in in Visual Studio Win32 (C++) Applications
In java where I work, logging is easy using log4j for instance.
How is the logging done in a Win32 app?
I have seen some code using macros to write to files.
Am I responsible to create some logging mechanism?
Is there a standard way to log in win32?
Thanks
Use the Event Log API to write to Windows Event Log
http://msdn.microsoft.com/en-us/library/aa385772(v=vs.85).aspx
Another way is using log4net since you have experience of log4j, there are very similar.
"Windows application" doesn't mean much of anything, Java apps can also run on Windows. There's log4net to adding logging to a .NET application. Log4cxx to do so for an app written in C++. Exact same approach as log4j. The project's home page is here.
It depends on who is going to be using your software's logging facility:
The Windows Event Log API is best if you are writing a service or "system" type task that needs to be supported by an IT support department. Support tools for Windows support remote access of system event logs to create system health alerts and so on.
Other than that, Windows does not have a convenient Logging API. So you need to roll-your own if the system event log is inappropriate.
For developers / debugging purposes theres OutputDebugString that will emit text to your debuggers "Output" window.
It is convenient when writing GUI apps, to make the debug build a console application, so that a console window is displayed in addition to the GUI. printf() can display messages to the console.
Otherwise, some OSS projects I built on windows did include a variant of log4c that had been ported to windows. So log4c can be coerced into working on windows if you really need it.
I obviously don't think it would work as it is. Its more like, does Windows internal architecture allows for some third party SW to integrate in between? From what I read about Compiz, I believe it creates its own window, and somehow mixes graphics from System X to its own. But it still has to catch events like EXIT button and so on.
Does Windows even allow this? Let 3rd program to scan for input of another window? And more, catching output of GUI and replace it?
Does Windows even allow this? Let 3rd
program to scan for input of another
window? And more, catching output of
GUI and replace it? Thanks.
It is certainly possible. See WindowBlinds for an example. Just note that Windows "officially" does not support this, applications like WindowBlinds use API hooking, subclassing etc. to perform their deeds.
Windows does not natively allow it - it has its own compositor framework built in called DWM that does much of the same internal functionality as Compiz. However, glitzy graphics that are systemwide are reserved for the OS to perform, sadly. As other people mention, doing this as a 3rd-party app is going to be really hacky and difficult.
API Hooking:
http://www.codeproject.com/KB/system/hooksys.aspx
Also, look at:
http://yodm-3d.en.uptodown.com/
A free 'Compiz' for Windows.
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 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.