I'm running a exe file that has cprintf calls in one of its DLLs, the exe is GUI application, I'm looking for a method to get the output of the cprintf calls.
Thanks.
This was solved by loading DLL on runtime that called AllocConsole() in DLLMain.
Related
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.
I have a project that consists of a DLL and a windows console application .exe.
The .exe calls the DLL. In the DLL I am creating a Dialog box.
AFX_MANAGE_STATE(AfxGetStaticModuleState());
MyDlg* dlg = new MyDlg;
dlg->Create(IDD_DIALOG1);
I had to add AFX_MANAGE_STATE(AfxGetStaticModuleState()) so it knew to look in the DLL for the resources. However this seems to be causing a problem when control is returned to the EXE.
When I "return 0" in the main() function of the EXE the console window does not go away. I have to physically close it in order for the EXE to stop running. If I remove AFX_MANAGE_STATE(AfxGetStaticModuleState()) from the DLL (along with all references to MyDlg since they won't work without it) everything works fine when control is passed back to the EXE.
Why would this be happening?
Fixed. My DLL is using DAO. I had to add AfxDaoTerm(); before exiting. Thank you
I have an MFC .exe application, and I created another project for a DLL with MFC dynamically linked to it.
Now, when I import that DLL through LoadLibrary, it crashes my application, because when the importing is done, the DLL calls AfxWinInit().
Should the DLL call AfxWinInit()? How do I avoid it? Or is something else wrong?
In your MFC application WinMain() calls AfxWinMain(). The AfxWinInit() is called at the beginning of AfxWinMain(). So the initialization is done by framework for you. There is no need to initialize it again.
MFC DLLs provide their own entry point, so you're not supposed to write one yourself. If you plan to write a DLL with MFC support, I'd suggest you start with a fresh MFC DLL created by the app wizard and then move your code there.
For MFC applications that load extension DLLs, use AfxLoadLibrary instead of LoadLibrary.
I have a CWinApp-based application that is built as a DLL that is loaded by another 3rd party application as a plugin. My app exposes an exported StartPlugin() method that creates a CDialog derived dialog. This exported function is somehow called by the 3rd party application. I'd like to be able to run my DLL outside of the 3rd party application so I can test and play around with UI stuff (not for unit testing).
How can I create a test harness that will allow me to run my dll code? I'm not sure how the main application launches my dll plugin, but I'm speculating that it's creating a User-Interface thread? So would I just need to create a simple exe that can somehow load my dll and create a new thread or something. Any links to tutorials or articles that explain something like this.
Use the Visual Studio wizard to create a MFC application, probably Dialog based. Have a button on the dialog to run your plugin. In the button code do a LoadLibrary with the name of your DLL, then call GetProcAddress to get a pointer to the StartPlugin function. Then you can call StartPlugin.
I'm using Visual Studio 2010 to create a 32-bit DLL as a plug-in to a 3rd party app (AviSynth). The DLL was being correctly loaded by the 3rd party app until I tried to use the FFTW (http://fftw.org) DLL. I took the 32-bit FFTW DLL, ran "lib /def:libfftw3-3.def" to create a .lib file, added that as a resource in the project. Made some calls to the functions. It compiles fine, but when I try to load it in the third party tool, it fails.
I've tried putting the FFTW DLL alongside my DLL, and I've also tried using LoadLibrary from inside my DllMain, but it's still not working.
I am able to stop the debugger in the DllMain function and in the function called by AviSynth (AvisynthPluginInit2), but AviSynth claims to be unable to load the DLL after that, and breakpoints at the tops of functions that were called before are no longer hit.
The AviSynth error message is:
LoadPlugin: unable to load "C:\Program Files (x86)\AviSynth 2.5\plugins\xxxMYPLUGINxxx.dll"
Thanks for your help.
The first thing I try when I get something like this is Dependency Walker:
http://www.dependencywalker.com/
It won't catch every possible problem, but it's very quick to check for simple problems (missing DLLs, missing exports). You can also set it to open any number of file-extensions by double-clicking them. I usually set .dll, .ax, .ocx, .sys, .exe.
IMO one of the essential tools for any Windows developer.
ps: if Dependency Walker doesn't find any problems, try to load your DLL with LoadLibrary() and see what GetLastError() returns.
BTW:
and I've also tried using LoadLibrary from inside my DllMain, but it's still not working.
You cannot call LoadLibrary() from DllMain().
The entry-point function should perform only simple initialization or termination tasks. It must not call the LoadLibrary or LoadLibraryEx function (or a function that calls these functions), because this may create dependency loops in the DLL load order.
(The entry-point function is your DllMain)
Turns out that the FFTW DLL had to be in the same directory as the AVS script, not the AVISynth plugin directory. I guess that's the working directory for Virtual Dub.
Anyway, it works now. Thanks for the help!