www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - D Lang installation on Windows, dependency on Visual Studio?

reply AB <ab396356 users.sourceforge.net> writes:
Installing D 2.072.0 on Windows 7 64-bit. After installation is 
complete I get the following two error (warning?) messages, 
screenshots here:

http://imgur.com/a/5fydB

For your convenience they read as follows:

"Could not detect Visual Studio (2008-2015 are supported). No 
64-bit support."

"Could not detect Windows SDK (6.0A-10.0 are supported). No 
64-bit support."

So the above means that the DMD compiler will not be able to 
generate 64-bit executables on my system, because a third-party 
piece of software is missing? This is ridiculous, what does 
Visual Studio have to do with DMD and its capability to generate 
64-bit code?

"You wanted a banana but what you got was a gorilla holding the 
banana and the entire jungle."
Nov 14 2016
next sibling parent rikki cattermole <rikki cattermole.co.nz> writes:
On 14/11/2016 9:38 PM, AB wrote:
 Installing D 2.072.0 on Windows 7 64-bit. After installation is complete
 I get the following two error (warning?) messages, screenshots here:

 http://imgur.com/a/5fydB

 For your convenience they read as follows:

 "Could not detect Visual Studio (2008-2015 are supported). No 64-bit
 support."

 "Could not detect Windows SDK (6.0A-10.0 are supported). No 64-bit
 support."

 So the above means that the DMD compiler will not be able to generate
 64-bit executables on my system, because a third-party piece of software
 is missing? This is ridiculous, what does Visual Studio have to do with
 DMD and its capability to generate 64-bit code?

 "You wanted a banana but what you got was a gorilla holding the banana
 and the entire jungle."
Visual Studio automatically installs the MSVC tool chain which includes the linker, Microsoft's libc and of course import libraries for linking against. Which we use for 64bit and 32bit coff support. This is the systems official tool chain, it isn't all that rediculas. After all, it is what is "standard" for building c/c++ libraries on Windows, which is nice for you know compatibility reasons.
Nov 14 2016
prev sibling next sibling parent reply Kagamin <spam here.lot> writes:
On Monday, 14 November 2016 at 08:38:32 UTC, AB wrote:
 This is ridiculous, what does Visual Studio have to do with DMD 
 and its capability to generate 64-bit code?
DMD can generate 64-bit object files just fine, you only need to link them, and DMD can invoke ms linker for you, that's all.
Nov 14 2016
parent reply AB <ab396356 users.sourceforge.net> writes:
On Monday, 14 November 2016 at 09:06:18 UTC, Kagamin wrote:
 DMD can generate 64-bit object files just fine, you only need 
 to link them, and DMD can invoke ms linker for you, that's all.
It is unreasonable to pull in the many GBs of Visual Studio as a dependency only to use its 64-bit linker.
Nov 14 2016
next sibling parent reply John Colvin <john.loughran.colvin gmail.com> writes:
On Monday, 14 November 2016 at 09:33:48 UTC, AB wrote:
 On Monday, 14 November 2016 at 09:06:18 UTC, Kagamin wrote:
 DMD can generate 64-bit object files just fine, you only need 
 to link them, and DMD can invoke ms linker for you, that's all.
It is unreasonable to pull in the many GBs of Visual Studio as a dependency only to use its 64-bit linker.
It used to be a pain to install the microsoft toolchain without install VS. Now there is http://landinghub.visualstudio.com/visual-cpp-build-tools, perhaps we should be encouraging using that instead?
Nov 14 2016
parent reply Kagamin <spam here.lot> writes:
On Monday, 14 November 2016 at 09:51:39 UTC, John Colvin wrote:
 Now there is 
 http://landinghub.visualstudio.com/visual-cpp-build-tools, 
 perhaps we should be encouraging using that instead?
It's still 3gb, so one might want to delete unneeded stuff after installation, like arm tools and cross compilers.
Nov 14 2016
next sibling parent Mike Parker <aldacron gmail.com> writes:
On Monday, 14 November 2016 at 10:20:48 UTC, Kagamin wrote:
 On Monday, 14 November 2016 at 09:51:39 UTC, John Colvin wrote:
 Now there is 
 http://landinghub.visualstudio.com/visual-cpp-build-tools, 
 perhaps we should be encouraging using that instead?
It's still 3gb, so one might want to delete unneeded stuff after installation, like arm tools and cross compilers.
Doesn't the installer allow you to pick which bits to download?
Nov 14 2016
prev sibling parent reply AB <ab396356 users.sourceforge.net> writes:
On Monday, 14 November 2016 at 10:20:48 UTC, Kagamin wrote:
 On Monday, 14 November 2016 at 09:51:39 UTC, John Colvin wrote:
 Now there is 
 http://landinghub.visualstudio.com/visual-cpp-build-tools, 
 perhaps we should be encouraging using that instead?
It's still 3gb, so one might want to delete unneeded stuff after installation, like arm tools and cross compilers.
Are there plans to write a homebrew 64-bit linker for DMD? To this question I would appreciate an answer from the people who develop DMD itself and its 32-bit linker.
Nov 15 2016
parent reply Kagamin <spam here.lot> writes:
On Tuesday, 15 November 2016 at 10:31:23 UTC, AB wrote:
 Are there plans to write a homebrew 64-bit linker for DMD?
There are already ld from mingw and lld from llvm team.
Nov 15 2016
parent reply AB <ab396356 users.sourceforge.net> writes:
On Tuesday, 15 November 2016 at 11:28:16 UTC, Kagamin wrote:
 On Tuesday, 15 November 2016 at 10:31:23 UTC, AB wrote:
 Are there plans to write a homebrew 64-bit linker for DMD?
