View mode: basic / threaded / horizontal-split · Log in · Help
February 13, 2012
newbie - hey walter, improvement potentials for installer
Hi

I just installed D 2.x.


   * Improvement potential #1  --  installer description.

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


   * Improvement potential #2  --  Start menu link to help file.

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!


   * Improvement potential #3  --  Linker executable name.

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.


   * Improvement potential #4  --  Standard options for tools.

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.


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


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)
February 13, 2012
Re: newbie - hey walter, improvement potentials for installer
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.
>
>
>   * Improvement potential #1  --  installer description.
>
> 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! :-)
>
>
>   * Improvement potential #2  --  Start menu link to help file.
>
> 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.


>
>   * Improvement potential #3  --  Linker executable name.
>
> 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.
>
>
>   * Improvement potential #4  --  Standard options for tools.
>
> 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.
>
>
>  * Improvement potential #5  --  The description of Windows prog.
>
> 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
February 13, 2012
Re: newbie - hey walter, improvement potentials for installer
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.
>>
>>
>>   * Improvement potential #1  --  installer description.
>>
>> 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! :-)
>>
>>
>>   * Improvement potential #2  --  Start menu link to help file.
>>
>> 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


>
>
>>
>>   * Improvement potential #3  --  Linker executable name.
>>
>> 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.
>>
>>
>>   * Improvement potential #4  --  Standard options for tools.
>>
>> 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.
>>
>>
>>  * Improvement potential #5  --  The description of Windows prog.
>>
>> 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
>
February 13, 2012
Re: newbie - hey walter, improvement potentials for installer
Hi Alf! Welcome!

On 2/12/2012 4:02 PM, Alf P. Steinbach wrote:
> Hi
>
> I just installed D 2.x.
>
>
> * Improvement potential #1 -- installer description.
>
> 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! :-)
>
>
> * Improvement potential #2 -- Start menu link to help file.
>
> 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!
>
>
> * Improvement potential #3 -- Linker executable name.
>
> 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.


> * Improvement potential #4 -- Standard options for tools.
>
> 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.


> * 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>
>
>
> 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.
February 14, 2012
Re: newbie - hey walter, improvement potentials for installer
>> * Improvement potential #3 -- Linker executable name.
>>
>> 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!
February 14, 2012
Re: newbie - hey walter, improvement potentials for installer
On 2/14/2012 12:50 AM, Vincent wrote:
>>> * Improvement potential #3 -- Linker executable name.
>>>
>>> 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.
February 14, 2012
Re: newbie - hey walter, improvement potentials for installer
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
February 14, 2012
Re: newbie - hey walter, improvement potentials for installer
On 2012-02-14 10:04, Walter Bright wrote:
> On 2/14/2012 12:50 AM, Vincent wrote:
>>>> * Improvement potential #3 -- Linker executable name.
>>>>
>>>> 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
February 14, 2012
Re: newbie - hey walter, improvement potentials for installer
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. 

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

> On 2/14/2012 12:50 AM, Vincent wrote:
>>>> * Improvement potential #3 -- Linker executable name.
>>>> 
>>>> 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.
>
February 14, 2012
Re: newbie - hey walter, improvement potentials for installer
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:
> >>>> * Improvement potential #3 -- Linker executable name.
> >>>>
> >>>> 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.
> >
>
« First   ‹ Prev
1 2
Top | Discussion index | About this forum | D home