www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - newbie - hey walter, improvement potentials for installer

reply "Alf P. Steinbach" <alf.p.steinbach+usenet gmail.com> writes:
Hi

I just installed D 2.x.




It was not clear to me that the first download is a full offline 
installer. In ignorance I used the one that downloads from web. The web 
page can possibly be mucho improved! :-)




It didn't work. Sorry I didn't check where it pointed, but it started 
searching for some [index.html]. I found that file by manual searching, 
plugged it in manual in the search that the link brought up, and all's 
well that ends well, but this is DEFINITELY an improvement opportunity!




The name [link.exe] conflicts with Microsoft's linker. Please name it 
[optlink.exe]. I just renamed it and fixed the options file, but this is 
not just an improvement opportunity, it's more on the MUST end of the 
scale: it is very impractical to have such a needless name clash.




Why have "-quiet" for the compiler and "-nologo" for the linker? 
Standardizing options across the toolset is a very nice improvement 
opportunity. Also, it would be nice if the linker refrained from 
reporting all about itself when it encounters an error.




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>


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


Cheers & hth.,

- Alf (at very beginning of checking out the D language)
Feb 12 2012
next sibling parent Brad Anderson <eco gnuk.net> writes:
On Sun, Feb 12, 2012 at 5:02 PM, Alf P. Steinbach <
alf.p.steinbach+usenet gmail.com> wrote:


 Hi

 I just installed D 2.x.




 It was not clear to me that the first download is a full offline
 installer. In ignorance I used the one that downloads from web. The web
 page can possibly be mucho improved! :-)




 It didn't work. Sorry I didn't check where it pointed, but it started
 searching for some [index.html]. I found that file by manual searching,
 plugged it in manual in the search that the link brought up, and all's well
 that ends well, but this is DEFINITELY an improvement opportunity!


I'll look into this one and make a pull request.





 The name [link.exe] conflicts with Microsoft's linker. Please name it
 [optlink.exe]. I just renamed it and fixed the options file, but this is
 not just an improvement opportunity, it's more on the MUST end of the
 scale: it is very impractical to have such a needless name clash.




 Why have "-quiet" for the compiler and "-nologo" for the linker?
 Standardizing options across the toolset is a very nice improvement
 opportunity. Also, it would be nice if the linker refrained from reporting
 all about itself when it encounters an error.




 Following main site's links to [http://d-programming-**
 language.org/windows.html <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>


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


 Cheers & hth.,

 - Alf (at very beginning of checking out the D language)


Regards,
Brad Anderson
Feb 12 2012
prev sibling next sibling parent Brad Anderson <eco gnuk.net> writes:
On Sun, Feb 12, 2012 at 7:07 PM, Brad Anderson <eco gnuk.net> wrote:


 On Sun, Feb 12, 2012 at 5:02 PM, Alf P. Steinbach <
 alf.p.steinbach+usenet gmail.com> wrote:


 Hi

 I just installed D 2.x.




 It was not clear to me that the first download is a full offline
 installer. In ignorance I used the one that downloads from web. The web
 page can possibly be mucho improved! :-)




 It didn't work. Sorry I didn't check where it pointed, but it started
 searching for some [index.html]. I found that file by manual searching,
 plugged it in manual in the search that the link brought up, and all's well
 that ends well, but this is DEFINITELY an improvement opportunity!


 I'll look into this one and make a pull request.


https://github.com/D-Programming-Language/installer/pull/6

The Start Menu "Documentation" link was to the D1 documentation.  If you
didn't install D1 the link was broken.


I have two other pull requests for the installer:
https://github.com/D-Programming-Language/installer/pull/5 : Replace
default NSIS welcome/finish graphic with custom D graphics
https://github.com/D-Programming-Language/installer/pull/4 : Make D1
unchecked by default

It'd be nice if all three of these could get merged before 2.058.

Regards,
Brad Anderson





 The name [link.exe] conflicts with Microsoft's linker. Please name it
 [optlink.exe]. I just renamed it and fixed the options file, but this is
 not just an improvement opportunity, it's more on the MUST end of the
 scale: it is very impractical to have such a needless name clash.




 Why have "-quiet" for the compiler and "-nologo" for the linker?
 Standardizing options across the toolset is a very nice improvement
 opportunity. Also, it would be nice if the linker refrained from reporting
 all about itself when it encounters an error.




 Following main site's links to [http://d-programming-**
 language.org/windows.html<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>


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


 Cheers & hth.,

 - Alf (at very beginning of checking out the D language)


 Regards,
 Brad Anderson
