On 1/8/2014 8:17 PM, Manu wrote:
Right... well, I don't really care how it is, I just want the wiki to be
updated with the 'standard' way. I will then copy and paste into my
code, and ideally everyone's startup code will look the same.
I have to say though, requiring additional linker arguments is pretty
lame. I'd definitely rather not, if I was voting on a standard approach.
It's the same with C or C++ apps, using any compiler on Windows.
Anything with a 'main' entry point is automatically launched as console
subsystem, anything with WinMain as windows subsystem. The command line
argument allows you to override the default behavior. You could, for
example, use a WinMain entry and specify /SUBSYSTEM:CONSOLE (or whatever
the keyword is).
I was surprised to learn when using premake with MinGW was that it
automatically configured things to link all windows executables as
subsystem windows. I got used to it when I mostly worked with C, so now
in D all of my dub package.jsons for executables have a configurations
section that looks something like this:
"configurations": [
{
"name": "foo",
"targetType": "executable",
"targetPath": "bin",
"targetName": "foo"
},
{
"name": "foo-win",
"targetType": "executable",
"targetPath": "bin",
"targetName": "foo",
"lflags": ["/SUBSYSTEM:WINDOWS:5.01"]
}
]
The console version as default means during development I get a console
window every time I launch the latest build (which is convenient for
debug output) without having specified any extra args on the dub command
line. Of course, for someone using VisualD it's not such a big deal. But
I think adding a linker flag to the project settings is less work than
maintaining two separate entry points :)
