Windows startup docs are out of date

[Mike Parker]

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 :)