Wish to terminate main.exe after execute DLL (C++) - c++

I run my main.exe on a mobile device which executes my test.dll. Now after the dll has startet I need to wm_destroy the main.exe for exchange while the dll is still running. I'm pretty new to this field and I see it's against all logic. But maybe there is a way to change the main.exe while dll is running.
Thx in advance!

When a DLL is loaded it's linked into the address space of the main executable. It doesn't and isn't supposed to exist independently. DLLs don't "run"/"execute" independently.
What you want to do is not what DLLs for. You probably want to spawn a new, independent process, and from there send the WM_DESTROY to the parent process.

What purpose this can even serve? If dll is running by itself, it's an .exe and should have own WinMain, not just DllMain. Actually they have same format, both .dll and .exe are PEXE files and can have exports. It's a bit tricky to get address of exported function from running module that isn't child process, but it's how certain profiler tools work, including VS analyzer.
In Windows there is utility which sole purpose is to run a dll, rundll32, which you can spawn as child process, but it requires elevated rights.

Related

Is it possible on windows to prevent other applications hooking in system DLLs

I am desperately looking for a cause of crashes in my Qt-based Application.
After some observation I've detected, that alone opening a QFileDialog, which is standard windows file dialog, even without selecting any file, causes the application to crash after some minutes. It doesn't happen on all machines.
I've opened my application in dependency walker and the profiling revealed, that opening of file dialog loads tons of DLLs, which I don't need in my application - all the tools which hooked in windows shell. Among the others - TortoiseSVN, which even makes depends to freeze.
Is it possible in an application context to prevent other DLLs like codecs or shell-hooks to be loaded?
Is it at least possible to create a QFileDialog without loading all the tool hooked in windows?
This is definitely possible, but it's not trivial. What you have to do is insert an API hook on LoadLibrary (and/or the Native API equivalent.) When your hook is called, you can examine the DLL filename and decide whether you want to pass it along to the real LoadLibrary or return an error.
A couple places to find more info on API hooks:
A tutorial on CodeProject
Microsoft Detours is Microsoft's library for API hooking.
Now all of that said, for your specific situation you may be better off just changing your TortoiseSVN settings. If you set the include/exclude paths in Tortoise to only look at directories on your computer that contain SVN repos, I bet this freeze will go away as long as you avoid those directories.

Getting a program only to run with certain dlls in the directory

When, for instance, I create a program and compile it with MinGW if I delete the environment variable I need to put the dll in the directory for it to work
ie. libgcc_s_dw2-1.dll
without it the program will not even start.
When developing with QT I noticed I needed another dll in the directory, it was QtCored4.dll, I was wondering how the program knows that the dll is missing?
Also is there anyway to add something like this to a program,
like a define statement or something?
I need an answer that can work with C++ :)
That is taken care by the operating system -- since your program uses functions from the DLL, it is automatically loaded when your program starts, and if the DLL is missing, you will get an error. You can read more about this process on MSDN: Load-Time Dynamic Linking.
when developing with QT I noticed I needed another dll in the directory, it was QtCored4.dll, I was wondering how the program knows that the dll is missing
You can also try to load the DLL yourself at runtime, and handle failure gracefully. See LoadLibrary and GetProcAddress.

DLL registering and Unregistering

I have created a context menu dll (C++ COM DLL) to show iconoverlays (using IShellIconOverlayIdentifier interface). To show the iconoverlays initially I have restarted the explorer. If the system restarts, to display the icon overlays, I need to manually register the dll and restart the explorer once again.
Is there any way to register my com dll before explorer starts. ??
Also, if I uninstall my application the DLL can not be removed. To remove the dll, I need to stop the explorer and other applications (For eg, thunderbird, visual studio) which use my dll, then unregister the dll. Then only I am able to delete the Dll. Is this correct.. Or any thing else I can do.
Thanks in Advance.
I wonder why you have to register your DLL on every restart of your system.
On the other hand it is quite normal that you have to restart explorer.exe and related programs to let the changes - especially done by shell extensions - take effect.
Further, the beahivour you encounter upon deletion is the standard procedure one has to go through when you want to delete your shell extension DLL.
You may want to use self-registrating DLLs. They include information required to store themselves in the operating system's registry and will automatically store themselves on your machine and become accessible when needed.
A detailed explanation can be found here : Self-Registration (COM)

Recompile MFC DLL while client exe is running

Is it possible to recompile an MFC DLL while its "client" executable is running, and have the executable detect and pick up the new changes? If it's possible, is it foolish? Being able to recompile the DLL without restarting the exe would save some time in my coding workflow. I am using Visual Studio 2008, code is written in native C++/MFC. My code changes are entirely contained in the DLL, not the EXE.
Thanks!
Unfortunately, unless the executable has support for hot-swapping DLLs, you can't do it. The standard DLL loading mechanism in Windows will load it either at the start of the process or at first use of a function exported by the DLL and will not watch the file for changes in order to reload it. Also, depending on how the DLL is loaded, the file might be locked for changes.
You will have to stop your client executable before recompiling.
Yes, it's possible. You'll need to make sure the executable explicitly loads your DLL (via LoadLibrary). If your executable implicitly loads your DLL you'll have the issues that Franci described.
To update the library while the executable is running:
Define some convention for staging the new version of the DLL. It could be in a separate folder, or with a different file name/extension.
Have a means of checking for a new version of the DLL. This could be in response to some specific gesture in the user interface, or you could monitor the directory for changes from a background thread.
When you see a new version, unload the old version (FreeLibrary), then delete it and move the new version to the desired location and reload it (LoadLibrary).
If your DLL implements any COM objects, let me know and I'll give you some additional tips.

Plugin DLLs that depend on other DLLs

I am writing a DLL to plug into another (3rd party) application. The DLL will need to depend on another set of DLLs (for license reasons I cannot link statically).
I would like my DLL to be "xcopy-deployable" to any directory. I would also like not to require adding this directory to the path.
If I just build the DLL the usual way, Windows will refuse to load the DLL, since it cannot find the DLLs next to the current process.
Are there any good options for helping Windows locate the DLL?
To answer some questions:
The DLL is written in C++.
The extra DLLs are QT-dlls.
I would like to place the extra DLLs in the same folder as my plugin DLL. I can get the name of that folder from GetModuleFileName.
The application is Firefox, the DLL is a PKCS#11 security module.
The application loads the DLL using the full path to the DLL (the user supplies it when installing the plugin).
Requiring that the DLLs be placed in System32 or next to the application would work, but it is a bit messy and could cause problems with uninstallers.
LoadLibrary and GetProcAddress would of course work, but is not really feasible in my case. I am using hundreds, if not thousands, of methods in the other DLLs. I really need to use the import-libraries.
I had thought about using delay-loaded dlls combined with SetDllDirectory in DllMain. Have anyone tried anything like this?
I can think of 3 ways.
put the dlls in the same folder as your application (you cannot do this?)
Use runtime linking. LoadLibrary() and GetProcAddress()
Use a manifest http://msdn.microsoft.com/en-us/library/aa374182(VS.85).aspx
But if the dll isn't in the same folder as the .exe, how are you going to know where it is? forget Windows not knowing, how do you know?
you can specify the path of dll as the parameter of LoadLibrary().
Another option is to modify the PATH variable. Have a batch file for launching the main app, and set the PATH=%PATH%;%~dp0. This ensures a minimal footprint, with no additional traces left in the system after running.