The Wiert Corner – irregular stream of stuff

Jeroen W. Pluimers on .NET, C#, Delphi, databases, and personal interests

  • My badges

    Mastodon

  • Twitter Updates

  • My Flickr Stream

    20140508-Delphi-2007--Project-Options--Cannot-Edit-Application-Title-HelpFile-Icon-Theming20140430-Fiddler-Filter-Actions-Button-Run-Filterset-now20140424-VMware-Fusion-6.0.3.-no-reclaimable
    More Photos

  • Pages

  • All categories

  • Enter your email address to subscribe to this blog and receive notifications of new posts by email.

    Join 4,152 other subscribers

Archive for August 8th, 2018

ngHttp2 and OpenSSL win32/i386/x86 and win64/x64_86 (a.k.a. x86_64) builds for Windows

Posted by jpluimers on 2018/08/08

[WayBack] ngHttp2 DLLs has a simple a version scheme. The build inside the Windows PHP distribution includes these version numbers. The TreadSafe versions work as plug in replacement for github.com/grijjy/DelphiScalableClientSockets/tree/master/Bin which is used by github.com/grijjy/GrijjyFoundation/blob/master/Grijjy.Http.pas#L11. You obtain them via [WayBack] PHP For Windows: Binaries and sources Releases; and at the time of writing these were the most recent versions:

[WayBack] OpenSSL DLLs has a much more complex version scheme, as they are numeric but OpenSSL releases are not.

  • DLLs have four numbers a.b.c.d
  • OpenSSL versions have three numbers and a letter a.b.c.x
  • The letter matches the fourth digit, though the ones marked with * have not been used yet:
    # letter # letter # letter # letter # letter remark
    1 a 6 f 11 k 16 p 21 u
    2 b 7 g 12 l 17 q 22 v *
    3 c 8 h 13 m 18 r 23 w *
    4 d 9 i 14 n 19 s 24 x *
    5 e 10 j 15 o 20 t 25 y *
    26 z *

[WayBack] Index of /SSL has “Pre-compiled Win32/64 libraries without external dependencies to the Microsoft Visual Studio Runtime DLLs, except for the system provided msvcrt.dll.”

These work no matter what development/deployment stacks you use (including a Visual Studio based stack).

The most recent version as of writing is 1.0.2o, which maps to 1.0.2.20 which contains libeay32.dll and ssleay32.dll for both the i386-win32 and x86_64-win64 build (not sure why they both use 32 in the name):

openssl-1.0.2o-i386-win32.zip
openssl-1.0.2o-x64_86-win64.zip which supports x86_64 as this site is about the only one using x64_86 in the name

Background reading:

These binaries are for instance used by (most of them are behind or far behind on the OpenSSL version):

  • Avira Antivirus
  • subversion
  • git mingw64
  • VMware Tools
  • Microsoft OneDrive
  • Delphi Indy communications library

Speaking of which: this is a recent Delphi wrapper around libeay32.dll: [WayBack] GitHub – lminuti/Delphi-OpenSSL: Delphi implementation of OpenSSL

–jeroen

Posted in Delphi, Development, OpenSSL, Power User, Security, Software Development | 2 Comments »

Some tips for your Delphi project options hierarchy

Posted by jpluimers on 2018/08/08

Over the years, various Delphi versions have cluttered the Project Options hierarchy quite a bit. This means that when you walk this hierarchy in the Project Options dialog, you will see many bold entries, indicating they have been changed for that level in the hierarchy.

The most important tip is to keep as much as possible at the top level, preferably using relative paths or paths containing $(...) macros.

