+ Windows targets can be classified as "native", ones that use Windows API
+ directly, and "hosted" which rely on POSIX-compatible layer. "Native"
+ targets are VC-* (where "VC" stems from abbreviating Microsoft Visual C
+ compiler) and mingw[64]. "Hosted" platforms are Cygwin and MSYS[2]. Even
+ though the latter is not directly supported by OpenSSL Team, it's #1
+ popular choice for building MinGW targets. In the nutshell MinGW builds
+ are always cross-compiled. On Linux and Cygwin they look exactly as such
+ and require --cross-compile-prefix option. While on MSYS[2] it's solved
+ rather by placing gcc that produces "MinGW binary" code 1st on $PATH.
+ This is customarily source of confusion. "Hosted" applications "live" in
+ emulated file system name space with POSIX-y root, mount points, /dev
+ and even /proc. Confusion is intensified by the fact that MSYS2 shell
+ (or rather emulated execve(2) call) examines the binary it's about to
+ start, and if it's found *not* to be linked with MSYS2 POSIX-y thing,
+ command line arguments that look like file names get translated from
+ emulated name space to "native". For example '/c/some/where' becomes
+ 'c:\some\where', '/dev/null' - 'nul'. This creates an illusion that
+ there is no difference between MSYS2 shell and "MinGW binary", but
+ there is. Just keep in mind that "MinGW binary" "experiences" Windows
+ system in exactly same way as one produced by VC, and in its essence
+ is indistinguishable from the latter. (Which by the way is why
+ it's referred to in quotes here, as "MinGW binary", it's just as
+ "native" as it can get.)
+
+ Visual C++ builds, a.k.a. VC-*
+ ==============================
+
+ Requirement details
+ -------------------
+
+ In addition to the requirements and instructions listed in INSTALL,
+ these are required as well:
+
+ - Perl. We recommend ActiveState Perl, available from
+ https://www.activestate.com/ActivePerl. Another viable alternative
+ appears to be Strawberry Perl, http://strawberryperl.com.