This may be too broad a question, but I have a DLL that contains a UI. It is currently invoked by an EXE. What steps would I do to try and invoke the UI within the DLL? Or put another way, how would I go about teasing out the code that would invoke the UI as it happens in the EXE?
Looks like you have access to source for both dll and executable that uses it. so what you are doing is writing a host for that dll from scratch.
Create a MFC application from VS project templates (make it the same kind as main executable, dialog, single document, multiple document, etc).
Look at what function dll exports, also look at its headers and best of all -- documentation.
Search source code of main exe and find the places the dll functions are called.
Figure out what is being done and why.
Narrow down scenarios you want to reproduce (initialize dll, show basic UI and tear down)
Start reproducing that code in your example app.
Copy the dll call, see what parameters it takes, see how those are initialized, etc.
Fix errors as they come up.
Related
This question is a bit similar to this one, except for a little twist :
Can I modify the side-by-side assembly search sequence?
We have a couple different softwares, made with different languages, that talk to each other when they run. To achieve this we made .NET COM objects that we load using Registration-Free COM Activation. This works well. Some of the languages we use can't load COMs, so we made a C++ Wrapper DLL that uses ACTCTX to activate the COMs from their embeded manifests. Also working well.
But now, we have a case where our C++ Wrapper is loaded by code that is ran by an application that isn't ours (let's call it the runtime) that is located somewhere and our application is located somewhere else. We'd rather deploy our COM objects at the same place as application is deployed rather than next to the runtime application.
Not that it is important as the concept remains the same, but the runner is FourJ's Genero (fgl.exe) and the code that calls our C++ wrapper are in .42m files. The runner (fgl.exe) is installed with Genero, by default in Program Files\FourJs and our applications are in another directory with our company's name ie : Program Files\MyCompany
This is similar to what you'd get with Java. Runtime at one place, applcation somewhere else.
So in our case, our .42m loads the C++ Wrapper properly, the wrappers activates the COM (located in the same directory as our .42m and the wrapper) properly but once we try to instanciate an object, we get a "80070002" file not found error.
I've read
Assembly Searching Sequence and noticed the described behavior using Process Monitor.
So what happens is, since ultimately it's fgl.exe that is running, the Windows Side-By-Side loader looks into :
C:\Program Files(x86)\FourJs\fgl\gen2.50\bin\MyCom.dll
C:\Program Files(x86)\FourJs\fgl\gen2.50\bin\MyCom.dll\MyCom.dll
While my COM is really inside of C:\Program Files(x86)\MyCompany\MyApplication\MyCom.dll
To confirm the behavior, we copied the COM in the same directory as fgl.exe and as expected, it works.
So i would like to be able to add a Search Directory to my Activation Context so that it looks for this DLL in my deployment directory.
Is this possible ?
If i can't find another solution, we'll end up deploying our COMs inside of that directory, but that's just not the right.
Thanks
I'm pretty new to WinAPI programming, and have written a Win32 application for screen capture. When I run the program, the cursor immediately changes to a crosshair and I can click and drag to capture a portion of the screen and save it to file.
However, I'd now like to modify my program so that it doesn't contain a main method (WinMain) and essentially turn it into an object class rather than an application class so I can call functions from other programs. I haven't been able to find a good resource on how to do this, as I believe WinMain carries out special functionality under the hood so I can't simply change the name of the method.
Can anyone suggest some good resources or tutorials that address this?
There are many ways to do that, but you have fist move one step back:
How do yopu expect your "program" (let us continue to call that way) to be called?
With which parameters and what return type?
Then, what kind of API do you want to expose? A C++ class in header? a C++ class from a static library?
A C function exported from a DLL? an COM object?
There are many sample on how a library or a DLL or a COM library looks like (just try google those keywords).
The simple way is most likely to set up a library or a DLL project (most IDE have wizard that provide empty skeletons), than paste in it the relevant code that you require to leave there, letting it be called from the exposed function or class method.
A more precise answer can be given only after you decided which "form" your "object" should have.
I have used a lot of modal dialogs and they worked fine without the use of AFX_MANAGE_STATE, but recently I was working on a different project in which the resource dlls are different from the launching dll. I surfed the web and found out the above line and when I inserted it before launching the dialog, it worked. I guess that maybe since we have different dlls, we need to load the state of the main dll in order to launch the dialog, but I am not sure. I have not been able to find a good explanation anywhere on the internet. Could anyone please explain in simple terms what AFX_MANAGE_STATE does and why I suddenly had to use it.
Thanks.
Every .exe and .dll has an internal resource handle, pointing to your dialogs and other resources. If you call a function in your DLL, the current resource handle is pointing to the resources in the .exe, which is wrong and needs to be changed to the resources of the DLL.
This is what AFX_MANAGE_STATE does.
AFX_MANAGE_STATE is a macro which calls resource function so that resource would be looked up only in this DLL, and not the EXE/DLL from which particular function is called. This macro also causes AFX_MAINTAIN_STATE class to be put on stack. This class would, on exit of function, reset the resource lookup, so that EXE/DLL that called this exported function gets it resource searching back.
In C++ terms:
// Some exported function that launches GUI or uses other resources
int GetSomething()
{
AFX_MANAGE_STATE();
...
}
Would be something like (not exactly):
int GetSomething()
{
SetResourceSearchingToThisDLL();
AFX_MAINTAIN_STATE state_RAII;
//Use resource
// Compiler will put destroctor call for state_RAII object here
// which will mean AFX_MAINTAIN_STATE::~AFX_MAINTAIN_STATE()
// And that would call something like:
ResetResourceSearching();
}
Usage of this macro, within same DLL call stack wont hurt anyone, since Resource-Searching has some usage-counter, which will revert to caller (DLL/EXE resource) only if it reaches 0.
It is important to note that, not every MFC DLL has to use this macro. It is only if DLL is loaded by non-MFC client, may be by a C client, a C++ console based application, .NET client etc (yes, may be MFC Windows application client also).
If your EXE and DLL are made in MFC, using same MFC/Compiler/linker version and has one CWinApp object, you need not to use this macro.
Ok so I am learning C++ slowly. I am familiar with all the console syntax and everything, but now I'm moving on to windows programming. Now what im trying to do, is create a DLL that I inject into a process, so it's hooked in. All I want the C++ application to do, is have text in it, that says "Hooked" if it's successfully injected, and an error if something wrong happened. Or even if I can do it without a DLL, Just open an executable, and when the certain process I'm trying to hook is opened, the status is changed to "Hooked". Also I have a safaribooksonline.com account so if there is any good reads you would recommend, just write it down. thanks
I think you might be looking at this backwards. In C/C++ an application 'pulls' a DLL in rather than having a DLL 'injected' into an application. Typically for plugins/hooks, there is some mechanism to inform an application of a DLL's availability (often just its presence in a specific directory) and a configuration file or some other logic is used to instruct the application to explicitly load the library, extract a function or two, and call them.
For Windows programming, I'd suggest doing a search for examples of the LoadLibrary() API call. You'll likely find a tutorial or two on how to do it.
If by "hooked" you mean, "have my DLL run in that processes' address space", you want CreateRemoteThread(). This is fairly advanced and difficult to debug, because your bugs make the other program crash. It's how a lot of malware works, by the way.
If you mean "have my DLL get notified of activity in the other process", you want SetWindowsHookEx().
Sounds like you want to inject as soon as the application starts? You can do that with Microsoft's Detours DetourCreateProcessWithDll(). Example here.
It's been ages since I've written a COM dll. I've made a couple of classes now, that inherit from some COM interfaces, but I want to test it out. I know I have to put a GUID somewhere and then register it with regsvr32, but what are the steps involved?
Edit: Sorry, forgot to mention I'm using C++.
To create a new ATL COM project you can proceed as follow:
File/New Project
Visual C++/ATL/ATL Project
Customize it settings, and press finish when done
You have created a new dll, but it is empty, to add a COM object you can do this:
Project/Add Class
Visual C++/ATL/ATL simple object, press add
Give the name you want (like MyObject), and press finish to add it
If you want that an object implement an interface
In the class view select the object class (CMyObject)
Right click/Add/Implement Interface...
You can select which Interface will implement
From an .idl file already in your projects files
From a .tlb/.dll/.exe which have a type library embedded
From an object already registered
When done press finish
PS: It is much easier to create a new ATL project with the same name in a different folder, and add the files you have customized. The wizard does several tasks and create several customized files.
For larger projects that are difficult to add file by file, I do the same but instead of adding my files to the new project I start copying the settings from the new projects to the old one, and adding any additional file that the wizard has created and fixing headers like stdafx.h to merge the new settings.
PPS: If you want that your dll to support MFC, instead of selecting ATL Project you have to select MFC/MFC Dll. When you add the ATL Simple Object the wizard will ask to add ATL support to the project.
You need to write a function called DllGetClassObject and export it. That function is responsible for allocating a "class factory", which you also have to write, and which is in turn capable of allocating instances of your COM object. It has to implement IClassFactory.
It's not too hard to do. The alternative is to use ATL (see xhantt's answer) which in theory does this for you, but in practice it's a real mess. Somehow it manages to encapsulate the complexity of COM inside an abstraction layer that is even more complicated. Good luck trying to move an object between DLLs for example.
But you could run the ATL wizard just to see an example of how to declare DllGetClassObject. Implementing IClassFactory is very easy - just one method that news-up an object.
Then you need to register your DLL - i.e. put keys into the registry. The regsvr32 tool cannot do this without further help from you. You have to write and export another function called DllRegisterServer, which does all the hard work. All that regsvr32 does is load the DLL, look up DllRegisterServer and call it.
Again, ATL has a way of implementing this for you, but it does it by reading a kind of script full of registry modification instructions, stored in an .rgs file that gets embedded into your DLL's resources. If you accidentally put any kind of syntax error into this file, the registration fails silently.
So again, you may actually find it simpler to write a few lines of code to tweak the registry yourself. Here are the details.
If you used C# instead, you wouldn't have any of these problems. Everything is encapsulated very cleanly. It actually works much better than C++ as a tool for developing COM objects.
When you build the solution, it automatically registers the dll.
And also it creates two files _i.c and .h file.
To test the dll create the sample application:
Create sample Win32 application. Include the _i.c and .h in the cpp file of the win32 application which has main function
Call CoInitialize();
Declare a interface pointer
CComPtr pMyInterface = NULL; // where IMyInterface is declared in _i.c
Create the instance
pMyInterface.CoCreateInstance(CLSID_MyClass); // CLSID_MyClass is GUID representing the
CoClass
Call the APIs present in the Interface
Call CoUnInitialize();