On 2014-01-08 09:46, Mike Parker wrote:

> The easiest way is to use main() and add this to the DMD command line:
>
> /SUBSYSTEM:WINDOWS:5.01
>
> This will give you a windowed app with no console popping up *and* the
> command line args are still stored in Runtime.args and passed to the
> main method just as they are in a console app.
>
> Note that 5.01 is for 32-bit. 5.02 should be used when compiling for
> 64-bit.

What's the original idea of WinMain anyway?

-- 
/Jacob Carlborg

On Wednesday, 8 January 2014 at 10:15:30 UTC, Jacob Carlborg wrote:
> On 2014-01-08 09:46, Mike Parker wrote:
>
>> The easiest way is to use main() and add this to the DMD command line:
>>
>> /SUBSYSTEM:WINDOWS:5.01
>>
>> This will give you a windowed app with no console popping up *and* the
>> command line args are still stored in Runtime.args and passed to the
>> main method just as they are in a console app.
>>
>> Note that 5.01 is for 32-bit. 5.02 should be used when compiling for
>> 64-bit.
>
> What's the original idea of WinMain anyway?

http://stackoverflow.com/a/2399064/1284631

On 8 January 2014 18:46, Mike Parker <aldacron@gmail.com> wrote:

> On 1/8/2014 6:29 AM, Adam D. Ruppe wrote:
>
>> On Tuesday, 7 January 2014 at 21:26:07 UTC, Manu wrote:
>>
>>> This doesn't work anymore. I don't know what the proper way to boot a Win32 app is.
>>>
>>
>> The easiest way is to just write a regular program with a main() instead of a WinMain. If you need the args, you can get them from functions like GetModuleHandle, GetCommandLine, etc.
>>
>>
> The easiest way is to use main() and add this to the DMD command line:
>
> /SUBSYSTEM:WINDOWS:5.01
>
> This will give you a windowed app with no console popping up *and* the command line args are still stored in Runtime.args and passed to the main method just as they are in a console app.
>
> Note that 5.01 is for 32-bit. 5.02 should be used when compiling for 64-bit.
>

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.

On 2014-01-08 12:17, 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 Windows that is lame. Every other platform uses a normal main function.

-- 
/Jacob Carlborg

On 2014-01-08 12:17, 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.

Using a standard main function allows you do use the same code on all platforms. You most likely will need different linker flags anyway.

-- 
/Jacob Carlborg

On Wednesday, 8 January 2014 at 11:17:24 UTC, Manu wrote:
> I have to say though, requiring additional linker arguments is pretty lame.

They aren't really required, the program will work without them, the linker argument tells the operating system not to allocate a console for this process.

That's not always wanted; I like having a console for printf debugging even with a gui.

But on my system, I made a separate little script that adds the linker argument so I don't type it out often when I want that. You might consider doing the same.


BTW I think dmd should have more linker pragmas though. I wouldn't mind a pragma(windows_subsystem, "windows") as well as things like pragma(manifest, "<some xml>") or pragma(resource) or pragma(module_definition) and so on. But eh I can see the arguments against these too.

On Wednesday, 8 January 2014 at 12:50:54 UTC, Jacob Carlborg wrote:
> It's Windows that is lame. Every other platform uses a normal main function.

eh they're really in the same boat. Declaring your own WinMain is kinda like declaring your own _start symbol on linux. It skips the runtime's main() function and you're more on your own.

Both the C and the D runtimes implement their own entry point which calls into your program's main and you can use these consistently across platforms.

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

On 2014-01-08 14:28, Adam D. Ruppe wrote:

> eh they're really in the same boat. Declaring your own WinMain is kinda
> like declaring your own _start symbol on linux. It skips the runtime's
> main() function and you're more on your own.

No, it's not.

For C:

Implementing WinMain does not bypass the runtime[1]. Implementing _start on Linux would most likely bypass the runtime. Implementing WinMain is more like implementing main() on Posix.

For D:

Implementing WinMain or main() as extern (C) will bypass the D runtime, it still won't bypass the C runtime.

I would expect the boot process be something like this:

Linux:
_start
C main
D main

Windows:
CRT (C runtime library)
C main or WinMain
D main

> Both the C and the D runtimes implement their own entry point which
> calls into your program's main and you can use these consistently across
> platforms.

WinMain is not the entry point. The C runtime library will call it just like it will call C main.

[1] http://msdn.microsoft.com/en-us/library/windows/desktop/ff381406%28v=vs.85%29.aspx

-- 
/Jacob Carlborg

On Wednesday, 8 January 2014 at 14:11:50 UTC, Jacob Carlborg wrote:
> Implementing WinMain does not bypass the runtime[1].

Ah, now I know, thanks!

> Implementing _start on Linux would most likely bypass the runtime.

Yeah, I know that does since I do it with gcc -nostdlib a lot. I was wrong about Windows though.