There are already ld from mingw and lld from llvm team.
Why aren't they used and distributed in DMD for Windows by default? If the tools mentioned above (LD and LLD) are available and usable on Windows x64 instead of the ones provided in heavily bloated packages by Microsoft, how come the DMD installer for Windows doesn't offer them as an alternative (or better yet as the default)?
Nov 15 2016
next sibling parent reply Daniel Kozak via Digitalmars-d <digitalmars-d puremagic.com> writes:
Dne 15.11.2016 v 14:23 AB via Digitalmars-d napsal(a):

 On Tuesday, 15 November 2016 at 11:28:16 UTC, Kagamin wrote:
 On Tuesday, 15 November 2016 at 10:31:23 UTC, AB wrote:
 Are there plans to write a homebrew 64-bit linker for DMD?
There are already ld from mingw and lld from llvm team.
Why aren't they used and distributed in DMD for Windows by default? If the tools mentioned above (LD and LLD) are available and usable on Windows x64 instead of the ones provided in heavily bloated packages by Microsoft, how come the DMD installer for Windows doesn't offer them as an alternative (or better yet as the default)?
AFAIK ld on mingw can`t link against mscoff file format so it is not very usable. LLD is quite new so I do not know how production ready is. But I believe LLD will be the answer in future. Btw. today I want to start working on a D project in work, but I cant, because there is not enoght space on C:\ partion and there is not possible to instal VS to another disk :( (Ok in few attempt of installing VS there has been path I can change but it does not work anyway, still VS is trying to install to C:\ ). So maybe one day I will be able to work at job on D windows project. Fortunately I can still work on other part (still in D) of project which is running on linux
Nov 15 2016
next sibling parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 16/11/2016 3:41 AM, Daniel Kozak via Digitalmars-d wrote:
 Dne 15.11.2016 v 14:23 AB via Digitalmars-d napsal(a):

 On Tuesday, 15 November 2016 at 11:28:16 UTC, Kagamin wrote:
 On Tuesday, 15 November 2016 at 10:31:23 UTC, AB wrote:
 Are there plans to write a homebrew 64-bit linker for DMD?
There are already ld from mingw and lld from llvm team.
Why aren't they used and distributed in DMD for Windows by default? If the tools mentioned above (LD and LLD) are available and usable on Windows x64 instead of the ones provided in heavily bloated packages by Microsoft, how come the DMD installer for Windows doesn't offer them as an alternative (or better yet as the default)?
AFAIK ld on mingw can`t link against mscoff file format so it is not very usable. LLD is quite new so I do not know how production ready is. But I believe LLD will be the answer in future.
From what I've read about LLD (~ 6+ months ago) the Windows implementation was a complete rewrite from the Linux support. It most definitely isn't production ready or we would have heard about it (after all e.g. OSX will want to shift over to it).
Nov 15 2016
parent Daniel Kozak via Digitalmars-d <digitalmars-d puremagic.com> writes:
Dne 16.11.2016 v 04:17 rikki cattermole via Digitalmars-d napsal(a):
 On 16/11/2016 3:41 AM, Daniel Kozak via Digitalmars-d wrote:
 Dne 15.11.2016 v 14:23 AB via Digitalmars-d napsal(a):

 On Tuesday, 15 November 2016 at 11:28:16 UTC, Kagamin wrote:
 On Tuesday, 15 November 2016 at 10:31:23 UTC, AB wrote:
 Are there plans to write a homebrew 64-bit linker for DMD?
There are already ld from mingw and lld from llvm team.
Why aren't they used and distributed in DMD for Windows by default? If the tools mentioned above (LD and LLD) are available and usable on Windows x64 instead of the ones provided in heavily bloated packages by Microsoft, how come the DMD installer for Windows doesn't offer them as an alternative (or better yet as the default)?
AFAIK ld on mingw can`t link against mscoff file format so it is not very usable. LLD is quite new so I do not know how production ready is. But I believe LLD will be the answer in future.
From what I've read about LLD (~ 6+ months ago) the Windows implementation was a complete rewrite from the Linux support. It most definitely isn't production ready or we would have heard about it (after all e.g. OSX will want to shift over to it).
http://www.phoronix.com/scan.php?page=news_item&px=LLVM-LD-Linker-Default-Discuss But I guess they are speaking about linux, freebsd and maybe OSX
Nov 15 2016
prev sibling parent reply Kagamin <spam here.lot> writes:
On Tuesday, 15 November 2016 at 14:41:34 UTC, Daniel Kozak wrote:
 AFAIK ld on mingw can`t link against mscoff file format so it 
 is not very usable.
It's dmd/optlink that don't support mscoff, mingw supports only mscoff.
 LLD is quite new so I do not know how production ready is.