Feb 12 2012
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
Hi Alf! Welcome!

On 2/12/2012 4:02 PM, Alf P. Steinbach wrote:

 Hi

 I just installed D 2.x.




 It was not clear to me that the first download is a full offline installer. In
 ignorance I used the one that downloads from web. The web page can possibly be
 mucho improved! :-)




 It didn't work. Sorry I didn't check where it pointed, but it started searching
 for some [index.html]. I found that file by manual searching, plugged it in
 manual in the search that the link brought up, and all's well that ends well,
 but this is DEFINITELY an improvement opportunity!




 The name [link.exe] conflicts with Microsoft's linker. Please name it
 [optlink.exe]. I just renamed it and fixed the options file, but this is not
 just an improvement opportunity, it's more on the MUST end of the scale: it is
 very impractical to have such a needless name clash.


Having clashes with programs from other vendors is a constant problem. Even 
having clashes with our own programs is, as people often wish to keep multiple 
versions installed.

This is why we switched away from relying solely on environment variables, such 
as PATH, to find the programs and set options. Instead, sc.ini is used:

   http://www.d-programming-language.org/dmd-windows.html#sc_ini

to set where the programs and libraries are to be found.





 Why have "-quiet" for the compiler and "-nologo" for the linker? Standardizing
 options across the toolset is a very nice improvement opportunity.


That's a good idea. Optlink has several anachronisms in it due to it having a 
long history.



 Also, it
 would be nice if the linker refrained from reporting all about itself when it
 encounters an error.


That's there so it's easy for users to cut&paste the error and also get the 
correct linker version, etc., when asking for help.





 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>


 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. 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.



 - 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.
Feb 13 2012
next sibling parent reply Vincent <thornik gmail.com> writes:


 The name [link.exe] conflicts with Microsoft's linker. Please name it
[optlink.exe].





 This is why we switched away from relying solely on environment variables, such
 as PATH, to find the programs and set options. Instead, sc.ini is used:


Hi, Walter!
I support Alf in renaming initiative. Even if you were so smart to use sc.ini,
other vedors are not!
I put dmd/bin in PATH where dmd.exe can be found (obvious solution), BUT
link.exe sit at the same place!
Despite what dmd.exe uses, MS tools will catch wrong link.exe or dmd will catch
MS' link.exe (if you put MS tools first in PATH).
So it's MUCH easier to rename link.exe (it's not a trademark, what a problem!),
than spreading curses every time you get strange error from compiler.
Situation is that MS is dominating on the market, so DM should adapt its tools
to be most painless after you add 'em on computer.

Good luck!
Feb 14 2012
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 2/14/2012 12:50 AM, Vincent wrote:



 The name [link.exe] conflicts with Microsoft's linker. Please name it
 [optlink.exe].





 This is why we switched away from relying solely on environment variables, such
 as PATH, to find the programs and set options. Instead, sc.ini is used:


 Hi, Walter!
 I support Alf in renaming initiative. Even if you were so smart to use sc.ini,
 other vedors are not!


It's fine if they do not, as sc.ini is designed to override any path set in the 
environment.



 I put dmd/bin in PATH where dmd.exe can be found (obvious solution), BUT
 link.exe sit at the same place!
 Despite what dmd.exe uses, MS tools will catch wrong link.exe or dmd will catch
 MS' link.exe (if you put MS tools first in PATH).
 So it's MUCH easier to rename link.exe (it's not a trademark, what a problem!),
 than spreading curses every time you get strange error from compiler.
 Situation is that MS is dominating on the market, so DM should adapt its tools
 to be most painless after you add 'em on computer.

 Good luck!


I am loathe to break 20+ years of working makefiles.

But there is a simple solution for your case. Create a batch file, dmd.bat,
with 
the contents:

    c:\dmd\windows\bin\dmd %1 %2 %3 %4

and put it somewhere in your PATH. Then, dmd will run the correct dmd.exe 
without it being on the PATH, and it will find the correct link.exe (because of 
sc.ini). Meanwhile, if you just type link, it will find your MS-LINK.

