bug#25633: porting gzip to Visual Studio 2015 failed due to redesign of CRT

[Kees Dekker]

>> 1.      frexp.c is not needed, as Visual Studio already provides frexp() 
>> function via system libraries.

>But probably with bugs.  And even if it is not needed on your platform,
>it is part of the tarball to replace broken frexp() on systems where it
>is buggy.  Part of configure determines if it is needed on your platform.

Possibly, but why is the chance on bugs on Microsoft's frexp() higher? The only 
(unfortunately common) practice of Microsoft is that they may differ from 
'standard' behavior on Linux.

>I'm less certain on the solutions for the others, although patches to
>gnulib are welcome.

I'm not sure whether I've the knowledge to do so, but today I tried to get 
gdiff also compilable in Cygwin shell (with all required environment variables 
used by Visual Studio's cl.exe properly set) + CC=cl.exe ./configure
And funny enough, I'm recognizing things. Gdiff also uses gnulib. A piece of 
the output is:

      checking absolute name of <wchar.h>... ""

So if a system header is not found, it expands to an empty string. Because 
Microsoft Visual Studio does not recognize the include_next pragma, I used the 
following trick:
The #include[_next] "" directive was replaced by #include "../ucrt/headerfile". 
This works well for the Windows 10 SDK. If an older Visual Studion version is 
used, use #include "../include/headerfile", where <headerfile> can be replaced 
by any system header (e.g. wchar.h or sys/types.h).

What is the recommended to get this behavior changed? It requires changes in 
configure to detect whether a ‘dotdot’ construct works for visual studio (and 
only of compiler matches with cl[.exe]) and if the header indeed exists 
(Windows has e.g. no dirent.h and much other UNIX style headers).