Hi,
I'm relatively new to C++ and WinAPI. So far I've managed to create an application, that is using the CreateProcess function and a STARTUPINFO structure to create a new desktop, launch inside that new desktop a new explorer.exe process and switch to it.
Next, because I wanted to be able to switch at any time between these two desktops, at a press of a key (LCTRL in my case), I've made another application that uses the SetWindowsHookEx function to create a global hook for the keyboard.
Because the hook is active only in the calling destkop, in the first app, using CreateProcess, before creating the explorer.exe process and switching to the new desktop, i've launched the executable of the second app twice: once in the current desktop and once in the new one.
Everything is working fine, I'm able to make the switch between desktops at any time, but now I've been asked to do something about the structure of the processes launched, somehow, to make the seconds app code run inside the first one, without creating a new process. Because this is my first post, I can't upload a snippet of the process tree, but the procexp application from live.systernals is showing the following structure:
---FirstApp.exe:
-------------SecondApp.exe (original desktop)
-------------explorer.exe (new desktop)
-------------SecondApp.exe (new desktop)
So basically, my question is: can I make the code of the application that hooks the keyboard run in the same thread as the FirstApp? This implementation, an app that starts these three processes, and the second app that hooks the keyboard, was my idea (I was not requested to do it this way, I was only asked to create a new desktop and switch between them), so I am open to suggestions towards making a better implementation for this problem too.
It could be possible since there is little difference between a DLL and an EXE on Windows, so I think you could try to export the routines from SecondApp and then import them in FirstApp with LoadLibrary.
But IMHO the clean way to do that is to break SecondApp in two pieces : a DLL containing code that actually does the job and an EXE that would be a simple frontend calling routines from the DLL.
That way, it will be trivial (and portable across different versions of Windows and SDK) to call the routines of the DLL from FirstApp.
Related
I'm working on an application (DLL) that logs specific WIN32 calls using Detours. It is injected into a target application that passes the filter. It has to absolutely log every call that the application makes, starting from the first instruction in the application's entry point.
I now am looking for a way to make my application (the one that always runs) inject the DLL as fast as possible, preferably without the target application making any other calls.
Is there any way to achieve this?
You could use the AppInit_DLLs registry key to load a dll into a process. The dll is loaded during DLL_PROCESS_ATTACH of User32.dll. For regular applications this should happen prior to running any application code.
Keep in mind though that AppInit_DLLs should be renamed Deadlock_Or_Crash_Randomly_DLLs.
As far as I know, there's no straightforward way of doing this in Windows.
Your options are:
Hooking the CreateProcess (or lower) function in all processes. When a new process is created, change the arguments to create it as suspended, inject, and resume if needed.
Using a driver.
I am writing an application in Qt which gets executed by a launcher app. How can I detect whether the Qt application was launched by the user or the launcher. Is command line parameters the only way or is there a better way?
Both the Qt app and launcher are written by me.
Lots of ways. A command line parameter could be easily sniffed (by Process Explorer, e.g.), if that's a concern. But a named mutex or some other interprocess handle that can be inherited by the child app would be more difficult to spoof.
I have written a simple vc++ background application. What am trying is like a watchdog service that could monitor if the application is running or not. If the application crashed then the service should start the application
For creating a setup through windows installer am using only the app.exe and app.dll.
Is that possible to create this watchdog - service in the exe itself ?
Unfortunately I have no idea of how to write such a program, does anyone have some example code that would demonstrate this technique please?
if so then how to make the default exe and watchdog exe as a single application to install ?
Your best route would be to create a separate service to act as the watchdog. Technically, it's possible to have the service and the "real application" in the same executable. You can differentiate between the two depending on how the exe has been started, but it will make maintenance quite difficult.
This article might be of interest.
Here - http://yadi.sk/d/EtzBRSMi3FqVH - is my implementation of WatchDog app, working in systray. Do not mind that it's written with Qt - the main functionality is with WinAPI.
This app is watching in processes list for several processes and restarts them if can't find. The second feature is that it monitors all windows in system for suspicious window title (for ex. "'My Great App' causes a system error and will be closed. Send message to developers ?") and, if find, restarts them too
P.S. I didn't i18n it, but I think there will no troubles )
Update: (according to #CodyGray comment)
Here's pastebin's links: WatchDog.cpp and WatchDog.h
Such a watchdog can be set up to, for example, write to a file every minute (or whatever). If the file hasn't been updated in two or more minutes then there is most likely a deadlock in the application and it has to be restarted.
I was hoping somebody here had some insight into what could be causing this problem. I've implemented several COM extensions for Explorer that provide ShellIconOverlays and a ContextMenu, and the overlays work perfectly. The Context Menu works fine when I click on the desktop but when I right click in any explorer instance, I can see the interface being queried in the debugger and an instance of IShellExtInit being generated but the initialize function doesn't get called in the explorer instances, but it is called fine from the desktop and a ContextMenu item is queried immediately after.
Has anybody here seen anything like this before?
If you're debugging a shell extension, chances are that you've had occasions to terminate the running explorer.exe process and start a new one. When you started a new one, was it running with the same integrity level as the original?
Do your Explorer settings say to browse files in a new process? If so, is that process running with the same integrity level as the original?
Also, since you're running a debugger, chances are that you built a debug build. Does explorer.exe sometimes try to load the debug build of your DLL and sometimes try to load the release build of your DLL?
OK, I run into the exact same problem here, and it turns out that the issue has to do with
ThreadingModel = Apartment
Basically, what I think you are experiencing, is that the second thread of explorer.exe (desktop runs in STA thread) uses the default (legacy) ThreadingModel - and expects your COM to implement IMarshal to do IPC. Apartment ThreadingModel allows multiple instances of your IShellExt class to co-exist.
Caveat - If you are using ActiveQt to develop Context Menu Shell Extensions, there are few more tricks to use.
We have a command line application that could benefit from a GUI. We want to add some plotting functionality and have identified a plotting library that uses MFC. Initially we developed a separate app, but we'd rather have the GUI in the same process space.
I was thinking of possibly a GUI in an MFC DLL that could be hosted in the production app AND in a testing app.
The questions are:
What are the steps necessary to add an MFC GUI to a win32 command line app
Is it possible to make a GUI in an MFC DLL and how can it be done? (so that different apps can reuse the same GUI)
EDIT
I should add that this is an unmanaged app (and needs to stay that way - it needs to be highly performant, makes extensive use of templates, boost, custom allocators, internally developed thread serialization, etc)
RESULTS:
Nick D's answer worked great - especially the follow-up link in his comment with the details about a regular MFC DLL.
Note that we will be using Qt for the next iteration. Modifying our build environment and getting used to a a new framework was just too much this time around.
You can call/reuse GUI code in a dll. (I even use Delphi forms in my C++ projects)
A very simple dll example:
// The DLL exports foo() function
void foo()
{
AFX_MANAGE_STATE( AfxGetStaticModuleState() );
CDlgFoo dlg;
dlg.DoModal();
}
In the console program you'll have code like this:
h = ::LoadLibrary( "my.dll" );
::DisableThreadLibraryCalls( h );
pfoo = (foo_type*)::GetProcAddress( h, (const char*)1 );
if ( pfoo ) pfoo();
First, you will have to surrender WinMain().
If you still want to retain the command-line arguments functionality, process command arguments in InitInstance() of your App class.
The straight forward approach would be to add a switch to your program and given a certain value it will launch the gui, otherwise use the command line options. Something like "app.exe -mode=gui". If you don't see this command arg on program launch, fall back to the old command line behavior.
Regarding the DLL, you could write all the UI functionality in a DLL and use it from your "production app" where you have a message loop running and a WinMain. But what's the point? If it's for testing purposes why not just separate the presentation from the logic and test the logic alone. How do you intend to test the UI in your test app anyway? Simulate button clicks?