Jump to page: 1 2
Thread overview
newbie - hey walter, improvement potentials for installer
Feb 13, 2012
Alf P. Steinbach
Feb 13, 2012
Brad Anderson
Feb 13, 2012
Brad Anderson
Feb 13, 2012
Walter Bright
Feb 14, 2012
Vincent
Feb 14, 2012
Walter Bright
Feb 14, 2012
Vladimir Panteleev
Feb 14, 2012
Jacob Carlborg
Feb 14, 2012
Sean Kelly
Feb 14, 2012
Brad Anderson
Feb 14, 2012
Alf P. Steinbach
Feb 14, 2012
Andrej Mitrovic
Feb 14, 2012
Ali Çehreli
Feb 14, 2012
Alf P. Steinbach
Feb 14, 2012
Sean Kelly
Feb 14, 2012
Walter Bright
Feb 14, 2012
Walter Bright
Feb 15, 2012
Mike Parker
February 13, 2012
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
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
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
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
>> * 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
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
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
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
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
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