But what most people do is have multiple .bat files, one for each compiler, to 
switcheroo the environment for the compiler they wish to use at the moment. 
After all, it isn't just link.exe. It's all the tools, the .h files, the
library 
files, etc.
Feb 14 2012
next sibling parent "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Tuesday, 14 February 2012 at 09:04:50 UTC, Walter Bright wrote:

 But there is a simple solution for your case. Create a batch 
 file, dmd.bat, with the contents:

   c:\dmd\windows\bin\dmd %1 %2 %3 %4


I would suggest replacing "%1 %2 %3 %4" with "%*".


 But what most people do is have multiple .bat files, one for 
 each compiler, to switcheroo the environment for the compiler 
 they wish to use at the moment. After all, it isn't just 
 link.exe. It's all the tools, the .h files, the library files, 
 etc.


For myself, I've written a plugin for my preferred file manager:

https://github.com/CyberShadow/EnvMan
Feb 14 2012
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-02-14 10:04, Walter Bright wrote:

 On 2/14/2012 12:50 AM, Vincent wrote:



 The name [link.exe] conflicts with Microsoft's linker. Please name it
 [optlink.exe].





 This is why we switched away from relying solely on environment
 variables, such
 as PATH, to find the programs and set options. Instead, sc.ini is used:


 Hi, Walter!
 I support Alf in renaming initiative. Even if you were so smart to use
 sc.ini,
 other vedors are not!


 It's fine if they do not, as sc.ini is designed to override any path set
 in the environment.



 I put dmd/bin in PATH where dmd.exe can be found (obvious solution), BUT
 link.exe sit at the same place!
 Despite what dmd.exe uses, MS tools will catch wrong link.exe or dmd
 will catch
 MS' link.exe (if you put MS tools first in PATH).
 So it's MUCH easier to rename link.exe (it's not a trademark, what a
 problem!),
 than spreading curses every time you get strange error from compiler.
 Situation is that MS is dominating on the market, so DM should adapt
 its tools
 to be most painless after you add 'em on computer.

 Good luck!


 I am loathe to break 20+ years of working makefiles.

 But there is a simple solution for your case. Create a batch file,
 dmd.bat, with the contents:

 c:\dmd\windows\bin\dmd %1 %2 %3 %4

 and put it somewhere in your PATH. Then, dmd will run the correct
 dmd.exe without it being on the PATH, and it will find the correct
 link.exe (because of sc.ini). Meanwhile, if you just type link, it will
 find your MS-LINK.

 But what most people do is have multiple .bat files, one for each
 compiler, to switcheroo the environment for the compiler they wish to
 use at the moment. After all, it isn't just link.exe. It's all the
 tools, the .h files, the library files, etc.


For that problem we have DVM: https://bitbucket.org/doob/dvm

-- 
/Jacob Carlborg
Feb 14 2012
prev sibling next sibling parent Sean Kelly <sean invisibleduck.org> writes:
It does help that Visual Studio ships with a batch file to open a console co=
nfigured for using vc++. Just don't use that when working on D apps.=20

On Feb 14, 2012, at 1:04 AM, Walter Bright <newshound2 digitalmars.com> wrot=
e:


 On 2/14/2012 12:50 AM, Vincent wrote:


=20
 The name [link.exe] conflicts with Microsoft's linker. Please name it
 [optlink.exe].




=20

 This is why we switched away from relying solely on environment variable=






s, such

 as PATH, to find the programs and set options. Instead, sc.ini is used:


=20
 Hi, Walter!
 I support Alf in renaming initiative. Even if you were so smart to use sc=




.ini,

 other vedors are not!


=20
 It's fine if they do not, as sc.ini is designed to override any path set i=


n the environment.

=20
=20

 I put dmd/bin in PATH where dmd.exe can be found (obvious solution), BUT
 link.exe sit at the same place!
 Despite what dmd.exe uses, MS tools will catch wrong link.exe or dmd will=




 catch

 MS' link.exe (if you put MS tools first in PATH).
 So it's MUCH easier to rename link.exe (it's not a trademark, what a prob=




lem!),

 than spreading curses every time you get strange error from compiler.
 Situation is that MS is dominating on the market, so DM should adapt its t=




ools

 to be most painless after you add 'em on computer.
=20
 Good luck!


=20
 I am loathe to break 20+ years of working makefiles.
=20
 But there is a simple solution for your case. Create a batch file, dmd.bat=


