On Tuesday, 13 July 2021 at 11:23:38 UTC, Scotpip wrote:
Mike - thanks for responding!
You say that there wasn't a Windows 64 bit release "for good reason".
That sounds a bit ominous - I'd appreciate your insights into what was behind this.
Nothing ominous. It was just because of the state of the Windows development ecosystem when Walter started working on D 20 years ago and the desire for the out-of-box experience to just work.
He started with a backend for his C compiler and the optlink linker, neither of which supported 64-bit, and both of which only supported the OMF object file format. He had a license to ship the Win32 link libraries that he packaged with his C compiler, so he shipped those with dmd as well.
He put off 64-bit support for quite a while because (I believe, he can correct me if I'm wrong) there was no good way to get it implemented. On Linux and Mac, people had no problem installing the system build tools and development libraries. In the Windows ecosystem, the equivalent was ostensibly the Microsoft Build Tools and Windows SDK, but outside of serious Windows dev shops people were averse to installing them. It probably didn't help that VS was commercial (the first free version that eventually came along---can't remember what it was called, but it preceded the Community Edition---was limited in features and restricted by license).
When he finally got it done, he added support for Microsoft's version of the COFF object file format in the backend, but the ecosystem hadn't changed all that much in terms of attitudes. Requiring the MS stuff to be installed for an out-of-the-box experience on 64-bit systems would have really hindered adoption. So the 32-bit distribution remained the default.
Later on, in order to start providing an out-of-the-box 64-bit experience, the decision was made to ship lld-link (the LLVM linker). Walter tried to get the rights to distribute Microsoft's 64-bit link libraries to go along with it, but MS said no. So instead, a system was set up to generate them from MinGW's libraries and ship the generated link libraries. But time was needed to ensure the new stuff worked as intended before throwing the switch on default 64-bit.
I guess the fact that the installer now includes 64-bit binaries means the time has almost come to pull the switch on 64-bit packages. So I expect not too far down the road we'll see installers that configure the 64-bit binaries on the system path on 64-bit systems.
Given the effort that's clearly gone into VisualD I was rather assuming that Windows was fully supported by the D community. As I'm pretty much stuck with Windows for this project, I hope I'm not mistaken?
Windows is supported just fine. I've been using it since I started with D in 2003. Walter is primarily a Windows user. The biggest issue has always been one of external tooling preventing an out-of-the-box 64-bit experience.
But you don't need the 64-bit binaries on the system path to build 64-bit. Just put the bin folder on the system path and pass -m64 to the compiler.
Also, you say that you don't use rdmd. As someone who hasn't used a standalone compiled language for decades, I'd be grateful if you could share your workflow, as at first sight rdmd looks rather useful. For a non-trivial personal project, is there a specific approach you would recommend?
I use dub, a build tool and package manager, which also ships with dmd. The docs start here:
And the package repository is here:
A little while back, dub was modified to start compiling 64-bit by default on 64-bit Windows systems, so it's kind of proving that the time has come to start making 64-bit the default.
Also, LDC, the LLVM-based D compiler, ships 64-bit Windows binaries and has for a long time.
Dub can be configured to compile with dmd, ldc, or gdc.