AFAIK that's only because of lack of support for debug info. The rest works.
 Btw. today I want to start working on a D project in work, but 
 I cant, because there is not enoght space on C:\ partion and 
 there is not possible to instal VS to another disk :( (Ok in 
 few attempt of installing VS there has been path I can change 
 but it does not work anyway, still VS is trying to install to 
 C:\ ).
My system drive is filled with 80gb and it has 3 versions of VS, 2 ssms, sdk and whatnot installed on it. If your system drive doesn't stretch, you should consider what you fill it with as you would do in old good days.
Nov 16 2016
parent reply Patrick Schluter <Patrick.Schluter bbox.fr> writes:
On Wednesday, 16 November 2016 at 09:21:18 UTC, Kagamin wrote:
 On Tuesday, 15 November 2016 at 14:41:34 UTC, Daniel Kozak 
 wrote:
 AFAIK ld on mingw can`t link against mscoff file format so it 
 is not very usable.
It's dmd/optlink that don't support mscoff, mingw supports only mscoff.
 LLD is quite new so I do not know how production ready is.
AFAIK that's only because of lack of support for debug info. The rest works.
 Btw. today I want to start working on a D project in work, but 
 I cant, because there is not enoght space on C:\ partion and 
 there is not possible to instal VS to another disk :( (Ok in 
 few attempt of installing VS there has been path I can change 
 but it does not work anyway, still VS is trying to install to 
 C:\ ).
My system drive is filled with 80gb and it has 3 versions of VS, 2 ssms, sdk and whatnot installed on it. If your system drive doesn't stretch, you should consider what you fill it with as you would do in old good days.
Another issue I had with the Microsoft Package besides the size it wants on the system drive is the difficulty to even get it to download behind a corporate proxy. It took me hours to find a disk image version of the (free) visual stuff on the rotten Microsoft sites. I get the technical reasons for using the MS toolchain but that doesn't change the fact that it is an ugly wart that has several negative aspect. Because in addition to the cases already described where it can be a pita to install there's also an image problem with that approach. dmd's adoption had always suffered from the closed source licence of the backend with one small company, adding a second depency, furthermore on a company not specially known for its openess (yeah, I know that it's a little bit better now) will raise criticism. This issue is not big but it is definitely a - point when one makes a checklist of + and - points for a language (just a semi-related question, what's the state of play in the concurrent languages go, rust, scala etc...?)
Nov 16 2016
next sibling parent reply Patrick Schluter <Patrick.Schluter bbox.fr> writes:
On Wednesday, 16 November 2016 at 17:06:37 UTC, Patrick Schluter 
wrote:
 On Wednesday, 16 November 2016 at 09:21:18 UTC, Kagamin wrote:
 On Tuesday, 15 November 2016 at 14:41:34 UTC, Daniel Kozak 
 wrote:
 AFAIK ld on mingw can`t link against mscoff file format so it 
 is not very usable.
It's dmd/optlink that don't support mscoff, mingw supports only mscoff.
 LLD is quite new so I do not know how production ready is.
AFAIK that's only because of lack of support for debug info. The rest works.
 Btw. today I want to start working on a D project in work, 
 but I cant, because there is not enoght space on C:\ partion 
 and there is not possible to instal VS to another disk :( (Ok 
 in few attempt of installing VS there has been path I can 
 change but it does not work anyway, still VS is trying to 
 install to C:\ ).
My system drive is filled with 80gb and it has 3 versions of VS, 2 ssms, sdk and whatnot installed on it. If your system drive doesn't stretch, you should consider what you fill it with as you would do in old good days.
Another issue I had with the Microsoft Package besides the size it wants on the system drive is the difficulty to even get it to download behind a corporate proxy. It took me hours to find a disk image version of the (free) visual stuff on the rotten Microsoft sites. I get the technical reasons for using the MS toolchain but that doesn't change the fact that it is an ugly wart that has several negative aspect. Because in addition to the cases already described where it can be a pita to install there's also an image problem with that approach. dmd's adoption had always suffered from the closed source licence of the backend with one small company, adding a second depency, furthermore on a company not specially known for its openess (yeah, I know that it's a little bit better now) will raise criticism. This issue is not big but it is definitely a - point when one makes a checklist of + and - points for a language (just a semi-related question, what's the state of play in the concurrent languages go, rust, scala etc...?)
Ok, I checked for Rust. They have 2 ABI versions one with MSVC and the other for gcc in 32 and 64 bits. MSVC ABI requires the same build tools from Microsoft, so the situation is the same there. go doesn't need the MS tools apparently.
Nov 16 2016
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2016-11-16 09:19, Patrick Schluter wrote:

 go doesn't need the MS tools apparently.
As far as I know Go uses static linking and contains its own linker. -- /Jacob Carlborg
Nov 16 2016
prev sibling parent Kagamin <spam here.lot> writes:
On Wednesday, 16 November 2016 at 17:19:28 UTC, Patrick Schluter 
wrote:
 Another issue I had with the Microsoft Package besides the 
 size it wants on the system drive is the difficulty to even 
 get it to download behind a corporate proxy.
Doesn't it pick whatever is configured in the system settings?
 makes a checklist of + and - points for a language (just a 
 semi-related question, what's the state of play in the 
 concurrent languages go, rust, scala etc...?)
They probably don't depend on C runtime as much. Scala?
 Ok, I checked for Rust. They have 2 ABI versions one with MSVC 
 and the other for gcc in 32 and 64 bits. MSVC ABI requires the 
 same build tools from Microsoft, so the situation is the same 
 there.
LDC once supported mingw, but it broke. Most stuff should be still there.
Nov 17 2016
prev sibling parent reply Mike Parker <aldacron gmail.com> writes:
On Wednesday, 16 November 2016 at 17:06:37 UTC, Patrick Schluter 
wrote:

 I get the technical reasons for using the MS toolchain but that 
 doesn't change the fact that it is an ugly wart that has 
 several negative aspect. Because in addition to the cases 
 already described where it can be a pita to install there's 
 also an image problem with that approach. dmd's adoption had 
 always suffered from the closed source licence of the backend 
 with one small company, adding a second depency, furthermore on 
 a company not specially known for its openess (yeah, I know 
 that it's a little bit better now) will raise criticism.
 This issue is not big but it is definitely a - point when one 
 makes a checklist of + and - points for a language (just a 
 semi-related question, what's the state of play in the 
 concurrent languages go, rust, scala etc...?)
Why is it a wart? The MS toolchain is the system development environment for Windows. On Mac OS X, it's Xcode, which is a 1+ GB download before you can do any development with clang or dmd or anything that depends on it. On Linux distros, if it the GCC packages aren't already installed, they need to be pulled down. I mean, I get that the MS tools might not be perceived by some as the 'system' tools, but that is what they are. It's no different than the other systems DMD is distributed on.
Nov 16 2016
parent kink <noone nowhere.com> writes:
On Wednesday, 16 November 2016 at 17:34:58 UTC, Mike Parker wrote:
 Why is it a wart? The MS toolchain is the system development 
 environment for Windows. On Mac OS X, it's Xcode, which is a 1+ 
 GB download before you can do any development with clang or dmd 
 or anything that depends on it. On Linux distros, if it the GCC 
 packages aren't already installed, they need to be pulled down.

 I mean, I get that the MS tools might not be perceived by some 
 as the 'system' tools, but that is what they are. It's no 
 different than the other systems DMD is distributed on.
+1000. I hope this ridiculous thread comes to an end (nope, ELLCC is not a solution). So yes, the DMD installer is right in warning that 64-bit code cannot be linked if VS isn't detected. It should detect the VC++ Build Tools though => https://issues.dlang.org/show_bug.cgi?id=16688. 32-bit MS COFF cannot be linked either, but let's not confuse new users by a too detailed msgbox.
Nov 17 2016
prev sibling parent reply kink <noone nowhere.com> writes:
On Tuesday, 15 November 2016 at 13:23:38 UTC, AB wrote:
 On Tuesday, 15 November 2016 at 11:28:16 UTC, Kagamin wrote:
 On Tuesday, 15 November 2016 at 10:31:23 UTC, AB wrote:
 Are there plans to write a homebrew 64-bit linker for DMD?
There are already ld from mingw and lld from llvm team.
Why aren't they used and distributed in DMD for Windows by default? If the tools mentioned above (LD and LLD) are available and usable on Windows x64 instead of the ones provided in heavily bloated packages by Microsoft, how come the DMD installer for Windows doesn't offer them as an alternative (or better yet as the default)?
It's not just the linker. You need the libs as well (static and dynamic ones), and not just the WinSDK ones, but the MSVCRT ones too. Just use the Visual C++ Build Tools if there's not enough disk space in 2016 *cough*. IMO there's just no way of doing professional Windows development without the MS toolchain. And no reason to complain about it just because most Linux distros come with a fully fledged development ecosystem.
Nov 15 2016
parent reply AB <ab396356 users.sourceforge.net> writes:
On Tuesday, 15 November 2016 at 16:00:48 UTC, kink wrote:
 It's not just the linker. You need the libs as well (static and 
 dynamic ones), and not just the WinSDK ones, but the MSVCRT 
 ones too.
I was under the impression that DMD for Windows was (meant to be) self-sufficient. I must have been misled by how it can build 32-bit applications just fine without requiring the many gigabytes of WinSDK and MSVCRT extras. Hopefully, future releases of DMD will fix this inconsistency by requiring Visual Studio for 32-bit D programs as well.
Nov 15 2016
next sibling parent Rene Zwanenburg <renezwanenburg gmail.com> writes:
On Tuesday, 15 November 2016 at 16:20:53 UTC, AB wrote:
 Hopefully, future releases of DMD will fix this inconsistency 
 by requiring Visual Studio for 32-bit D programs as well.
You already do, if you compile with -m32mscoff.
Nov 15 2016
prev sibling next sibling parent kink <noone nowhere.com> writes:
On Tuesday, 15 November 2016 at 16:20:53 UTC, AB wrote:
 On Tuesday, 15 November 2016 at 16:00:48 UTC, kink wrote:
 It's not just the linker. You need the libs as well (static 
 and dynamic ones), and not just the WinSDK ones, but the 
 MSVCRT ones too.
I was under the impression that DMD for Windows was (meant to be) self-sufficient. I must have been misled by how it can build 32-bit applications just fine without requiring the many gigabytes of WinSDK and MSVCRT extras.
Did you give the Build Tools even a try? I can't install it as it's not installable alongside VS (yes, I do have enough disk space for 3 parallel VS installations!). The system requirements on their site says it needs 200 MB. Also, DMD ships with the most common Windows libs (no idea from which WinSDK though), and DMD for 32-bit Windows (the non-COFF, i.e., optlink flavour) uses the Digital Mars C runtime (for which there's obviously no 64-bit version). The 32-bit non-COFF Windows DMD comes along as self-sufficient package for basic users. If you're one of them, fine, otherwise get a proper dev environment and acknowledge that it'll require some space on disk.
Nov 15 2016
prev sibling parent reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Tuesday, November 15, 2016 16:20:53 AB via Digitalmars-d wrote:
 On Tuesday, 15 November 2016 at 16:00:48 UTC, kink wrote:
 It's not just the linker. You need the libs as well (static and
 dynamic ones), and not just the WinSDK ones, but the MSVCRT
 ones too.
I was under the impression that DMD for Windows was (meant to be) self-sufficient. I must have been misled by how it can build 32-bit applications just fine without requiring the many gigabytes of WinSDK and MSVCRT extras.
You _can_ build 32-bit applications with dmd without the Microsoft toolchain just fine. dmc and optlink should be installed with the dmd installer so that code can be compiled to 32-bit OMF and linked. You just need the Microsoft toolchain if you're compiling for 64-bit (which is only COFF) or if you want to compile to 32-bit COFF. It's unnecessary if you simply want to compile and run 32-bit programs and are willing to use OMF for the linker format. If dmd's installer is actually requiring that you install Visual Studio to compile 32-bit programs, then that's a problem. It didn't do that before, and it shouldn't need to now. - Jonathan M Davis
Nov 15 2016
parent reply Jerry <hurricane hereiam.com> writes:
On Tuesday, 15 November 2016 at 23:34:34 UTC, Jonathan M Davis 
wrote:
 On Tuesday, November 15, 2016 16:20:53 AB via Digitalmars-d 
 wrote:
 On Tuesday, 15 November 2016 at 16:00:48 UTC, kink wrote:
 It's not just the linker. You need the libs as well (static 
 and dynamic ones), and not just the WinSDK ones, but the 
 MSVCRT ones too.
