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:
https://dub.pm/getting_started
And the package repository is here:
https://code.dlang.org/
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.
https://github.com/ldc-developers/ldc/releases
Dub can be configured to compile with dmd, ldc, or gdc.
