I downloaded GTK+ for windows and included the library in my Visual Studio 2010 and it works fine, but I don't know how to output text to the console or any other form for debugging.
I tried g_print("hi"); and even std::cout << "cout test"; but nothing shows up.
Is there a way to debug in windows?
In gcc there is the -mwindows flag that sets the PE header subsystem type to get a GUI application. Without it you'll get two windows: one with the GTK+ GUI and one with a console where stdout and stderr are redirected. I suspect there is something similar also in Visual Studio, maybe specifying in some way your application is console based.
Related
This is from Visual Studio Community 2022 64-bit 17.1.1, "Current."
The binary to be debugged was compiled on Windows 11 with the same IDE, but I'm running it on Windows 10 Pro. Once it starts, I'm trying to attach the debugger.
The same file system contains all exe, lib, dll, obj, and source, all in the same places and full paths, as it's mounted in the same position on both computers (T:).
Attachment type is "Automatic." I'm doing Debug->Attach to Process, and clicking on a PID.
The same workflow succeeds on connecting the debugger on the same IDE on the Windows 11 box where the exe was compiled.
All processes belong to the same user (me).
Googling is finding nothing at all except red herrings about remote debugging (I'm trying to debug on the computer running the binary) and permissions.
OK, I'm not sure if this answer will help others, but on Windows 11, when I select the binary in question, the "Attach to:" menu comes up as "Native Code" automatically. On Windows 10, the same Visual C++ release, attaching to the exact same binary, for some reason is detecting it as Python. Manually setting the Code Type to "Debug these code types:"-->Native allowed the debugger to attach correctly.
When building and running an OpenGL Solution, it opens the OpenGl window and a terminal. My question is how do I set it so that this terminal appear in my debug build but not my final build?
I'm using Visual Studio 2017.
Set the Debug configuration to use the CONSOLE subsystem and WINDOWS for Release.
Don't forget to adapt your entry-point (main() vs WinMain()) if your application framework (if any) doesn't handle that internally. SDL2 for example handles that for you via some #ifdef logic.
I installed MinGW and created a makefile project on Visual Studio Community 2015 today and got it working for compilation.
Still two things are bugging me:
Interface
I can't tell Visual Studio to prevent closing the console window after running the program. Even Start Without Debugging closes the window and the project properties are not the same as a normal VS project, so I don't know how to configure this.
Debugging
Setting breakpoints is hopeless. Apparently the debugger won't understand debug info from files compiled with other compilers. I get Module was built without symbols..
I've tried setting up gdb according to this answer, but then starting the debugger lead me to this window:
which indicates that the executable has indeed debugging symbols (I'm compiling with -g)
I can feel I'm getting pretty close. What am I missing?
mingw-gcc generates DWARF format debugging information in its
executables. The Visual Studio debugger expects separate PDB
debugging files as produced by Microsoft's compilers. It can't
recognize DWARF.
You can debug MinGW executables either with
the gdb console, as you have almost started to do, or for
"visual" debugging you can do it in an IDE that supports gdb,
on Windows, such as CodeLite, Eclipse-CDT, CodeBlocks. If you
are wedded to Visual Studio you might try your luck with
Microsoft's open sourced Visual Studio MI Debug Engine ,
which according to its blurb "enables debugging with debuggers that support the gdb Machine Interface ("MI") specification such as GDB, LLDB, and CLRDBG".
I know nothing more about it
I just got a new 64-bit computer with the characteristics in the title above and am trying to run a simple OpenGL program with only glutInit() and return 0 in main() . It builds but running under Debug opens a window with a black screen and then another popup window which says "The application was unable to start correctly (0xc000007b). Click OK to close the application." I've rechecked the placing of the .h, .lib and .dll files and they match suggestions I've found online. I think my project settings are correct or it wouldn't have built. What did I forget to do?
I have written a small getting-started program for OpenGL 3.2 (or later) using Visual Studio 2010 and FreeGlut / GLEW.
https://github.com/mortennobel/OpenGL_3.2_VS_2010_freeglut
One important points to notice is to set glewExperimental = GL_TRUE; (otherwise the program can crash on some OpenGL drivers).
I want to know if this can be done in the latest version of VS by a simple setting somewhere that causes VS to behave in a way that is equivalent to "ContextMenu">run "a_Java_src_file_with_main" in the Eclipse IDE. I'm using the trial version of VS 2010 Pro on a new W7 platform. Even the minimal helloworld cpp source file added to a project generated from the "empty" template redirects into a command window.
Same question 3 years ago:
Capturing cout in Visual Studio 2005 output window?
And 9 months ago:
How to redirect stdout to output window from visual studio
I'm aware of using OutputDebugString(...) and of redirecting the stream to a file as alternatives.
Capture console output for debugging in VS?
Simple way to do this is to "suppress the console window" by building an executable with a WinMain entry point on windows instead of main.
This can usually be done by editing the project settings, but if you use cmake, like me, these settings are overwritten every time you call the cmake build. So, in this case you need to add WIN32 to executable target in CMakeList.txt or set CMAKE_WIN32_EXECUTABLE to true for cmake configure command.