I was under the impression that DMD for Windows was (meant to be) self-sufficient. I must have been misled by how it can build 32-bit applications just fine without requiring the many gigabytes of WinSDK and MSVCRT extras.
You _can_ build 32-bit applications with dmd without the Microsoft toolchain just fine. dmc and optlink should be installed with the dmd installer so that code can be compiled to 32-bit OMF and linked. You just need the Microsoft toolchain if you're compiling for 64-bit (which is only COFF) or if you want to compile to 32-bit COFF. It's unnecessary if you simply want to compile and run 32-bit programs and are willing to use OMF for the linker format. If dmd's installer is actually requiring that you install Visual Studio to compile 32-bit programs, then that's a problem. It didn't do that before, and it shouldn't need to now. - Jonathan M Davis
That's not a good enough reason to keep using it, compared to all the reasons for it's removal. Optlink is old and bug ridden, switching to Microsoft's linker solved a bunch of misc problems I was having with D (unable to debug cause of constant crashing, mismanagement of resources like std file handles, etc...). There is no 64-bit equivalent, so you are using two different linkers, when you can simply unify it to have one. It isn't compatible with the standard format of the host OS. Most software uses 64-bit, some not even bothering with 32-bit applications. Having Visual Studio is already pretty much a requirement, if you want 64-bit (which is probably most people). Adding Visual Studio build tools in some way to the installer will ease the setup process for people that want 64-bit. I'm for removing it completely, if not, then at the very least don't make it the default and add a switch instead.
Nov 15 2016
parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 16/11/2016 4:58 PM, Jerry wrote:
 On Tuesday, 15 November 2016 at 23:34:34 UTC, Jonathan M Davis wrote:
 On Tuesday, November 15, 2016 16:20:53 AB via Digitalmars-d wrote:
 On Tuesday, 15 November 2016 at 16:00:48 UTC, kink wrote:
 It's not just the linker. You need the libs as well (static > and
