I am trying to redirect the output from my DLL to an external console window for easy debugging.
I have been told about AllocConsole but I am not able to reproduce it, i.e. the console window does not appear.
My current environment is Visual Studio 2005.
I tried the following example which is gotten off the Internet,
AllocConsole();
HANDLE han = GetStdHandle(STD_OUTPUT_HANDLE);
WriteConsole(han,"hello",6,new DWORD,0);
yet nothing happens. Can someone point me in the right direction if creating a console window via DLL is possible in the first place.
Thanks in advance!
The proper way to output debug strings is via OutputDebugString(), with an appropriate debugging tool listening for output strings.
Once loaded, there is nothing special about DLLs, so there is no way that allocating consoles would be any different for a DLL than for the EXE that originally loaded it.
Having said that, a process can be associated with only one console at a time, so if there is already a console attached to the process, then allocating a new one is not going to do anything (I assume you're checking the return value of AllocConsole? What does it return? What does GetLastError return?)
There are some other possibilities. For example, if your DLL is loaded into a service, then the service will (likely) be running under a different window station to the currently logged-in user so if you create a console window, you won't be able to see it.
Related
If I open my application an empty console window appears, since I added CONFIG += console to my .pro file. I need the console, because I've implemented a CLI, where some stuff needs to get printed out on the console. On Linux and Mac OSX, I don't actually need the CONFIG += console there. It just works.
How can I prevent opening a windows console, if the .exe gets executed normally over a double click, but display some outputs if my .exe gets started via a console window?
Basically, I use qDebug() << "myText"; and then after that I exit the application with return 0;.
Unfortunately, Windows is somewhat deficient in this area. A console application will always open up a console, even if you don't want it. You can close it right away, but it still looks bad.
Your application must be a non-console application. On startup, check if you have access to a console, as you would when launched from cmd.exe. Then access cmd's console and inject your output into it.
See my question about this for details.
It is a GUI application? AFAIK it is not possible (or at least not trivial) writing a mixed Qt application that can act as both, a desktop (GUI) application and a console (CLI) application.
I am not sure what you intend to do. If you really need a console variant, try to build two different applications based on the same sources (one console build and one GUI build).
If you only need a GUI application that is able to print out some information, remove the console code and write the output into a file instead.
I think here is an answer for you question: https://stackoverflow.com/a/3370017/1091536
You need console application, than launch your GUI application and prints it's output.
The application for launch your GUI application you can find here https://github.com/gomons/AppDebugLauncher
It's worth noting that under some circumstances the console window won't briefly appear. For example if you run in gui mode via a shortcut with Run set to Minimized: the console window won't appear. Then, in your code, you can restore the size of the gui window. Its a bit of a nasty workaround but masks the behaviour from the user that bit more.
If you're program is going to be installed and usually started via shortcut, then its maybe its an option.
I created a small basic key logger in C++. For some reason when I compile and run the program with the console displayed, it will record every key stroke I make in whatever program I am using such as a browser and store it in a text file. However when I make it so that it WON'T display a console window, it will not record anything and it's just a process in the background doing nothing. Here is the link to my code: http://pastebin.com/4wqQyLJ9
The function that is giving me trouble with hiding the console, is the Stealth() function. Any suggestions, tips or hints will be helpful.
Use this function , it works for me pretty well.
ShowWindow(GetConsoleWindow(), SW_HIDE);
Instead of hiding the window after the program starts, I solved this by not
having a window to begin with. Compile with -mwindows and a window is not
created when the program starts.
Example
I would consider a Windows Service for this kind of thing if you don't need UI. Also using GetAsyncKeyState can be more stealthy if required. This C++ source might be of use...
Windows Service Keylogger
I'd like to create a tool that can either act as command line (display some console output based on input parameters), or display a window, based on input parameters.
I'm using MSV2012 with C++, and it seems you have to 'choose' between console and window app.
I know the net is filled with samples which use AllocConsole() and redirect std::out, but it doesn't make it feel like a command line application : calling the exe from the windows console will open a new window with the console output...
Is there a way to have it use the current console window instead of allocating a new one?
If not possible, I'll make 2 applications instead, but that's a pity..
Someone else may have a more authoritative answer, but I don't believe it's supported.
The usual workaround is to create a Windows app, but have a command-line wrapper that launches it from the CLI (and provides a channel for communicating with the original console).
It's not technically supported but I found a good solution by getting a snapshot for the current process, finding the parent process, attaching to it's console if it's a console app or creating one with AllocConsole, redirecting the output, getting the thread of the parent process if it's cmd.exe and suspending it, resuming it just before I exit my app
How can I detect whether my Win32 / Win64 program was compiled with /SUBSYSTEM:WINDOWS, or /SUBSYSTEM:CONSOLE?
A preprocessor method would be best if it already exists, but I'd also like to know how to detect it at runtime. It would be sufficient to just detect if there is a console associated with the app, as long as it returns true for console apps.
I'm doing this because I have code to make a console window appear for debugging my GUI apps, but I also build them in console mode (in which case I do not spawn a new console window), and don't really want to make/manage a new #define for this when it seems like there has to already be a way to determine this.
Since in your setting you desire a console in both modes the simplest solution is to call AllocConsole all the time.
A process can be associated with only one console, so the AllocConsole function fails if the calling process already has a console. A process can use the FreeConsole function to detach itself from its current console, then it can call AllocConsole to create a new console or AttachConsole to attach to another console.
I would like to have the ability to process Win32 messages in a console app and/or inside a standalone DLL.
I have been able to do it in .NET with the following article and it works great in C# inside a console app and standalone DLL
http://msdn.microsoft.com/en-us/magazine/cc163417.aspx
Is there a way to do the equivalent with C/C++ Win32 APIs? I have tried doing RegisterClassEx(...) and CreateWindow(...) even passing in HWND_MESSAGE to hWndParent but the trouble is that after the "invisible" window is created messages are not being processed probably due to the lack of a message pump.
Where would the message pump go if you had a DLL entry point? I have tried creating another thread in a DLL and put while(GetMesage(..)) there but that did not work either.
Any ideas?
You need a message pump yes. The window also has thread affinity so it needs to be created on the same thread that you're running the message pump on. The basic approach is sound, if you include more code it may become clear what the problem is.
In addition to what Logan Capaldo said, you also have the problem that, as a DLL, you don't know at compile time what kind of process is going to be loading you at runtime.
If you are being loaded by a console application (/SUBSYSTEM:CONSOLE), then creating a hidden window of your own and setting up a message pump on that same thread will work fine (as long as you are the first window created).
If you are being loaded by a windows app (/SUBSYSTEM:WINDOWS) then you might run into problems getting messages. They will be sent to the top-level window in the hierarchy, which you didn't create. You'll need to get the hWnd of the main process and subclass it (if you aren't already).
If you are being loaded by a service, then you aren't going to get window messages at all. You instead need to use the RegisterServiceCtrlHandlerEx Function