On Friday, 25 September 2015 at 09:03:35 UTC, John Colvin wrote:
> On Friday, 25 September 2015 at 00:25:54 UTC, Manu wrote:
>> I update DMD yesterday, it couldn't work out where it was installed and the uninstall fails, then complains and errors when trying to install over the failed uninstall, requiring manual intervention.
>>
>> [...]
>
> There seems to be a trend here:
> Windows devs have problems getting D to install/work correctly on their machines.
> Non-windows devs boot up windows and test it and it works fine for them (In this case that was me).

Thousands of developers download and use the installer just fine. Right after Walter added 64-bit support it was a chore for each developer to get it working but it's designed to Just Work these days (Martin even recently made it offer to download Visual Studio and install it for you). I don't think this is a Windows-dev vs non-Windows-dev issue, it's an atypical setup issue. There is also a history of the installer not being very good years ago so some of the veteran D users have an understandable bias against it.

> I seriously doubt that much progress will be made here unless some dedicated full-time modern Windows developers take over or at least significantly help with the installer code. Someone like you has years of experience and knowledge about what are good/bad solutions on windows, what workarounds/hacks are OK and which will be abhorrent to users, what will likely break in newer versions of windows/VS etc. etc. etc.
>
> Realistically, no-one except an experienced full-time windows developer is ever going to get this right.