I usually fill these entries there:

  • “All configurations – All platforms”
    • “Conditional defines” having the base conditional defines
    • “Output directory” (usually including a relative path that includes .\$(Platform)\$(Config)
    • “Search path” with .\$(Platform) when you nave libraries containing DCU files per platform
      • You can even do $(Platform)\$(Config) here if these DCU files are different for configurations (DEBUG/RELEASE) as well.
    • “Unit output directory” so each application gets a unique path (so I include .\$(SanitizedProjectName)\$(Platform)\$(Config) or .\$(Platform)\$(Config)\$(SanitizedProjectName) in the path)
    • Unit scope names (based onSource: Delphi unit prefixes for VCL applications)
  •  “Debug configuration – All platforms”
    • “Conditional defines”: add DEBUG
  • “Release configuration – All platforms”
    • “Conditional defines”: add RELEASE

I include the $(SanitizedProjectName) because it has the name of your project, which I documented at Source: Delphi XE8 does not adhere the $(PROJECTNAME) in a “Unit Output Directory”, but does recognise $(SanitizedProjectName) including many other macros.

Note:

A long time ago, +Uwe Raabe explained that you can use $(SanitizedProjectName) in your project settings to include the actual project name in https://plus.google.com/+DavidNottageDelphiExpert/posts/PcW8CwMQGmH

This works great for DCU output, but not so well for EXE output: when using for instance C:\Binaries\$(SanitizedProjectName) as target, the debugger cannot find the executable as the compiler puts it in the wrong place.

Example with a fresh console project:

0. Ensure C:\Binaries exists and you have write access to it
1. Set Output directory to C:\Binaries\$(SanitizedProjectName)
2. Set Unit output directory to .\$(SanitizedProjectName)\$(Platform)\$(Config)
3. Run:

---------------------------
Error
---------------------------
Could not find program, 'C:\Binaries\%SanitizedProjectName%\Project1.exe'.
---------------------------
OK
---------------------------

The executable is actually at C:\Binaries\Project1.exe, so the compiler does not take the “\$(SanitizedProjectName)” bit into account.

Anyone with a fix for that?

Via [WayBack] A long time ago, +Uwe Raabe explained that you can use $(SanitizedProjectName) in your project settings to include the actual project name in https://pl… – Jeroen Wiert Pluimers – Google+

Uwe Raabe

To make the compiler use the correct path the SanitizedProjectName item must be located before its use in the dproj file. DprojNormalizer assures that since version 2.2.1 and ProjectMagician does so, too. Thus my Project1.exe is written correctly to C:\Binaries\Project1\Project1.exe here on my system.
Unfortunately that won’t fix the main problem, which is that the call to the debugger doesn’t resolve this variable in the first place. Currently I don’t know how this could be fixed.
At [WayBack] Project Settings – variable for name of the project In the Project Settings you can use “macros” or variables like $(Platform)\$(Config). Is there a v… – Graeme Geldenhuys – Google+, Achim Kalwa suggest using this:
Achim Kalwa+2
You may try
$(MSBuildProjectName)

It looks like the .dproj is this using itself too, for instance as this part:

    <Import Project="$(MSBuildProjectName).deployproj" Condition="Exists('$(MSBuildProjectName).deployproj')"/>

–jeroen

Posted in Conference Topics, Conferences, Delphi, Development, Event, Software Development | Leave a Comment »

E2026 or W1023 – take your pick (:

Posted by jpluimers on 2018/08/08

[WayBack] A compiler curiosity I’ve learned today … – David Berneda – Google+: depending on if TEST is defined or not, you get E1026 or W1023.

// This works:
{$IF Declared(Test) and (Test>=100)}
{$ENDIF}

// This not:
{$IF Declared(Test)}
{$IF Test>=100} // "E2026 Constant expression expected"
{$ENDIF}
{$ENDIF}

The W1023 can be alleviated by replacing 100 with +100.

Note that both errors have been documented since at least Delphi 2007:

–jeroen

Source: A compiler curiosity I’ve learned today: // This works: {$IF Declared(Test) …

Posted in Conference Topics, Conferences, Delphi, Development, Software Development | 2 Comments »

 
%d bloggers like this: