On 13.02.2012 20:13, Walter Bright wrote:
> Hi Alf! Welcome!

Thanks.


> On 2/12/2012 4:02 PM, Alf P. Steinbach wrote:
[snip]
>
>> * Improvement potential #5 -- The description of Windows prog.
>>
>> Following main site's links to
>> [http://d-programming-language.org/windows.html],
>> I found a real monstrosity as an example of purportedly simplest possible
>> Windows GUI program. It's almost funny. Here is mine:
>>
>> <code>
>> import std.c.windows.windows;
>>
>> void main()
>> {
>>     MessageBoxW( null, "Text", "Caption", MB_OK | MB_ICONINFORMATION );
>> }
>> </code>

[Just in passing, a practical tip: in Thunderbird (which you're using), selecting all the text before hitting "Reply" prevents TB from removing indents from code. They added the remove-indents behavior in version 2. Nobody expects it, for why on Earth should it do that?, but it does.]


>> And here is how I built it:
>>
>>
>> <example>
>> [d:\dev\test\d]
>> > dmd minimal_gui.d -L-subsystem:windows
>>
>> [d:\dev\test\d]
>> > dumpbin /headers minimal_gui.exe | find /i "sub"
>> 3.10 subsystem version
>> 2 subsystem (Windows GUI)
>>
>> [d:\dev\test\d]
>> > minimal.d
>> </example>
>>
>>
>> Maybe with DMD tools something potentially bad happens here. However,
>> with
>> extant C++ compilers (and even old Borland C++ 5.5) this way of doing
>> things
>> works splendidly. So here is a definite improvement potential for the
>> web site
>> page with the monstrous code, and if the current tools don't handle it
>> well,
>> also for the the toolset. :-)
>
> Good point, the Windows examples get less love than the other stuff.

He he.


> On
> the other hand, I don't think a simple main()/MessageBoxW() program
> scales as a first program. It needs to be a WinMain(), and it needs to
> show how to get a classic GUI program started up and shut down. The user
> can then start hanging flesh on it for his own purposes.

Oh, that's just Microsoft propaganda-by-example.

In C and C++ the non-standard Microsoft specific WinMain startup function technically only makes the programs formally incorrect for a hosted implementation, and in practice it serves to make people accept also other Microsoft lock-in things blindly, without questioning.

People are tricked into believing that this Microsoft standard-breaking thing is needed because all Microsoft examples use it, and because Microsoft's toolchain (but not e.g. the GNU toolchain) won't accept a standard `main` for a GUI subsystem program, without use of not very well documented options (MSVC linker option "/entry:mainCRTStartup").

In D, if the example code given on the D site is correct apart from the result value bug, WinMain requires a lot of ugly boiler-plate code. Re the bug, it's duplicated in the VisualD starter code for a new console project, so such boiler-plate code is definitely undesirable... So, on the Bright side, this is a real improvement opportunity :-).

The main problem (pun not intended) in C and C++ is that neither standard `main` nor non-standard Microsoft `WinMain` provide the command line arguments in Unicode. Standard `main` has `char` arguments, by Windows convention encoded in Windows ANSI, which generally means data loss and e.g. that some file names can't be passed. Microsoft `WinMain` provides the arguments part of the command line, in Unicode, but not split up into individual arguments.

I do not yet know the valid signatures for a D standard `main`.

But if those D signatures include one with a set of Unicode arguments, then all is super-duper, and if not, then one must just do in D what one must do in C and C++ for a real and standard-conforming program, namely to use the Windows API to retrieve the arguments (if necessary).


>> - Alf (at very beginning of checking out the D language)
>
> Thanks for taking the time to post these first experiences. It's often
> hard for use to see the picture in the way a new user does.

I once, as a college lecturer, used to quip that one learns as long as one has students... ;-)


Cheers & hth.,

- Alf

You can get the runtime arguments at any point in your D code (and especially in module constructors that run before main) via 'Runtime.args', by importing 'core.runtime'.

On 02/14/2012 11:45 AM, Alf P. Steinbach wrote:
> On 13.02.2012 20:13, Walter Bright wrote:
>> Hi Alf! Welcome!
>
> Thanks.

Welcome! :) I've learned a lot from you on comp.lang.c++.moderated. It is great to see you here as well.

If you don't mind my asking, and of course it is totally fine if you choose not to answer, what features of D have made it worth it for you to try it out?

Ali

On Feb 14, 2012, at 11:45 AM, Alf P. Steinbach wrote:
> 
> The main problem (pun not intended) in C and C++ is that neither standard `main` nor non-standard Microsoft `WinMain` provide the command line arguments in Unicode. Standard `main` has `char` arguments, by Windows convention encoded in Windows ANSI, which generally means data loss and e.g. that some file names can't be passed. Microsoft `WinMain` provides the arguments part of the command line, in Unicode, but not split up into individual arguments.
> 
> I do not yet know the valid signatures for a D standard `main`.
> 
> But if those D signatures include one with a set of Unicode arguments, then all is super-duper, and if not, then one must just do in D what one must do in C and C++ for a real and standard-conforming program, namely to use the Windows API to retrieve the arguments (if necessary).

D should pass the command-line args as properly translated UTF-8.  If this doesn't happen, consider it a bug.  Regarding Windows specifically, D currently gets the args via GetCommandLineW(), so if that doesn't muck things up then all should be well.

