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