dynamic ones), and not just the WinSDK ones, but the > MSVCRT ones too. I was under the impression that DMD for Windows was (meant to be) self-sufficient. I must have been misled by how it can build 32-bit applications just fine without requiring the many gigabytes of WinSDK and MSVCRT extras.
You _can_ build 32-bit applications with dmd without the Microsoft toolchain just fine. dmc and optlink should be installed with the dmd installer so that code can be compiled to 32-bit OMF and linked. You just need the Microsoft toolchain if you're compiling for 64-bit (which is only COFF) or if you want to compile to 32-bit COFF. It's unnecessary if you simply want to compile and run 32-bit programs and are willing to use OMF for the linker format. If dmd's installer is actually requiring that you install Visual Studio to compile 32-bit programs, then that's a problem. It didn't do that before, and it shouldn't need to now. - Jonathan M Davis
That's not a good enough reason to keep using it, compared to all the reasons for it's removal. Optlink is old and bug ridden, switching to Microsoft's linker solved a bunch of misc problems I was having with D (unable to debug cause of constant crashing, mismanagement of resources like std file handles, etc...). There is no 64-bit equivalent, so you are using two different linkers, when you can simply unify it to have one. It isn't compatible with the standard format of the host OS. Most software uses 64-bit, some not even bothering with 32-bit applications. Having Visual Studio is already pretty much a requirement, if you want 64-bit (which is probably most people). Adding Visual Studio build tools in some way to the installer will ease the setup process for people that want 64-bit. I'm for removing it completely, if not, then at the very least don't make it the default and add a switch instead.
And then we'll get complaints that they need another big download just to compile basic 32bit programs... This whole argument about making changes is rediculas. Unless we get explicit permission from Microsoft to distribute the parts we needs, I think it is safe to say that Optlink stays, in fact nothing will change.
Nov 15 2016
parent Jerry <hurricane hereiam.com> writes:
On Wednesday, 16 November 2016 at 04:04:05 UTC, rikki cattermole 
wrote:
 And then we'll get complaints that they need another big 
 download just to compile basic 32bit programs... This whole 
 argument about making changes is rediculas.

 Unless we get explicit permission from Microsoft to distribute 
 the parts we needs, I think it is safe to say that Optlink 
 stays, in fact  nothing will change.
So just make it a switch. It's fine for anyone wanting to just try it, but for everyone else they probably already have to download Visual Studio.
Nov 16 2016
prev sibling next sibling parent Mike Parker <aldacron gmail.com> writes:
On Monday, 14 November 2016 at 09:33:48 UTC, AB wrote:
 On Monday, 14 November 2016 at 09:06:18 UTC, Kagamin wrote:
 DMD can generate 64-bit object files just fine, you only need 
 to link them, and DMD can invoke ms linker for you, that's all.
It is unreasonable to pull in the many GBs of Visual Studio as a dependency only to use its 64-bit linker.
No, it isn't unreasonable. The alternative is for Walter to write a new linker that is compatible with the Microsoft ecosystem. He instead took the expedient, and IMO correct, course of working with the system linker. If you do C or C++ development with Clang on Windows these days, it's best to have the MS tools installed. This isn't any different.
Nov 14 2016
prev sibling next sibling parent reply Patrick Schluter <Patrick.Schluter bbox.fr> writes:
On Monday, 14 November 2016 at 09:33:48 UTC, AB wrote:
 On Monday, 14 November 2016 at 09:06:18 UTC, Kagamin wrote:
 DMD can generate 64-bit object files just fine, you only need 
 to link them, and DMD can invoke ms linker for you, that's all.
