This issue is a duplicate of #2171 but I can't seem to comment on it and wanted to add some extra information.

I consider this issue to be very high priority as in this day and age loading non-DEP/ASLR aware modules into applications that
process untrusted input is a huge liability. This is particularly problematic for extension DLLs like GpgOL and probably GpgEX.
Given this is cryptographic software, security of the binaries should be of utmost importance. At a minimum, DEP & ASLR should
be enabled, but there are some additional helpful options that could be enabled for further hardening of the emitted binaries.

A summary of the major relevant compiler options per feature:

• DEP (essential) /NXCOMPAT (on by default since VS2010)
• ASLR (essential) /DYNAMICBASE (on by default since VS2010)
• 64-bit ASLR (recommended) /HIGHENTROPYVA (on by default for 64-bit images but requires VS2012+)
• Digital Signature (recommended) /INTEGRITYCHECK (off by default)

To give you an idea of how far behind GpgOL is with respect to hardening of the binary, Outlook 2016 x64 on the system I'm
writing this on has 285 modules(!) loaded into the process. Only two of those aren't marked as DEP aware (GpgOL being one),
while only one isn't marked as ASLR capable (GpgOL).

Appreciate this is open-source software and there's finite resources to address issues but I feel this should be a high-priority
candidate for whatever resources are available.