That's kind of what happened. I started using D and the installer sucked. I'm no NSIS ninja but I do use NSIS for our commercial product at work so I was somewhat familiar with it and slowly made improvements to it. Rainer, Martin, and Vladimir all contributed things too. Personally I think it's in great shape these days. I can't think of a single thing I'd change about it. It's simple and svelte but does everything it needs to (and doesn't take 10 minutes to install). The only thing that I'd like to see is Code Signing of the installer and the executables/binaries included but that requires someone higher up on the foodchain than me to do (perhaps we can finally get it when the D Foundation is in place).

On 25 September 2015 at 22:17, Kagamin via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Friday, 25 September 2015 at 09:03:35 UTC, John Colvin wrote:
>>
>> Realistically, no-one except an experienced full-time windows developer is ever going to get this right.
>
>
> It's not a simple tradeoff: Manu's usual requirement is that dmd must work at the utmost ease of use even if heavens crash. Correct behavior is possible, but the question is how much user experience he would like to sacrifice for correctness.

This is because I am constantly introducing new users to D, and even
more important when those users are colleagues in my workplace.
If I talk about how cool D is, then point them at the website where
they proceed to download and install the compiler, and their
experience is immediately hindered by difficulty to configure within
seconds of exposure, this paints a bad first impression, and
frustratingly, it also reflects badly on *me* for recommending it;
they're mostly convinced I'm some ridiculous fanboy (they're probably
right). This is based exclusively on their experience and
first-impressions. These basic things really matter!

Understand; people with no vested interest in D, and likely some
long-term resistance to every new trend in the software world jumping
up and down fighting for their attention (which includes fanboys like
me!), will not be impressed unless the experience is efficient and
relatively seamless.
I'm talking about appealing to potential end-users, not enthusiasts.
My experience is, over and over again, for years now, that these tiny
little things **REALLY MATTER**, more than literally anything else. If
they're turned away by first impressions, then literally nothing else
matters, and you rarely get a second chance; people don't tend to
revisit something they've written off in the past.

On 26 September 2015 at 02:06, Dicebot via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Friday, 25 September 2015 at 15:40:54 UTC, Kagamin wrote:
>>
>> On Friday, 25 September 2015 at 13:03:47 UTC, Dicebot wrote:
>>>
>>> Hm, so is the correct approach on Windows to provide separate shell for each application that has console utilities? X_x
>>
>>
>> If tools conflict, they need a form of isolation. Like... make install 3 versions of gcc on your system and make them work.
>
>
> What causes conflict? Is it just optilink? Maybe it would be more reasonable to simply rename it to something less generic? DMD doesn't look like something that inherently requires isolation.

Renaming optlink to optlink.exe would have solved one problem in this case.

> Taking your example, installing 3 versions of gcc simultaneously is not that problematic if you don't need them all to be called `gcc`.

Yeah, GCC has strategy here, toolchains all have a prefix that distinguishes them.

On 26 September 2015 at 02:30, Jonathan M Davis via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Friday, 25 September 2015 at 16:06:44 UTC, Kagamin wrote:
>>
>> I suppose, PATH variable on windows works the same as on unix? And path hell can be easily reproduced on unix too. Nothing windows-specific here.
>
>
> AFAIK, PATH on Windows works basically the same as it does on *nix, but a big difference is that on *nix, there are generally some very specific places where programs go, and almost nothing needs to touch PATH - e.g. a binary is usually going to be in /bin, /usr/bin, or /usr/local/bin, all of which are likely to be in your PATH variable. And if you installed something as your user, then you'd generally put the binary (or a symlink to it) in ~/bin. Windows really doesn't have anything like bin. Everything gets installed in its own directory (usually under Program Files), and if you want it to be usable on the command line, you have to add it to PATH. And since all of these programs are separate, they can have executables with the same name (e.g. link.exe), whereas that's much less likely on *nix, because almost all executables get installed to one of a few bin directories. So, you won't even end up installing conflicting binaries, because they'd overwrite each other.
>
> I really don't know what the "correct" way to deal with this is in Windows, but the way that it's set up does seem to naturally cause more problems with PATH than you typically get in *nix.

I think the biggest problem with PATH in windows in general is that
windows doesn't have dependency management.
As a result, every time you ship a program in windows, you need to
bundle it together with every other program it depends on. This leads
to hundreds of instances of exactly the same thing littered all over
the place, and as soon as more than one of those places enters the
PATH environment, then you have potential conflicts, and ordering
issues.

Windows is just a terrible operating system and I wish it would die already, but OSS just can't get a reasonable Microsoft Office, Photoshop, or Visual Studio alternative together. I don't even care if it's free, I'd pay good money for a linux version of each of these programs, they just have to exist.

On 9/25/2015 6:03 AM, Dicebot wrote:
> Hm, so is the correct approach on Windows to provide separate shell for each
> application that has console utilities? X_x

VS 10 does that, and I find it highly annoying. It sets a zillion environment variables that I have no idea what they are for or what they do. Evidently, this is the modern way, though I find it very unfriendly.

DMC++ is designed to work without any environment variables at all. (It uses sc.ini to find where things are.) It was the only compiler of its day that did not require any installation, it would run off of the CD.

The real problem is that DMD for Win64 requires some VS components. With every new release of VS, Microsoft throws every library and executable at a dart board and moves them to those random new directories.

But I also do not understand why professional developers have such a hard time understanding what PATH is and apparently have no idea where the libraries exist on their system or how to find out where they are.

On 9/25/2015 6:39 PM, Manu via Digitalmars-d wrote:
> Renaming optlink to optlink.exe would have solved one problem in this case.

Renaming it where?

Your posts are always tantalizing in that they leave out just enough information to ensure I can do nothing to help :-(

On 26 September 2015 at 09:15, Brad Anderson via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Friday, 25 September 2015 at 00:25:54 UTC, Manu wrote:
>>
>> I update DMD yesterday, it couldn't work out where it was installed and the uninstall fails, then complains and errors when trying to install over the failed uninstall, requiring manual intervention.
>>
>> Then I try and build with LDC, it can't link anymore because paths are
>> messed up and when looking for link.exe (microsoft's linker) it finds
>> optlink link.exe instead.
>> I tried to use a tool in VisualD which disassembles some code, but it
>> can't find the tools it needs to do the job!
>>
>> This is silly. I don't know how such simple things can be so consistently
>> hard?!
>> My first and most frequent problems with the D ecosystem were pathing
>> issues, and that's still more-or-less the case today.
>>
>> It's been 6 years for me. I'm getting tired. Can we please make an effort to get the paths right? This might mean some intelligence is required to make it work; check if the tool is the right tool? If it's not, keep looking? If tools can't be found, produce a dialog box prompting the user to supply the proper path to the tool? MSVC interaction (DMD-COFF and LDC) should probably leverage Microsoft's command line scripts, which are located in reliable places, and work reliably. MSCV associated tools shouldn't be capable of finding optlink by mistake.
>>
>> As a rule, no tool should ever require a windows user to interact with their path variable. It's a colossal mess, windows doesn't do 'PATH'. Mine has an endless list of bin directories, and many/most of them provide duplicates of the same programs. A robust program can never rely on PATH.
>>
>> [snip]
>>
>> This is minimal compared to my home dev environment (ie, is a
>> controlled office PC).
>> Surely this is evidence enough to conclude that no tool should *EVER*
>> refer to PATH to find tools?
>
>
> dmd, as it is installed, doesn't. The installer does detect and set the direct paths for all of the Visual C integration with sc.ini. It uses the values set by Visual C in the Windows registry. It's designed to be idiot proof. It doesn't touch the system/user PATH environment variable for this purpose (just the PATH dmd itself uses). The installer can optionally update the PATH to add dmd (years ago I also added a Visual C Command Window style shortcut to the installer for users that didn't want to change their PATH).
>
> Take a look at the current sc.ini[1]. It describes how it all works. You never have to change your system/user PATH to get anything to work.

Yeah, I think the only one of my complaints in this case that affected
the DMD installer was the uninstallation issue.
It looks like Rainer may have recently fixed this, which is great.

>> The installer should remember where it installed last time!
>
>
> I just use the defaults so I've never bothered to implement this. Pull requests welcome, of course. Sounds trivial.
>
>> This requires action from every tool in the ecosystem, to include a little bit of logic that allows it to validate that paths are configured correctly and that the program _works_, and do something useful or ideally *helpful* if they're not.
>
>
> Perhaps there are problems in LDC and VisualD but vanilla dmd has been pretty solid in this area for awhile now. Rainer just recently added support for VS2015. I'm not sure if it's in the latest release.
>
> Perhaps you could share your sc.ini and some more information about the uninstall error you hit. It's kind of difficult to fix any bugs when the description is vague and you seem to be the only one experiencing it.
>
> 1. https://github.com/D-Programming-Language/dmd/blob/master/ini/windows/bin/sc.ini#L31

My sc.ini is whatever the installer wrote. It works, and it's uneventful.
DMD is working well for me for over a year or so, uninstallation issue
aside. I have come to find DMD reliable in recent years. I think LDC
is the most important toolchain moving forward though, and that needs
all the love it can get.
I wonder if the DMD installer could be repurposed for LDC to use too?
The path wrangling would be equally useful to LDC I think, since it
depends on MSVC too.

On 9/25/2015 8:23 PM, Walter Bright wrote:
> On 9/25/2015 6:39 PM, Manu via Digitalmars-d wrote:
>> Renaming optlink to optlink.exe would have solved one problem in this case.
>
> Renaming it where?
>
> Your posts are always tantalizing in that they leave out just enough information
> to ensure I can do nothing to help :-(

Oh, I see, you mean rename the executable.

   https://issues.dlang.org/show_bug.cgi?id=15118

You can greatly help ease the problems you're having by filing bug reports like this for every last one of the usability issues you run into.

On 26 September 2015 at 13:20, Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On 9/25/2015 6:03 AM, Dicebot wrote:
>>
>> Hm, so is the correct approach on Windows to provide separate shell for
>> each
>> application that has console utilities? X_x
>
>
> VS 10 does that, and I find it highly annoying. It sets a zillion environment variables that I have no idea what they are for or what they do. Evidently, this is the modern way, though I find it very unfriendly.

It's horrible, but the alternative is demonstrably worse.

> DMC++ is designed to work without any environment variables at all. (It uses sc.ini to find where things are.) It was the only compiler of its day that did not require any installation, it would run off of the CD.

Fwiw, DMD is working great these days. It's just that I mostly use LDC now.

> The real problem is that DMD for Win64 requires some VS components. With every new release of VS, Microsoft throws every library and executable at a dart board and moves them to those random new directories.

Yup, PITA, but DMD is doing well with this, and LDC needs the same attention.

> But I also do not understand why professional developers have such a hard time understanding what PATH is and apparently have no idea where the libraries exist on their system or how to find out where they are.

It's not that, as I've tried to convey so many times before, it's all
about the impression it makes. Is it one of quality and reliability?
People don't like having their working time wasted. The only way I can
get people to take a look at D is as an opportunistic aside, where
people might humor my endless ranting, check it out, and see if it
appeals to them. It's never something that presents itself to them as
a task they must do to get their job done, D is not that prolific.
If they're speculatively trialing a new technology (especially since
it's hyped), it has about 3 minutes to make a positive impression on
them, and create a perception that it may make their working life
easier and better, or at the very least, get them excited such that it
retains their attention past 3 minutes and they pursue it further.
This is a matter of human psychology, and has nothing to do with D
itself other than the way in which it makes its first impressions on
new users.
I have no clear suggestions, other than this should be held high in
consideration when thinking about strategy for D moving forward.

Editing the path variable is one of the most unenjoyable and annoying things to do in windows. start -> settings -> system -> advanced system settings -> environment variables -> PATH -> note the stupid window that appears; a single-line text box created in 1995 (or earlier?), which barely lets you see a single path in a line that's probably a few kb long... whenever you touch it, you know you're likely breaking something on your system that currently works ;) People do it if they have to; in my current case, dev's MUST setup emscripten to build the web frontend, and they proceed to complain about how shit the toolchain experience is, but they are forced to use it regardless... nobody is forced to use D. They must find themselves actively drawn to use D.

This is my experience over many years now. The toolchain and compiler are now more-or-less sufficiently stable that anyone writing code will have a good experience. I believe it's the little things that matter more than anything in 2015.

On 26 September 2015 at 13:29, Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On 9/25/2015 8:23 PM, Walter Bright wrote:
>>
>> On 9/25/2015 6:39 PM, Manu via Digitalmars-d wrote:
>>>
>>> Renaming optlink to optlink.exe would have solved one problem in this case.
>>
>>
>> Renaming it where?
>>
>> Your posts are always tantalizing in that they leave out just enough
>> information
>> to ensure I can do nothing to help :-(
>
>
> Oh, I see, you mean rename the executable.
>
>    https://issues.dlang.org/show_bug.cgi?id=15118

Wow. Yeah, it never occurred to me that renaming a tool that has been around for 10s of years was a reasonable thing to expect ;)

Incidentally, I have encountered the same problem with the make.exe in the dmd/bin. It seems to be non-standard.


> You can greatly help ease the problems you're having by filing bug reports like this for every last one of the usability issues you run into.

I did file each one yesterday as I encountered these problems. My post
was about something slightly different though, I just want to try and
bring it to attention again that the little things matter more than
the attention they tend to get.
I think it's important to realise that the ecosystem is taken in
aggregate. DMD can do a great job of this stuff, but if LDC doesn't
have the same love, it's 'D' in general that gets the blame.

Out of curiosity, what is the strategy wrt LDC and GDC moving forward?
Will they move towards simultaneous releases? Will they be included in
CI builds, such that PR's which break (or don't work) the other
compilers do fail CI?
GDC as a culture has different packaging expectations so I don't think
it's affected so much, but especially for Windows users LDC is the way
forward, and it should be as solid as DMD in terms of presentation.