It is unreasonable to pull in the many GBs of Visual Studio as a dependency only to use its 64-bit linker.
That's a true issue imho also. I had the same problem. Both my machine at work and at home have their windows system partition on a smallish SSD. Installing Visual Studio failed because of lack of space. Even installing it on another drive fails because even in that case the Microsofties want to install gigabytes of stuff on the system drive. Extremely annoying when you only want to install an otherwise extremely lean development tool (dmd) to test 100 liners.
Nov 14 2016
next sibling parent Chris <wendlec tcd.ie> writes:
On Monday, 14 November 2016 at 13:44:29 UTC, Patrick Schluter 
wrote:

 That's a true issue imho also. I had the same problem. Both my 
 machine at work and at home have their windows system partition 
 on a smallish SSD. Installing Visual Studio failed because of 
 lack of space. Even installing it on another drive fails 
 because even in that case the Microsofties want to install 
 gigabytes of stuff on the system drive. Extremely annoying when 
 you only want to install an otherwise extremely lean 
 development tool (dmd) to test 100 liners.
Same here. Last week I tried to install dmd on Windows only to learn that there was not enough space for Visual Studio.
Nov 14 2016
prev sibling next sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 11/14/2016 08:44 AM, Patrick Schluter wrote:
 have their windows system partition on a smallish SSD.
Well, in all honestly, that IS going to cause problems regardless. The larger SSDs are fine (enough) for a phone, but for a PC that's used for anything more than the average joe's web/email/word combo, SSDs are still far too small. I still have an "old fashioned" HDD-only in my PC (a laptop): dirt-cheap: <$100 for 1TB (try to find an SSD that remotely compares), and the ONLY time I ever have speed issues in either Win or Lin is when I'm running far too much crap and start hitting virtual memory swapping (or when some badly coded program soaks up all the CPU recourses, but SSDs cant help with that anyway).
Nov 14 2016
next sibling parent reply fdjfgj <fdjfgj^ ghfhg.fg> writes:
On Monday, 14 November 2016 at 16:59:56 UTC, Nick Sabalausky 
wrote:
 On 11/14/2016 08:44 AM, Patrick Schluter wrote:
 have their windows system partition on a smallish SSD.
Well, in all honestly, that IS going to cause problems regardless. The larger SSDs are fine (enough) for a phone, but for a PC that's used for anything more than the average joe's web/email/word combo, SSDs are still far too small. I still have an "old fashioned" HDD-only in my PC (a laptop): dirt-cheap: <$100 for 1TB (try to find an SSD that remotely compares), and the ONLY time I ever have speed issues in either Win or Lin is when I'm running far too much crap and start hitting virtual memory swapping (or when some badly coded program soaks up all the CPU recourses, but SSDs cant help with that anyway).
In 2005 a 250Gb magnetic HDD costed the same as nowadays 250Gb SSD.
Nov 14 2016
next sibling parent Patrick Schluter <Patrick.Schluter bbox.fr> writes:
On Monday, 14 November 2016 at 18:04:05 UTC, fdjfgj wrote:
 On Monday, 14 November 2016 at 16:59:56 UTC, Nick Sabalausky 
 wrote:
 On 11/14/2016 08:44 AM, Patrick Schluter wrote:
 have their windows system partition on a smallish SSD.
Well, in all honestly, that IS going to cause problems regardless. The larger SSDs are fine (enough) for a phone, but for a PC that's used for anything more than the average joe's web/email/word combo, SSDs are still far too small. I still have an "old fashioned" HDD-only in my PC (a laptop): dirt-cheap: <$100 for 1TB (try to find an SSD that remotely compares), and the ONLY time I ever have speed issues in either Win or Lin is when I'm running far too much crap and start hitting virtual memory swapping (or when some badly coded program soaks up all the CPU recourses, but SSDs cant help with that anyway).
In 2005 a 250Gb magnetic HDD costed the same as nowadays 250Gb SSD.
In 2005 I had no wife nor kids, so I could put whatever I fancied in my PC, now I have other priorities. At work, I have only a very small influence on what goes into my workstation. I'm even one of the super duper priviledged, I have an i3 with 8GiB (took me one year to be upgraded to that), a 128GB SSD, a 250GB platter and local admin rights (that I have to renew every year with a 2 page form with justifications why I need such fancy stuff).
Nov 14 2016
prev sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 11/14/2016 01:04 PM, fdjfgj wrote:
 On Monday, 14 November 2016 at 16:59:56 UTC, Nick Sabalausky wrote:
 On 11/14/2016 08:44 AM, Patrick Schluter wrote:
 have their windows system partition on a smallish SSD.
Well, in all honestly, that IS going to cause problems regardless. The larger SSDs are fine (enough) for a phone, but for a PC that's used for anything more than the average joe's web/email/word combo, SSDs are still far too small. I still have an "old fashioned" HDD-only in my PC (a laptop): dirt-cheap: <$100 for 1TB (try to find an SSD that remotely compares), and the ONLY time I ever have speed issues in either Win or Lin is when I'm running far too much crap and start hitting virtual memory swapping (or when some badly coded program soaks up all the CPU recourses, but SSDs cant help with that anyway).
In 2005 a 250Gb magnetic HDD costed the same as nowadays 250Gb SSD.
Eh? 2005 has nothing to do with anything. In 2016, magnetic HDDs are not purchased at 2005 prices. In 2016, a 250GB magnetic HDD costs vastly less than a 250GB SSD. In 2016, you can even get a 1TB HDD for less than a 250GB SSD. Even in 2.5". In 2016, 250GB is quite small as far as general-purpose PC storage goes. In 2016, I picked up a 5TB USB3 HDD drive for HALF the price of a 1TB SSD. But most importantly: In what alternate 2016 reality is a 250GB drive insufficient to be able to spare 3Gb to install a core dev tool?
Nov 14 2016
next sibling parent fdjfgj <fdjfgj^ ghfhg.fg> writes:
On Monday, 14 November 2016 at 20:01:37 UTC, Nick Sabalausky 
wrote:
 On 11/14/2016 01:04 PM, fdjfgj wrote:
 In 2005 a 250Gb magnetic HDD costed the same as nowadays 250Gb 
 SSD.
