On Friday, 27 October 2017 at 09:56:25 UTC, Kagamin wrote:
> MinGW compiles import libraries from text .def files that are lists of exported symbols: https://sourceforge.net/p/mingw-w64/mingw-w64/ci/master/tree/mingw-w64-crt/lib64/

I will test dmd + lld + use .def files instead of .lib files

On Friday, 27 October 2017 at 14:20:04 UTC, MrSmith wrote:
> On Friday, 27 October 2017 at 09:56:25 UTC, Kagamin wrote:
>> MinGW compiles import libraries from text .def files that are lists of exported symbols: https://sourceforge.net/p/mingw-w64/mingw-w64/ci/master/tree/mingw-w64-crt/lib64/
>
> I will test dmd + lld + use .def files instead of .lib files

With this the only missing piece will be the C startup code (mainCRTStartup in crtexe.c), though not sure where it's compiled.

On Friday, 27 October 2017 at 16:05:10 UTC, Kagamin wrote:
> (mainCRTStartup in crtexe.c)

Or crt0.c

On Wednesday, 25 October 2017 at 14:17:21 UTC, Jonathan M Davis wrote:
> 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)

Fun read: http://cr.yp.to/papers.html#cachetiming - a cache timing attack on AES recovering full key. This flaw was accounted for in Salsa and Chacha design.

On Fri, Oct 27, 2017 at 05:35:17PM +0000, Kagamin via Digitalmars-d wrote:
> On Wednesday, 25 October 2017 at 14:17:21 UTC, Jonathan M Davis wrote:
> > 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)
> 
> Fun read: http://cr.yp.to/papers.html#cachetiming - a cache timing attack on AES recovering full key. This flaw was accounted for in Salsa and Chacha design.

Yes, and this is exactly why I would not trust any D crypto implementation that hasn't been vetted by crypto experts. Nobody would think of such weaknesses when they're writing the code, unless they were already aware of such issues beforehand -- and I doubt many of us here would even be aware of half of the issues crypto implementors must work with on a regular basis.  If even the openSSL folk didn't manage to avoid this exploit, we non-crypto people wouldn't even stand a chance.

Of course, the larger picture is that crypto algorithms are only a small (albeit critical) part of a larger cryptosystem, and oftentimes the weaknesses come not from the algorithm itself but from issues affecting the other parts of the cryptosystem.  You can have the best, most unbreakable crypto (or whatever else) algorithm in your hand, but if you use it incorrectly or just carelessly, you'd still get exploited, and all that crypto strength would be for nought.


T

-- 
Insanity is doing the same thing over and over again and expecting different results.

On Friday, October 27, 2017 09:46:21 Kagamin via Digitalmars-d wrote:
> On Friday, 27 October 2017 at 01:40:07 UTC, Jonathan M Davis
>
> wrote:
> > The problem is that to reasonably interact with the rest of the Windows C/C++ ecosystem, you're pretty much stuck using Microsoft's linker. If we can get that without pulling in all of VS, all the better, but without the linker, we can't link with most existing C/C++ code, which is a big problem.
>
> How so? curl is an import library for libcurl.dll, mingw handles import libraries just fine, same for zlib and mxWidgets. But most of the time you only need to link phobos and some code from dub and that's all.

I don't know anything about import libraries, but we need to be able to link against any C/C++ libraries that someone is doing with VS. If mingw can do that, then it could be an option, though a lot more Windows devs are going to have VS than mingw, and it's my understanding that you have to pull in a fair bit of stuff for mingw (though presumably, it's not as big as VS), so I don't know how much of an improvement that would be.

But the key thing here is that it needs to be easy and straightforward to link against the C/C++ libraries that are generally available for Windows and which folks are writing for their own projects, and that means being compatible with Microsoft and its linker.

- Jonathan M Davis

On Friday, 27 October 2017 at 13:15:38 UTC, codephantom wrote:
> The less the D language partakes in that stuff up.. the better D will be for it.

This mentality is why D is pretty awful on Windows. It's bad enough that DMD doesn't release a 64-bit version on Windows but now you are advocating for the removal of the ability for it to generate 64-bit binaries as well! Yah that won't bring you 10 steps back. Ideals are nice and all, but some people still need to get shit done. This sort of mentality is hurting D, not helping it.

On Friday, 27 October 2017 at 19:44:49 UTC, Jerry wrote:
> On Friday, 27 October 2017 at 13:15:38 UTC, codephantom wrote:
>> The less the D language partakes in that stuff up.. the better D will be for it.
>
> This mentality is why D is pretty awful on Windows. It's bad enough that DMD doesn't release a 64-bit version on Windows but now you are advocating for the removal of the ability for it to generate 64-bit binaries as well! Yah that won't bring you 10 steps back. Ideals are nice and all, but some people still need to get shit done. This sort of mentality is hurting D, not helping it.

Rubbish!

And get you facts straight!

Where did I advocate from the removal of the ability for D to generate 64-bit binaries?

64bit D on Windows, is a problem because of Windows.

The fact that D cannot disentangle itself from the monstrosity known as Visual Studio, is a problem of Visual Studio.

If you really want to get work done, then try wasting 10 hours of your time, trying to work out how to install VS, and all stuff that it depends on - you are even forced to upgrade your operating system too!

At a minimum, I had to download 3.5GB of VS build tools just so I could compile a 64 bit D program (and it took me almost a whole day to work out the correct process).

Is that a problem of D or VS?

Is is it problem that D should accept, and just impose on it's users?

Or should D find a better way?

Which is the worse mentality?

And VS destroys competition and imposes considerable and unacceptable requirements on its users. That is the only mentality you should be questioning.

On Friday, 27 October 2017 at 19:44:49 UTC, Jerry wrote:
> This mentality is why D is pretty awful on Windows.

Have read of this... then you will understand things better:

https://dlang.org/blog/2017/10/25/dmd-windows-and-c/

On Friday, 27 October 2017 at 11:25:13 UTC, codephantom wrote:
> On Friday, 27 October 2017 at 05:20:05 UTC, codephantom wrote:
>> That's it!
>> I've had enough!
>> 4 hours wasted!
>
> ok... I must have done something wrong..
>
> But still, I started testing this whole process at 12:04pm today.
>
> It's now 10:23PM
>
> All I can say, it thank god I used FreeBSD ;-)
>
>> pkg install ldc
> (a few seconds later, I can start compiling 64bit D code).

looks like d has a long way to go on freebsd as well.