On Tuesday, 24 October 2017 at 13:37:09 UTC, rikki cattermole wrote:
> On 24/10/2017 2:25 PM, Mike Parker wrote:
>> On Tuesday, 24 October 2017 at 13:20:10 UTC, Andrei Alexandrescu wrote:
>> 
>>> * better dll support for Windows.
>> 
>> This one is on a lot of wish lists.
>
> It definitely needs to be a target for 2018H1, I'll be making sure its added! Too big a blocker and comes up a little too often...

DIP45 has the solution (make export an attribute), it needs to be updated for the new DIP format from what I heard. It needs to be pushed, as Windows still the most popular OS on the consumer side of things, then we can have Phobos and DRuntime as DLLs without using experimental versions of DMD. I have some plans with the better DLL support, such as the possibility of a D based Python (for better class interoperability with D), or even using a modified set of D for scripting (eg. SafeD only).

On Tuesday, 24 October 2017 at 21:11:37 UTC, Andre Pany wrote:
>
> In general I agree with you that coff is the way to go. I just dislike the consequences. Today you just download the dmd Windows zip, extract it and you have a running compiler. Nice, self contained and a good advertisement for D. On the other side if the user is forced to install Visual Studio / C++ build pack, this might distract first time D users...
>
> If the Microsoft linker could be added to dmd that would be the best solution. Just dreaming :)
>
> Kind regards
> Andre

I'm sympathetic to your point.

I think there was/is some effort to allow LLD (the LLVM linker) as a replacement for the MSVC linker in LDC. Perhaps if LLD could be a drop-in for MSVC in DMD for Windows, then eventually it could be the default? Not sure that's possible or not.

On 10/24/2017 6:20 AM, Andrei Alexandrescu wrote:
> * better dll support for Windows.

It's been there, but it breaks repeatedly because it is not in the test suite.

On Wednesday, 25 October 2017 at 04:55:16 UTC, Walter Bright wrote:
> On 10/24/2017 6:20 AM, Andrei Alexandrescu wrote:
>> * better dll support for Windows.
>
> It's been there, but it breaks repeatedly because it is not in the test suite.

Yes that is right. One of these issues is the Runtime.unload bug
https://issues.dlang.org/show_bug.cgi?id=15443

The wiki page https://wiki.dlang.org/Win32_DLLs_in_D has an example in which the function
gc_getProxy and gc_setProxy is used the inject the garbage collector. The example shows only this behavior in the static linked case but not in the dynamically linked case. For the dynamically linked case, there is an error. Ian Hatch found out same more information
http://forum.dlang.org/post/nteskpizpsnxrulcsgri@forum.dlang.org

In general the "export" work of Benjamin Thaut is also highly interesting
(D's Import and Export Business, DConf2016)

Kind regards
André

On Tuesday, 24 October 2017 at 16:37:10 UTC, H. S. Teoh wrote:
> (Having said all that, though, D is probably a far better language for implementing crypto algorithms -- built-in bounds checking would have prevented some of the worst security holes that have come to light recently, like Heartbleed and Cloudbleed.

Those were buffer overflows in parsers, not in cryptographic algorithms.

On Wednesday, October 25, 2017 13:22:46 Kagamin via Digitalmars-d wrote:
> On Tuesday, 24 October 2017 at 16:37:10 UTC, H. S. Teoh wrote:
> > (Having said all that, though, D is probably a far better language for implementing crypto algorithms -- built-in bounds checking would have prevented some of the worst security holes that have come to light recently, like Heartbleed and Cloudbleed.
>
> Those were buffer overflows in parsers, not in cryptographic algorithms.

The point still stands though that you have to be _very_ careful when implementing anything security related, and it's shockingly easy to do something that actually leaks information even if it's not outright buggy (e.g. the timing of the code indicates something about success or failure to an observer), and someone who isn't an expert in the area is bound to screw something up - and since this is a security issue, it matters that much more than it would with other code.

- Jonathan M Davis

On Tuesday, 24 October 2017 at 22:19:59 UTC, jmh530 wrote:
> On Tuesday, 24 October 2017 at 21:11:37 UTC, Andre Pany wrote:
>> [...]
>
> I'm sympathetic to your point.
>
> I think there was/is some effort to allow LLD (the LLVM linker) as a replacement for the MSVC linker in LDC. Perhaps if LLD could be a drop-in for MSVC in DMD for Windows, then eventually it could be the default? Not sure that's possible or not.

VC++ command line tools seem to be available on their own:

http://landinghub.visualstudio.com/visual-cpp-build-tools

On Wednesday, 25 October 2017 at 15:00:04 UTC, bitwise wrote:

> VC++ command line tools seem to be available on their own:
>
> http://landinghub.visualstudio.com/visual-cpp-build-tools

Still a big download and requires the Windows SDK to be downloaded and installed separately.

On Wed, Oct 25, 2017 at 08:17:21AM -0600, Jonathan M Davis via Digitalmars-d wrote:
> On Wednesday, October 25, 2017 13:22:46 Kagamin via Digitalmars-d wrote:
> > On Tuesday, 24 October 2017 at 16:37:10 UTC, H. S. Teoh wrote:
> > > (Having said all that, though, D is probably a far better language for implementing crypto algorithms -- built-in bounds checking would have prevented some of the worst security holes that have come to light recently, like Heartbleed and Cloudbleed.
> >
> > Those were buffer overflows in parsers, not in cryptographic algorithms.
> 
> The point still stands though that you have to be _very_ careful when implementing anything security related, and it's shockingly easy to do something that actually leaks information even if it's not outright buggy (e.g. the timing of the code indicates something about success or failure to an observer), and someone who isn't an expert in the area is bound to screw something up - and since this is a security issue, it matters that much more than it would with other code.
[...]

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

-- 
You have to expect the unexpected. -- RL

On 10/25/17 09:34, Mike Parker wrote:
> On Wednesday, 25 October 2017 at 15:00:04 UTC, bitwise wrote:
>
>> VC++ command line tools seem to be available on their own:
>>
>> http://landinghub.visualstudio.com/visual-cpp-build-tools
>
> Still a big download and requires the Windows SDK to be downloaded and
> installed separately.

Speaking from very long experience, 95%+ of Windows devs have VS+WinSDK installed as part of their default system buildout. The few that don't will have little trouble understanding why they need it and acquiring it.

This is one of those breathless "the sky is falling" arguments we hear on these forums sometimes. Usually from linux devs who are inured to having the GCC tools on every machine and automatically assume that because Windows doesn't by default that it won't be there and that getting it will be some insurmountable burden. TBH, the attitudes around here towards Windows devs can be more than a little snobbish.

In reality, it is quite easy to find a linux distro that doesn't have GCC by default, container distros for example. So the snobby attitude is really quite unfounded.

-- 
Adam Wilson
IRC: LightBender
import quiet.dlang.dev;