Eh? 2005 has nothing to do with anything. In 2016, magnetic HDDs are not purchased at 2005 prices. In 2016, a 250GB magnetic HDD costs vastly less than a 250GB SSD. In 2016, you can even get a 1TB HDD for less than a 250GB SSD. Even in 2.5".
I tried to tell that the SSD technology becomes cheaper and cheaper, as the magnetic disks during the previous decade.
 In 2016, 250GB is quite small as far as general-purpose PC 
 storage goes.
Because general purpose PC users more or less suffer of digital hoarding (videos & games & music accumulation).
Nov 14 2016
prev sibling parent Daniel Kozak via Digitalmars-d <digitalmars-d puremagic.com> writes:
Dne 14.11.2016 v 21:01 Nick Sabalausky via Digitalmars-d napsal(a):

 But most importantly:

 In what alternate 2016 reality is a 250GB drive insufficient to be 
 able to spare 3Gb to install a core dev tool?
First it is more than a 3GB, on my windows it has been around 10GB or more for VS and sdk (I belive I can remove some checkboxes in instalation but who knows which :D). And second I have 128GB ssd with dual boot or even with just linux and virtual machine for windows 10 it has been problem for me :D. Yep I need to by a new SSD :)
Nov 14 2016
prev sibling next sibling parent reply Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
On Monday, 14 November 2016 at 16:59:56 UTC, Nick Sabalausky 
wrote:
 SSDs are still far too small.
Hmm... http://arstechnica.com/gadgets/2016/08/seagate-unveils-60tb-ssd-the-worlds-largest-hard-drive/
 the ONLY time I ever have speed issues
"Speed issues" is one thing. Having most operations be INSTANT is another. It MASSIVELY transforms your workflow; UIs where each key press launches a command (e.g. magit, background builds...) become sensible and usable "blindly", and can easily multiply productivity by an order of magnitude. If you don't have an SSD in your work machine (but can afford one), you simply don't value your time.
Nov 15 2016
next sibling parent reply Kagamin <spam here.lot> writes:
On Tuesday, 15 November 2016 at 08:33:26 UTC, Vladimir Panteleev 
wrote:
 UIs where each key press launches a command (e.g. magit, 
 background builds...)
emacs? Also doesn't dmdfe spend most of its time in semantic analysis? You can't possibly optimize that with IO.
Nov 15 2016
parent Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
On Tuesday, 15 November 2016 at 09:02:08 UTC, Kagamin wrote:
 On Tuesday, 15 November 2016 at 08:33:26 UTC, Vladimir 
 Panteleev wrote:
 UIs where each key press launches a command (e.g. magit, 
 background builds...)
emacs?
Yep.
 Also doesn't dmdfe spend most of its time in semantic analysis?
Yep, but this isn't restricted to D, of course. More complicated build systems do a lot of I/O (and, often, unnecessary sync()ing).
Nov 15 2016
prev sibling next sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 11/15/2016 03:33 AM, Vladimir Panteleev wrote:
 On Monday, 14 November 2016 at 16:59:56 UTC, Nick Sabalausky wrote:
 SSDs are still far too small.
Hmm... http://arstechnica.com/gadgets/2016/08/seagate-unveils-60tb-ssd-the-worlds-largest-hard-drive/
I mean "too small at reasonable prices". A $10k SSD doesn't really count.
Nov 15 2016
parent Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
On Tuesday, 15 November 2016 at 17:23:56 UTC, Nick Sabalausky 
wrote:
 I mean "too small at reasonable prices".
If you keep your photos/movies/music/backups/installers/etc. on spinning rust (where they belong), and aren't living in poverty, it's not. A 250GB Samsung 850 EVO is under $100, which is less than most other PC components.
Nov 15 2016
prev sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 11/15/2016 03:33 AM, Vladimir Panteleev wrote:
 On Monday, 14 November 2016 at 16:59:56 UTC, Nick Sabalausky wrote:
 the ONLY time I ever have speed issues
