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

[Kees Dekker]

Hi,

I tried to compile gzip with visual studio 2015. Unfortunately, a few files 
could not be ported. Microsoft has redesigned the core CRT which affects the 
visibility of (hidden/internals) of e.g. the FILE type. None of the internals 
of the FILE type is not visible anymore (contrary to Visual Studio 2013 and 
before). This affects e.g. freadingc, fpurge.c, fseeko.c, fseterr.c.

If something else than gcc/glibc is used, then each change - up to everything 
that the OS/libc/compiler vendor found as useful - may break gzip. Is it not 
bad programming practice to do so?

My questions are:

1.       why does gzip use and rely on these internals?

2.       Is it intended that gzip should NOT compile on anything else where 
gcc/glibc is not used?

Background information: we are normally just compile gzip to be sure that gzip 
uses the same bits (64-bit) and same C/C++ runtime (DLLs) as used by all our 
binaries. By using the same compiler, end-users only need to install one 
runtime (using vcredistxxx.exe that is shipped with Visual Studio). Moving to 
something else (e.g. pre-compiled gzip) will break this. Also, there is no 
recent gzip version available using Visual Studio runtime DLLs.

Please let me know your thoughts,
Regards,
Kees Dekker