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.

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.

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.

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.

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?

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.

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

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).

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.

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.