Visual C, C89 and Win32 Shining Light precompiled fixes

[bulk88]

Only test fail I get with Perl 5.25 (yes dev) and VC 2013 is

t/local/38_priv-key.t .................. ok
t/local/39_pkcs12.t .................... OPENSSL_Uplink(526F6340,08): no OPENSSL
_Applink
t/local/39_pkcs12.t .................... Dubious, test returned 1 (wstat 256, 0x
100)
Failed 19/19 subtests
t/local/40_npn_support.t ............... skipped: fork() not supported on MSWin3
2
t/local/41_alpn_support.t .............. skipped: fork() not supported on MSWin3

but OpenSSL's applink is a whole nother complicated story for another PR and I already had a try at
applink in 2015 and it was never merged and I never got around to reviewing my patch on CPAN RT
about applink (a C std lib swap/vtable/abstraction layer OpenSSL invented for Win32 to deal with the
multiple CRTs DLLs in 1 process problem). After this PR a user only needs to install Shining Light 50 MB full size dev MSI and just "click next until it says finish" then no interaction "cpan install Net::SSLeay" and it just works. No env vars, no editing config files. simcop2387 on IRC gets 1% credit for the loop fix.

[h-vn]

I have a Windows machine I'm going to try this pull request. Before proceeding, which Perl distribution is recommended. Is it ActovePerl, Strawberry or something else? RT 101638 mentions ActivePerl but I thought I'd check where this needed.

The RT ticket also has an update by jkahrman from February 2020 that shows updates that were needed to get it compile with OpenSSL applink and pass all tests. Is this PR compatible with the February 2020 applink update? I can try and see what happens.

[bulk88]

https://rt.cpan.org/Public/Bug/Display.html?id=101638 The jkahrman from February 2020 changes were a hack to get my 2015 patch to compile on newer VCs headers bc the PEB struct is always "undocumented" by MS even though poking in it is done by too many apps over the years and nearly standard by now. His patch will break older/newer VCs without alot of testing. Shining path OpenSSL includes a applink.c in its headers, but it feels like a headache to compile it into a .obj from a random disk location and header search path, makefile complexity. So I copied applink.c into the CPAN XS repo to save the headache of finding the file in the Shining Path headers dir, and copying it or putting an absolute path into the makefile to the headers dir.

[bulk88]

I use self compiled VC perl. ActivePerl 5.18 and up use GCC like Strawberry Perl. AP 5.16 and older use Visual C. I'm not sure AP any version is appropriate to test with, since all familys of AP have a precompiled binary package manager and Net::SSLEay is shipped as a binary. Mingw/GCC always uses msvcrt.dll as C lib, so im not sure if applink test always fails during ActivePerl's corporate build farm build and the test fail is intentionally ignored, and I'm not sure what happens on strawberry (applink.c is compiled out or test fail ignored by kmx during his build process). Atleast with shining path/stock SSL, the "root .exe" must export the applink symbol/C function callback, but Win32 Perl is not static linked and there is no control over starting .exe of Win32 perl. Its either a P5P tiny stub that calls main() in libperl or its apache.exe or something. There is not really any runtime API in Windows to ask the OS what was the parent dependency of a certain DLL. Dependency walker starts from root .exe and goes down the static dependency tree specified in the PE files, along with runtime function pointer patching to hook GetProcAddress and LoadLibrary and check the return address/caller of both hook functions to find out what the parent DLL is for a runtime dynamic load.

[h-vn]

Currently available Shining Light OpenSSL MSI installers use the following installation directories:

• C:\Program Files\OpenSSL-Win64\
• C:\Program Files (x86)\OpenSSL-Win32\

At the time of writing, the MSI file names are Win64OpenSSL-1_1_1w.msi, Win64OpenSSL-3_0_12.msi, Win64OpenSSL-3_1_4.msi and Win64OpenSSL-3_2_0.msi. 32bit versions are respectively named Win32OpenSSL-1_1_1w.msi, etc.

In other words, none of the currently available installers use these directories from the commit in this pull request:

• C:\Program Files\OpenSSL\bin\openssl.exe
• C:\Program Files\OpenSSL-Win32\bin\openssl.exe

Therefore I'll skip these two directories and add the aforementioned directories that the current installers use. Older Shining Light OpenSSL installers are not available so I'd say it's reasonable to target them anymore.

[h-vn]

The changes were cherry-picked to pull request #455 and then merged. Some modifications and updates were needed, but most of them were still applied correctly and were up-to-date. Thanks for your contribution.