www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Windows startup docs are out of date

reply Manu <turkeyman gmail.com> writes:
http://dlang.org/windows.html

This doesn't work anymore. I don't know what the proper way to boot a Win32
app is.
Is it required to explicitly init the runtime?
Jan 07 2014
next sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
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.


 Is it required to explicitly init the runtime?


If you want to use WinMain directly, yes, use Runtime.initalize 
before doing anything else. But I say regular main is much easier.
Jan 07 2014
next sibling parent reply Manu <turkeyman gmail.com> writes:
On 8 January 2014 07:29, Adam D. Ruppe <destructionator gmail.com> 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.


  Is it required to explicitly init the runtime?


 If you want to use WinMain directly, yes, use Runtime.initalize before
 doing anything else. But I say regular main is much easier.


It complains and says to use rt_init(), and that exception handler thing is
gone.
I think that page needs to be updated by someone who knows how it should
look.



 Jan 07 2014



  parent reply "Adam D. Ruppe" <destructionator gmail.com>  writes:


On Tuesday, 7 January 2014 at 21:37:05 UTC, Manu wrote:

 It complains and says to use rt_init(), and that exception 
 handler thing is gone.


blargh, well Runtime.initialize() without args works too.


 I think that page needs to be updated by someone who knows how 
 it should look.


Yeah, and it'd be good to add the note that doing your own 
WinMain isn't actually needed... and use MessageBoxW.



 Jan 07 2014



  parent reply Manu <turkeyman gmail.com>  writes:


On 8 January 2014 07:43, Adam D. Ruppe <destructionator gmail.com> wrote:


 On Tuesday, 7 January 2014 at 21:37:05 UTC, Manu wrote:


 It complains and says to use rt_init(), and that exception handler thing
 is gone.


 blargh, well Runtime.initialize() without args works too.



It didn't work for me. Said it was deprecated... and to use rt_init().
Is there a difference? Why do Runtime.initialize() AND rt_init() both
exist? I don't like pointless aliases... I freak out that there's some
small difference that I don't understand.

 I think that page needs to be updated by someone who knows how it should

 look.


 Yeah, and it'd be good to add the note that doing your own WinMain isn't
 actually needed... and use MessageBoxW.


But yeah, it needs to be updated with the latest best practise.



 Jan 07 2014



 next sibling parent  "Adam D. Ruppe" <destructionator gmail.com>  writes:


On Wednesday, 8 January 2014 at 00:32:56 UTC, Manu wrote:

 It didn't work for me. Said it was deprecated... and to use 
 rt_init().



Huh, the message I got is:
winmain.d(13): Deprecation: function 
core.runtime.Runtime.initialize is deprecated - Please use the 
overload of Runtime.initialize that takes no argument.

Maybe different dmd versions. Oh well.


 Is there a difference?


The source tells:

     static bool initialize()
     {
         return !!rt_init();
     }

/// C interface for Runtime.initialize, returns 1/0 instead of 
bool
extern(C) int rt_init();


So no real difference.


 Why do Runtime.initialize() AND rt_init() both exist?


idk



 Jan 07 2014



prev sibling  parent  Jacob Carlborg <doob me.com>  writes:


On 2014-01-08 01:32, Manu wrote:


 It didn't work for me. Said it was deprecated... and to use rt_init().
 Is there a difference? Why do Runtime.initialize() AND rt_init() both
 exist? I don't like pointless aliases... I freak out that there's some
 small difference that I don't understand.


rt_init() is to be used from C, so you don't have to bother with the D 
mangling. Runtime.initialize() is supposed to be used from D, you need 
to do something special about the boot process, which you normally doesn't.

-- 
/Jacob Carlborg



 Jan 07 2014



prev sibling next sibling parent  Jacob Carlborg <doob me.com>  writes:


On 2014-01-07 22:29, Adam D. Ruppe wrote:


 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 runtime provides access to the command line arguments as well:

core.Runtime.args
core.Runtime.cArgs

http://dlang.org/phobos/core_runtime.html

-- 
/Jacob Carlborg



 Jan 07 2014



prev sibling  parent reply Mike Parker <aldacron gmail.com>  writes:


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.



 Jan 08 2014



 next sibling parent reply Jacob Carlborg <doob me.com>  writes:


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



 Jan 08 2014



  parent  "eles" <eles eles.com>  writes:


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



 Jan 08 2014



prev sibling  parent reply Manu <turkeyman gmail.com>  writes:


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.



 Jan 08 2014



 next sibling parent reply Jacob Carlborg <doob me.com>  writes:


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



 Jan 08 2014



  parent reply "Adam D. Ruppe" <destructionator gmail.com>  writes:


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.



 Jan 08 2014



  parent reply Jacob Carlborg <doob me.com>  writes:


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



 Jan 08 2014



  parent  "Adam D. Ruppe" <destructionator gmail.com>  writes:


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.



 Jan 08 2014



prev sibling next sibling parent  Jacob Carlborg <doob me.com>  writes:


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



 Jan 08 2014



prev sibling next sibling parent  "Adam D. Ruppe" <destructionator gmail.com>  writes:


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.



 Jan 08 2014



prev sibling  parent  Mike Parker <aldacron gmail.com>  writes:


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



 Jan 08 2014



prev sibling  parent  Jacob Carlborg <doob me.com>  writes:


On 2014-01-07 22:25, Manu wrote:

 http://dlang.org/windows.html

 This doesn't work anymore. I don't know what the proper way to boot a
 Win32 app is.
 Is it required to explicitly init the runtime?


I started to think about this some more and I agree with Adam, just use 
a regular D main function.

-- 
/Jacob Carlborg



 Jan 07 2014