On Sunday, 29 October 2017 at 02:09:31 UTC, 12345swordy wrote:
>
> It seems to me that you have a major case of anti-windows bias here, as I never have any issues on my main windows machine.

Well, throughout this discussion, I have documented *my* experience (not yours) of getting 64bit D on a fresh install of Windows 7. That was my only objective.

I'm really not anti-windows. Windows XP is still one of favourite all time os's!

I'm not anti-microsoft either...they have some good stuff too.... I wish they'd get .NET core working on FreeBSD properly though...as I like playing with C# too...

What I am, is:

anti-bloat
anti-too-many-unecessary-dependencies
anti you-have-no-choice-but-to-download-GB's-stuff-you-really-don't-need

This is not specific to Windows by the looks of the discussion.

Apple has similar demands of you apparently (with Xcode).

I think it can and should be done better...that's the point I'm really trying to get (push) across. I'm shocked that so many seem to disagree.

The modularisation of the VS install process helps a little (if you can get your head around how it works)...but there are still too many dependencies...and the whole experience should be streamlined a lot more...

Many developers these days learn to program in these bloated IDE's..and they are used to it..I get that. I learnt to program in C, using vi ;-)

I guess different experiences lead to different expectations.

On Saturday, 28 October 2017 at 07:39:21 UTC, codephantom wrote:
> It's the *minimum* 'selection set' you'll need (with regards to the Visual Studio Build Tools 2017) in order to get DMD to sucessfully compile a 64bit exe (-m64)
>
> Now to be fair, this is assuming you **don't** want and **don't** have VS installed, but just want the necessary 'build tools' so that DMD can build a *64bit* binary on Windows - (in total about 3.5GB).
>
>
> Code tools
> 	Static analysis tools
>
> Compilers, build tools, and runtimes
> 	VC++ 2017 v141 toolset (x86,x64)
>
> SDK's, libraries and frameworks
> 	Windows 10 SDK (10.0.16299.0) for Desktop C++ [x86 and x64]
> 	Windows 10 SDK (10.0.16299.0) for UWP: C#, VB, JS
> 	Windows 10 SDK (10.0.16299.0) for UWP: C++


I need to correct my statement above (it was late at night ;-)

The actual download size was 977MB
The installed size was 3.5GB

On Sunday, 29 October 2017 at 02:09:31 UTC, 12345swordy wrote:
> It seems to me that you have a major case of anti-windows bias here, as I never have any issues on my main windows machine.

Actually, it's the very opposite...I'm strongly arguing 'for' D on Windows.

