digitalmars.D.learn - Building 64-bit Windows application with console window
cc <cc nevernet.com> writes:
This might be more a question about the MS linker than D, but I'm noticing that when building with -m64 under DMD v2.087.1, it is no longer generating a console window when running the application. Under 32-bit, it would always generate the console window, and I had to disable it by building with a .def file that specified SUBSYSTEM WINDOWS when I no longer wanted it. Is there a way to instruct it to still spawn the console window for debugging purposes? Sample program here: https://pastebin.com/wpLetNKP Generates console window and main application window Only generates main application window I tried adding -L/SUBSYSTEM:CONSOLE to the build arguments but then I believe it looks for the wrong entry point and fails: libcmt.lib(exe_main.obj) : error LNK2019: unresolved external symbol main referenced in function "int __cdecl __scrt_common_main_seh(void)" (?__scrt_common_main_seh YAHXZ)
Sep 17 2019
Adam D. Ruppe <destructionator gmail.com> writes:
On Wednesday, 18 September 2019 at 00:13:43 UTC, cc wrote:Sample program here: https://pastebin.com/wpLetNKPYou have a WinMain function there. The Microsoft linker sees that as an indication that you are writing a Windows gui application and thus suppresses the console window. Inside your program, you can always call the AllocConsole() function to pop up a console and attach it: https://docs.microsoft.com/en-us/windows/console/allocconsole So a potential fix for you to just stick debug AllocConsole(); right inside your WinMain before doing anything else. Or my preference is to just never write WinMain in D. Just write a normal D main and use -L/subsystem:windows when you don't want the console (note: on 64 bit using the subsystem with normal main(), you also need to pass `-L/entry:mainCRTStartup.` to dmd so it uses the right entry point), and allow the defaults if you do want it.
Sep 17 2019