, with the contents:

=20
   c:\dmd\windows\bin\dmd %1 %2 %3 %4
=20
 and put it somewhere in your PATH. Then, dmd will run the correct dmd.exe w=


ithout it being on the PATH, and it will find the correct link.exe (because o=
f sc.ini). Meanwhile, if you just type link, it will find your MS-LINK.

=20
 But what most people do is have multiple .bat files, one for each compiler=


, to switcheroo the environment for the compiler they wish to use at the mom=
ent. After all, it isn't just link.exe. It's all the tools, the .h files, th=
e library files, etc.

=20
Feb 14 2012
prev sibling parent Brad Anderson <eco gnuk.net> writes:
On Tue, Feb 14, 2012 at 9:40 AM, Sean Kelly <sean invisibleduck.org> wrote:


 It does help that Visual Studio ships with a batch file to open a console
 configured for using vc++. Just don't use that when working on D apps.


While fixing up some PATH setting issues with the installer I've wondered
if a similar batch file for D would be helpful to anyone.  Is there any
interest in that option?  I'd probably change the installer to make setting
the PATH optional if I added that.  Right now there is no indication that
the installer is going to change your path which is a bit rude (especially
when the installer used to fail and erase the entire PATH in some cases).

Regards,
Brad Anderson



 On Feb 14, 2012, at 1:04 AM, Walter Bright <newshound2 digitalmars.com>
 wrote:


 On 2/14/2012 12:50 AM, Vincent wrote:



 The name [link.exe] conflicts with Microsoft's linker. Please name it
 [optlink.exe].





 This is why we switched away from relying solely on environment






 variables, such

 as PATH, to find the programs and set options. Instead, sc.ini is used:


 Hi, Walter!
 I support Alf in renaming initiative. Even if you were so smart to use




 sc.ini,

 other vedors are not!


 It's fine if they do not, as sc.ini is designed to override any path set


 in the environment.

 I put dmd/bin in PATH where dmd.exe can be found (obvious solution), BUT
 link.exe sit at the same place!
 Despite what dmd.exe uses, MS tools will catch wrong link.exe or dmd




 will catch

 MS' link.exe (if you put MS tools first in PATH).
 So it's MUCH easier to rename link.exe (it's not a trademark, what a




 problem!),

 than spreading curses every time you get strange error from compiler.
 Situation is that MS is dominating on the market, so DM should adapt




 its tools

 to be most painless after you add 'em on computer.

 Good luck!


 I am loathe to break 20+ years of working makefiles.

 But there is a simple solution for your case. Create a batch file,


 dmd.bat, with the contents:

   c:\dmd\windows\bin\dmd %1 %2 %3 %4

 and put it somewhere in your PATH. Then, dmd will run the correct


 dmd.exe without it being on the PATH, and it will find the correct link.exe
 (because of sc.ini). Meanwhile, if you just type link, it will find your
 MS-LINK.

 But what most people do is have multiple .bat files, one for each


 compiler, to switcheroo the environment for the compiler they wish to use
 at the moment. After all, it isn't just link.exe. It's all the tools, the
 .h files, the library files, etc.







 Feb 14 2012



prev sibling  parent reply "Alf P. Steinbach" <alf.p.steinbach+usenet gmail.com>  writes:


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]



 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



 Feb 14 2012



 next sibling parent  Andrej Mitrovic <andrej.mitrovich gmail.com>  writes:


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'.



 Feb 14 2012



prev sibling next sibling parent reply =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com>  writes:


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



 Feb 14 2012



  parent  "Alf P. Steinbach" <alf.p.steinbach+usenet gmail.com>  writes:


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



 Feb 14 2012



prev sibling next sibling parent reply Sean Kelly <sean invisibleduck.org>  writes:


On Feb 14, 2012, at 11:45 AM, Alf P. Steinbach wrote:

=20
 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.

=20
 I do not yet know the valid signatures for a D standard `main`.
=20
 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.=



 Feb 14 2012



  parent  Walter Bright <newshound2 digitalmars.com>  writes:


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.



 Feb 14 2012



prev sibling  parent reply Walter Bright <newshound2 digitalmars.com>  writes:


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]



 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.



 Feb 14 2012



  parent  Mike Parker <aldacron gmail.com>  writes:


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...



 Feb 14 2012