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

rdmd --build-only -debug -g -of"con32.exe" contest.d  ## Generates console window and main application window

rdmd --build-only -debug -g -m64 -of"con64.exe" contest.d  ## 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)

On Wednesday, 18 September 2019 at 00:13:43 UTC, cc wrote:
> Sample program here: https://pastebin.com/wpLetNKP

You 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.