(otherwise I wouldn't have wasted my time with this).

If you're ok with having VS, then that is not too much of pain to install..I get it.

But if you don't want VS, then it really is a pain. You have to work out what is the min required components....all by yourself - like i had to do. That really was a pain!

I want D on Windows (64bit included), and I want it to be a better experience than what I had...that's been the whole point of my involvement in the discussion.

In essence, I'm an advocate for D on Windows ;-)

(but to do that, without being forced to advocate for VS as well..is kinda challenging..it seems)

It's D I'm interested in. Not VS.

On Sunday, 29 October 2017 at 03:46:35 UTC, codephantom wrote:
> It's D I'm interested in. Not VS.

btw. since this thread has gone way off topic... I'd suggest this one instead:

https://forum.dlang.org/thread/xwuxfcdaqkcealxzgmqk@forum.dlang.org

On Wednesday, 25 October 2017 at 22:46:27 UTC, Adam Wilson wrote:
> On 10/25/17 11:23, H. S. Teoh wrote:
>> On Wed, Oct 25, 2017 at 08:17:21AM -0600, Jonathan M Davis via Digitalmars-d wrote:
>>> [...]
>> [...]
>>
>> Yeah.  There have been timing attacks against otherwise-secure crypto
>> algorithms that allow extraction of the decryption key.  And other
>> side-channel attacks along the lines of CRIME or BREACH.  Even CPU
>> instruction timing attacks have been discovered that can leak which path
>> a branch in a crypto algorithm took, which in turn can reveal
>> information about the decryption key.  And voltage variations to deduce
>> which bit(s) are 1's and which are 0's.  Many of these remain
>> theoretical attacks, but the point is that these weaknesses can come
>> from things you wouldn't even know existed in your code. Crypto code
>> must be subject to a LOT of scrutiny before it can be trusted. And not
>> just cursory scrutiny like we do with the PR queue on github; we're
>> talking about possibly instruction-by-instruction scrutiny of the kind
>> that can discover vulnerabilities to timing or voltage.
>>
>> I would not be comfortable entrusting any important data to D crypto
>> algorithms if they have not been thoroughly reviewed.
>>
>>
>> T
>>
>
> I am one-hundred-ten percent in agreement with Mr. Teoh here. Even .NET Framework and Core forward to the highly vetted system crypto API's (SChannel on Windows and OpenSSL on Linux/macOS). If you need RSA crypto in D, pull in OpenSSL. Period. Everything else is a good way to run afoul of a security audit, and potentially expose yourself.
>
> Phobos could forward to these system provided API's like .NET does and provide an idiomatic D interface, but Phobos itself should absolutely and 110% stay out of the crypto implementation business.

I think you made a very good point, it was also mentioned by someone else in this thread. Phobos could provide a crypto interface with implementions for SChannel, mbedtls, openssl.
On Windows SChannel would be used as default implementation and on the other operation systems either openssl or mbedtls.
This would be very convenient and we would avoid opening the Pandora box.

I will close my issue and create a new one with the request for a crypto interface in Phobos.

Kind regards
Andre

On Sunday, 29 October 2017 at 03:46:35 UTC, codephantom wrote:
> On Sunday, 29 October 2017 at 02:09:31 UTC, 12345swordy wrote:
>> It seems to me that you have a major case of anti-windows bias here, as I never have any issues on my main windows machine.
>
> Actually, it's the very opposite...I'm strongly arguing 'for' D on Windows.
>
> (otherwise I wouldn't have wasted my time with this).
>
> If you're ok with having VS, then that is not too much of pain to install..I get it.
>
> But if you don't want VS, then it really is a pain. You have to work out what is the min required components....all by yourself - like i had to do. That really was a pain!
>
> I want D on Windows (64bit included), and I want it to be a better experience than what I had...that's been the whole point of my involvement in the discussion.
>
> In essence, I'm an advocate for D on Windows ;-)
>
> (but to do that, without being forced to advocate for VS as well..is kinda challenging..it seems)
>
> It's D I'm interested in. Not VS.

Just a little answer so that you see that you're not alone with your concerns. I think you're absolutely right and that your experiment was nicely done and clear from the beginning what it was about. Reading is a skill that some people seem to have problems with.
To my experience now. I finally managed to install VS2017 by doing essentially the sleep during download thing to get the offline installer. My Internet is not especially bad but not good either (5 Mb down, 1 Mb up ADSL with very fluctuating latencies) and the download took also several hours. For 1.6 GB it's really slow. It has probably more to do with the Microsoft download code than anything else (as the discussions in the link someone provided tend to show).
The good thing is that it is now possible to install VS2017 on a relatively small system partition, a thing that I didn't manage to do with VS2013 and VS2015. The DMD installer also had no problem to install the Visual-D plug-in and I managed to build my project in 32 and 64 bit.
This said, it's the whole VS experience that I'm really annoyed with. MS goes really out of its way to make the whole IDE as magical as possible, i.e. everything is set so that the gritty reality of code generation is hidden from the developer. The more it goes, the less obvious it gets to install unconventional things in the environment. Even simple stuff can become a real pain. For instance, I like to have visible white spaces when editing code (yeah, I hate tabs in program code). In all editors and IDE I have tried yet, it was easy to set, when not in an appearance toolbar, it's somewhere in "view" or "edit" menu. In VS, it was a chore to find and I had to customize a tool bar using 5 deep dialog box galore. Annoying. I can understand how and why MS do it that way. When you work a little bit longer with it, it is really sleek and nicely integrated in the system. The thing is, it that it removes the perspective of what really happens when building a program (object files, libs, linking etc.) and that's the reason why we get so regularely the complaints about the "Windows experience sucking": MS has nurtured a generation of devs who have no clue what building an app entails.
To conclude: if D wants to cater to that crowd, it will have to bite the bullet and make the Windows experience even smoother than it is now. You won't overcome Windows dev's Stockholm syndrome otherwise and Windows devs, should also peg down a little bit and learn that MS's way of doing things is far from being ideal (bloat, loss of control, changing specs every 3 years, programmed obsolescence (Active-X anyone?)).

On Sunday, 29 October 2017 at 10:21:22 UTC, Patrick Schluter wrote:
> Just a little answer so that you see that you're not alone with your concerns. I think you're absolutely right and that your experiment was nicely done and clear from the beginning what it was about. Reading is a skill that some people seem to have problems with.

Thanks for the support ;-)

btw. I was just experimenting with the Windows 7 SDK iso (a 570MB download)
https://www.microsoft.com/en-au/download/details.aspx?id=8442

From that ISO, I only need to install two components:
- Header and Libraries (only the x64 ones are needed) (~180MB)
- Visual C++ Compilers (~637MB)

The total disk space needed to install those 2 components is 810MB.

Then I can compile D using -m64

However DMD won't pick up the SDK during install, so I had to change these two settings in the sc.ini:

VCINSTALLDIR=C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\
WindowsSdkDir=C:\Program Files\Microsoft SDKs\Windows\v7.1\

To my surprise (not really knowing what I was doing), it all worked (so far), and apart from downloading the iso, you don't need to be connected to the internet during the install of the SDK...

The SDK requires you have .NET 4 installed first though, otherwise it won't let you install the Visual C++ Compilers.

btw. The min size if you use the VS 2017 build tools was 3.5GB installed.

So I have saved myself several gb of download, and several gb of disk space...just by using the Windows 7 SDK instead.

On Sunday, 29 October 2017 at 02:39:21 UTC, codephantom wrote:
> On Sunday, 29 October 2017 at 02:09:31 UTC, 12345swordy wrote:
>>
> What I am, is:
>
> anti-bloat
> anti-too-many-unecessary-dependencies
> anti you-have-no-choice-but-to-download-GB's-stuff-you-really-don't-need
>

How exactly do you know this? You never justify it! We are living in an age where we have terabytes harddrives! Hell, I even recall that gdb needs python for some strange reason, in my linux machines. I don't know WHY it requires it, but I wouldn't jump to conclusions and think it as "unnecessary-dependencies" simply because I don't understand the rational behind it.

On Sunday, October 29, 2017 16:14:11 12345swordy via Digitalmars-d wrote:
> On Sunday, 29 October 2017 at 02:39:21 UTC, codephantom wrote:
> > On Sunday, 29 October 2017 at 02:09:31 UTC, 12345swordy wrote:
> >
> > What I am, is:
> >
> > anti-bloat
> > anti-too-many-unecessary-dependencies
> > anti
> > you-have-no-choice-but-to-download-GB's-stuff-you-really-don't-need
>
> How exactly do you know this? You never justify it! We are living in an age where we have terabytes harddrives! Hell, I even recall that gdb needs python for some strange reason, in my linux machines. I don't know WHY it requires it, but I wouldn't jump to conclusions and think it as "unnecessary-dependencies" simply because I don't understand the rational behind it.

Really, it doesn't matter. Yes, it would be great if VS didn't take up as much space as it does. It would be great if Microsoft released stuff with the idea that the core compiler command-line tools were what mattered, and the IDE was just an add-on for those who care. I'm sure that we could all come up with reasons to complain about what Microsoft is doing - _lots_ of geeks love to complain about Microsoft.

What matters is that D needs to be able to link and interoperate with C/C++ code generated by Microsoft's compiler, because that's the primary compiler for Windows systems and what most everyone is using if they're developing on Windows. If we can do that in a way that minimizes what needs to be downloaded, then great. If we can't, then well, that sucks, but that's life.

While complaining about what Microsoft is doing with VS may be justified, it doesn't really help anything. I think that we'd all be better off if we just let this topic die.

- Jonathan M Davis

On Sunday, 29 October 2017 at 10:21:22 UTC, Patrick Schluter wrote:
> To conclude: if D wants to cater to that crowd, it will have to bite the bullet and make the Windows experience even smoother than it is now. You won't overcome Windows dev's Stockholm syndrome otherwise and Windows devs, should also peg down a little bit and learn that MS's way of doing things is far from being ideal (bloat, loss of control, changing specs every 3 years, programmed obsolescence (Active-X anyone?)).

Or better yet, don't bother with a dying platform full of whiny devs who are helpless without an IDE.  One of D's strengths is that it isn't architected for IDE-driven development and the oft-resulting verbosity, that's a market D should probably just leave alone.  Instead, focus on the current major platform which lets you use almost any toolchain you want:

http://forum.dlang.org/thread/xgiwhblmkvcgnsktjnoo@forum.dlang.org

Of course, it is admirable what Rainer and others do to maintain VisualD and other D tools for the Windows platform.  I just don't see it mattering much in the next decade.