On 2/14/2012 11:45 AM, Alf P. Steinbach wrote:
> On 13.02.2012 20:13, Walter Bright wrote:
>> Hi Alf! Welcome!
>
> Thanks.
>
>
>> On 2/12/2012 4:02 PM, Alf P. Steinbach wrote:
> [snip]
>>
>>> * Improvement potential #5 -- The description of Windows prog.
>>>
>>> Following main site's links to
>>> [http://d-programming-language.org/windows.html],
>>> I found a real monstrosity as an example of purportedly simplest possible
>>> Windows GUI program. It's almost funny. Here is mine:
>>>
>>> <code>
>>> import std.c.windows.windows;
>>>
>>> void main()
>>> {
>>> MessageBoxW( null, "Text", "Caption", MB_OK | MB_ICONINFORMATION );
>>> }
>>> </code>
>
> [Just in passing, a practical tip: in Thunderbird (which you're using),
> selecting all the text before hitting "Reply" prevents TB from removing indents
> from code. They added the remove-indents behavior in version 2. Nobody expects
> it, for why on Earth should it do that?, but it does.]
>
>
>>> And here is how I built it:
>>>
>>>
>>> <example>
>>> [d:\dev\test\d]
>>> > dmd minimal_gui.d -L-subsystem:windows
>>>
>>> [d:\dev\test\d]
>>> > dumpbin /headers minimal_gui.exe | find /i "sub"
>>> 3.10 subsystem version
>>> 2 subsystem (Windows GUI)
>>>
>>> [d:\dev\test\d]
>>> > minimal.d
>>> </example>
>>>
>>>
>>> Maybe with DMD tools something potentially bad happens here. However,
>>> with
>>> extant C++ compilers (and even old Borland C++ 5.5) this way of doing
>>> things
>>> works splendidly. So here is a definite improvement potential for the
>>> web site
>>> page with the monstrous code, and if the current tools don't handle it
>>> well,
>>> also for the the toolset. :-)
>>
>> Good point, the Windows examples get less love than the other stuff.
>
> He he.
>
>
>> On
>> the other hand, I don't think a simple main()/MessageBoxW() program
>> scales as a first program. It needs to be a WinMain(), and it needs to
>> show how to get a classic GUI program started up and shut down. The user
>> can then start hanging flesh on it for his own purposes.
>
> Oh, that's just Microsoft propaganda-by-example.
>
> In C and C++ the non-standard Microsoft specific WinMain startup function
> technically only makes the programs formally incorrect for a hosted
> implementation, and in practice it serves to make people accept also other
> Microsoft lock-in things blindly, without questioning.
>
> People are tricked into believing that this Microsoft standard-breaking thing is
> needed because all Microsoft examples use it, and because Microsoft's toolchain
> (but not e.g. the GNU toolchain) won't accept a standard `main` for a GUI
> subsystem program, without use of not very well documented options (MSVC linker
> option "/entry:mainCRTStartup").
>
> In D, if the example code given on the D site is correct apart from the result
> value bug, WinMain requires a lot of ugly boiler-plate code. Re the bug, it's
> duplicated in the VisualD starter code for a new console project, so such
> boiler-plate code is definitely undesirable... So, on the Bright side, this is a
> real improvement opportunity :-).

Yes, unfortunately, I am not an expert at Windows event loop GUI programming, and so I am unsure of the right way to do this. So I fell back on the standard way.


> But if those D signatures include one with a set of Unicode arguments, then all
> is super-duper, and if not, then one must just do in D what one must do in C and
> C++ for a real and standard-conforming program, namely to use the Windows API to
> retrieve the arguments (if necessary).

In D, the main(string[] args) are supposed to be in Unicode (more specifically, UTF-8).


> I once, as a college lecturer, used to quip that one learns as long as one has
> students... ;-)

And the old but true corollary, the best way to learn something is to try and teach it to others.

On 2/14/2012 2:02 PM, Sean Kelly wrote:
> D should pass the command-line args as properly translated UTF-8.  If this
> doesn't happen, consider it a bug.  Regarding Windows specifically, D
> currently gets the args via GetCommandLineW(), so if that doesn't muck things
> up then all should be well.

Just to add to that, D is designed to be a Unicode language from front-to-back. The runtime library (and that would include the code that calls main()) is supposed to do any translations necessary to make that happen when dealing with operating systems APIs.

For user level programming, it is considered good style to adhere to this practice. I.e. all data imported into the program should be converted on input to Unicode, processed, and converted to the output representation upon output. All runtime library interfaces expect text strings to be in Unicode.

On 14.02.2012 22:21, Ali Çehreli wrote:
> On 02/14/2012 11:45 AM, Alf P. Steinbach wrote:
>  > On 13.02.2012 20:13, Walter Bright wrote:
>  >> Hi Alf! Welcome!
>  >
>  > Thanks.
>
> Welcome! :) I've learned a lot from you on comp.lang.c++.moderated. It
> is great to see you here as well.
>
> If you don't mind my asking, and of course it is totally fine if you
> choose not to answer, what features of D have made it worth it for you
> to try it out?

Well, there's Walter, compiler genius, and Andrei, template genius, and I figure that with both of them doing D stuff there must be something here. ;-)


Cheers,

- Alf

On 2/15/2012 7:16 AM, Walter Bright wrote:

>
> And the old but true corollary, the best way to learn something is to
> try and teach it to others.

After 18 years of teaching English here in Korea, I find it very difficult not to correct friends and family back home. If my high school teachers could see me now...