"Speed issues" is one thing. Having most operations be INSTANT is another. It MASSIVELY transforms your workflow; UIs where each key press launches a command (e.g. magit, background builds...) become sensible and usable "blindly", and can easily multiply productivity by an order of magnitude. If you don't have an SSD in your work machine (but can afford one), you simply don't value your time.
I don't really use emacs, and (thought I admit I'm not 100% certain), I don't think much of what I use launches (or at least needs to launch) separate commands for each keypress (sounds like bad software engineering to me, but that's just my gut impression, maybe I'm wrong). That does remind me though: Are hybrid drives still a thing? They sounded like a good idea (at least for laptops, where you can usually only have one internal drive), but I seem to remember hearing that they tended to have reliability problems. Has that been sorted out, or have the hybrids just gone away entirely?
Nov 15 2016
parent Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
On Tuesday, 15 November 2016 at 17:31:04 UTC, Nick Sabalausky 
wrote:
 I don't really use emacs, and (thought I admit I'm not 100% 
 certain), I don't think much of what I use launches (or at 
 least needs to launch) separate commands for each keypress 
 (sounds like bad software engineering to me, but that's just my 
 gut impression, maybe I'm wrong).
As the threshold of what performance is acceptable rises, so do the possibilities. Things that sounded like bad engineering years ago can be considered perfectly acceptable today (e.g. why go through the effort of integrating something by writing a library and inventing an API, if you can just spawn processes for every operation at negligible cost, and greatly lower development and maintenance effort). Granted, certainly not everything will benefit from I/O performance, but a lot of things do.
 That does remind me though: Are hybrid drives still a thing? 
 They sounded like a good idea (at least for laptops, where you 
 can usually only have one internal drive),
Ah, I missed that you were talking in the context of a laptop. One thing to note is that as optical disk drives become less useful, dual-HDD laptops are more common. I've also seen some models (ThinkPads, IIRC?) with a small amount of on-board flash memory that can be used as a cache. Caching with two drives can also be done in software (bcache/lvmcache), though if you have two drives, IMO it's simpler to separate the data yourself.
Nov 15 2016
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2016-11-14 08:59, Nick Sabalausky wrote:

 I still have an "old fashioned" HDD-only in my PC (a laptop):
 dirt-cheap: <$100 for 1TB (try to find an SSD that remotely compares),
 and the ONLY time I ever have speed issues in either Win or Lin is when
 I'm running far too much crap and start hitting virtual memory swapping
 (or when some badly coded program soaks up all the CPU recourses, but
 SSDs cant help with that anyway).
I bought an SSD drive around a year ago. It was one of the biggest performance boosts I've seen in a computer. Boot times went from minutes to seconds. -- /Jacob Carlborg
Nov 16 2016
prev sibling next sibling parent thedeemon <dlang thedeemon.com> writes:
On Monday, 14 November 2016 at 13:44:29 UTC, Patrick Schluter 
wrote:
 Extremely annoying when you only want to install an otherwise 
 extremely lean development tool (dmd) to test 100 liners.
But you most probably don't need all that stuff for testing your 100-liners. By default DMD on Windows builds 32-bit binaries where its own linker is used, you don't really need MS linker to make Windows binaries with DMD. 32 bits are quite fine for most cases.
Nov 14 2016
prev sibling parent Kagamin <spam here.lot> writes:
On Monday, 14 November 2016 at 13:44:29 UTC, Patrick Schluter 
wrote:
 That's a true issue imho also. I had the same problem. Both my 
 machine at work and at home have their windows system partition 
 on a smallish SSD.
You can move stuff from the system drive with symbolic links; e.g. windows\installer, just see what takes space and has no reason to be on the system drive.
Nov 15 2016
prev sibling next sibling parent Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
On Monday, 14 November 2016 at 09:33:48 UTC, AB wrote:
 On Monday, 14 November 2016 at 09:06:18 UTC, Kagamin wrote:
 DMD can generate 64-bit object files just fine, you only need 
 to link them, and DMD can invoke ms linker for you, that's all.
It is unreasonable to pull in the many GBs of Visual Studio as a dependency only to use its 64-bit linker.
FWIW, Digger can download and unpack only those parts of Visual Studio that D needs: https://github.com/CyberShadow/ae/blob/3365c066c78a82584b8fc5b24edc4da0a4f738a8/sys/d/manager.d#L2089-L2104 Digger is https://github.com/CyberShadow/Digger.
Nov 14 2016
prev sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 11/14/2016 04:33 AM, AB wrote:
 On Monday, 14 November 2016 at 09:06:18 UTC, Kagamin wrote:
 DMD can generate 64-bit object files just fine, you only need to link
 them, and DMD can invoke ms linker for you, that's all.
It is unreasonable to pull in the many GBs of Visual Studio as a dependency only to use its 64-bit linker.
The Linux and Mac versions rely on Linux/Mac's native C linkers, regardless of 32/64 bit. If Win's native linker is too large, or can't be obtained as part of a small enough package, that's really a Microsoft problem. You can't blame Samsung if there's nothing good to watch on TV.
Nov 14 2016
parent reply Jacob Carlborg <doob me.com> writes:
On 2016-11-14 09:05, Nick Sabalausky wrote:

 The Linux and Mac versions rely on Linux/Mac's native C linkers,
 regardless of 32/64 bit.
Yeah. On macOS, Xcode is a 4.x GB download size and 12 GB install size (just looking at what I currently have). Perhaps we should take the missing parts from the ELLCC tool chain [1]. It's a cross-compiler tool chain based on LLVM. It contains a compiler, linker, C/C++ standard library, other binutils and is completely self contained. [1] http://ellcc.org -- /Jacob Carlborg
Nov 16 2016
parent reply Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
On Wednesday, 16 November 2016 at 18:03:31 UTC, Jacob Carlborg 
wrote:
 Perhaps we should take the missing parts from the ELLCC tool 
 chain [1]. It's a cross-compiler tool chain based on LLVM. It 
 contains a compiler, linker, C/C++ standard library, other 
 binutils and is completely self contained.

 [1] http://ellcc.org
It seems to use MinGW-w64, which uses the GNU linker, which can't create PDB files.
Nov 17 2016
parent Jacob Carlborg <doob me.com> writes:
On 2016-11-17 11:16, Vladimir Panteleev wrote:

 It seems to use MinGW-w64, which uses the GNU linker, which can't create
 PDB files.
I thought the whole tool chain was based on LLVM, but I might be wrong. -- /Jacob Carlborg
Nov 17 2016
prev sibling parent Joakim <dlang joakim.fea.st> writes:
On Monday, 14 November 2016 at 08:38:32 UTC, AB wrote:
 Installing D 2.072.0 on Windows 7 64-bit. After installation is 
 complete I get the following two error (warning?) messages, 
 screenshots here:

 http://imgur.com/a/5fydB

 For your convenience they read as follows:

 "Could not detect Visual Studio (2008-2015 are supported). No 
 64-bit support."

 "Could not detect Windows SDK (6.0A-10.0 are supported). No 
 64-bit support."

 So the above means that the DMD compiler will not be able to 
 generate 64-bit executables on my system, because a third-party 
 piece of software is missing? This is ridiculous, what does 
 Visual Studio have to do with DMD and its capability to 
 generate 64-bit code?

 "You wanted a banana but what you got was a gorilla holding the 
 banana and the entire jungle."
It used to be possible to get just the command-line tools by installing the much smaller Windows SDK: http://forum.dlang.org/post/hvdyyutbgehlefluvsup forum.dlang.org If that's not the case anymore, I suggest you take it up with Microsoft.
Nov 14 2016