NOISSUE add archived projects

Signed-off-by: Mehmet Samet Duman <yongdohyun@projecttick.org>

8 files changed, 1074 insertions, 0 deletions

diff --git a/archived/ptlibzippy/win32/DLL_FAQ.txt b/archived/ptlibzippy/win32/DLL_FAQ.txt
new file mode 100644
index 0000000000..e7f62194db
--- /dev/null
+++ b/archived/ptlibzippy/win32/DLL_FAQ.txt
@@ -0,0 +1,381 @@
+
+            Frequently Asked Questions about PTLIBZIPPY1.DLL
+
+
+This document describes the design, the rationale, and the usage
+of the common DLL build of PTlibzippy, named PTLIBZIPPY1.DLL.  If you have
+general questions about PTlibzippy, you should see the file "FAQ" found
+in the PTlibzippy distribution, or at the following location:
+  http://projecttick.org/p/zlib/ptlibzippy_faq.html
+
+
+ 1. What is PTLIBZIPPY1.DLL, and how can I get it?
+
+  - PTLIBZIPPY1.DLL is the common build of PTlibzippy as a DLL.
+    (Please remark the character '1' in the name.)
+
+    Applications that link to PTLIBZIPPY1.DLL can rely on the following
+    specification:
+
+    * The exported symbols are exclusively defined in the source
+      files "ptlibzippy.h" and "ptlibzippy.def", found in an official PTlibzippy
+      source distribution.
+    * The symbols are exported by name, not by ordinal.
+    * The exported names are undecorated.
+    * The calling convention of functions is "C" (CDECL).
+    * The PTLIBZIPPY1.DLL binary is linked to MSVCRT.DLL.
+
+    The archive in which PTLIBZIPPY1.DLL is bundled contains compiled
+    test programs that must run with a valid build of PTLIBZIPPY1.DLL.
+    It is recommended to download the prebuilt DLL from the PTlibzippy
+    web site, instead of building it yourself, to avoid potential
+    incompatibilities that could be introduced by your compiler
+    and build settings.  If you do build the DLL yourself, please
+    make sure that it complies with all the above requirements,
+    and it runs with the precompiled test programs, bundled with
+    the original PTLIBZIPPY1.DLL distribution.
+
+    If, for any reason, you need to build an incompatible DLL,
+    please use a different file name.
+
+
+ 2. Why did you change the name of the DLL to PTLIBZIPPY1.DLL?
+    What happened to the old PTLIBZIPPY.DLL?
+
+  - The old PTLIBZIPPY.DLL, built from ptlibzippy-1.1.4 or earlier, required
+    compilation settings that were incompatible to those used by
+    a static build.  The DLL settings were supposed to be enabled
+    by defining the macro PTLIBZIPPY_DLL, before including "ptlibzippy.h".
+    Incorrect handling of this macro was silently accepted at
+    build time, resulting in two major problems:
+
+    * PTLIBZIPPY_DLL was missing from the old makefile.  When building
+      the DLL, not all people added it to the build options.  In
+      consequence, incompatible incarnations of PTLIBZIPPY.DLL started
+      to circulate around the net.
+
+    * When switching from using the static library to using the
+      DLL, applications had to define the PTLIBZIPPY_DLL macro and
+      to recompile all the sources that contained calls to PTlibzippy
+      functions.  Failure to do so resulted in creating binaries
+      that were unable to run with the official PTLIBZIPPY.DLL build.
+
+    The only possible solution that we could foresee was to make
+    a binary-incompatible change in the DLL interface, in order to
+    remove the dependency on the PTLIBZIPPY_DLL macro, and to release
+    the new DLL under a different name.
+
+    We chose the name PTLIBZIPPY1.DLL, where '1' indicates the major
+    PTlibzippy version number.  We hope that we will not have to break
+    the binary compatibility again, at least not as long as the
+    PTlibzippy-1.x series will last.
+
+    There is still a PTLIBZIPPY_DLL macro, that can trigger a more
+    efficient build and use of the DLL, but compatibility no
+    longer dependents on it.
+
+
+ 3. Can I build PTLIBZIPPY.DLL from the new PTlibzippy sources, and replace
+    an old PTLIBZIPPY.DLL, that was built from ptlibzippy-1.1.4 or earlier?
+
+  - In principle, you can do it by assigning calling convention
+    keywords to the macros ZEXPORT and ZEXPORTVA.  In practice,
+    it depends on what you mean by "an old PTLIBZIPPY.DLL", because the
+    old DLL exists in several mutually-incompatible versions.
+    You have to find out first what kind of calling convention is
+    being used in your particular PTLIBZIPPY.DLL build, and to use the
+    same one in the new build.  If you don't know what this is all
+    about, you might be better off if you would just leave the old
+    DLL intact.
+
+
+ 4. Can I compile my application using the new PTlibzippy interface, and
+    link it to an old PTLIBZIPPY.DLL, that was built from ptlibzippy-1.1.4 or
+    earlier?
+
+  - The official answer is "no"; the real answer depends again on
+    what kind of PTLIBZIPPY.DLL you have.  Even if you are lucky, this
+    course of action is unreliable.
+
+    If you rebuild your application and you intend to use a newer
+    version of PTlibzippy (post- 1.1.4), it is strongly recommended to
+    link it to the new PTLIBZIPPY1.DLL.
+
+
+ 5. Why are the PTlibzippy symbols exported by name, and not by ordinal?
+
+  - Although exporting symbols by ordinal is a little faster, it
+    is risky.  Any single glitch in the maintenance or use of the
+    DEF file that contains the ordinals can result in incompatible
+    builds and frustrating crashes.  Simply put, the benefits of
+    exporting symbols by ordinal do not justify the risks.
+
+    Technically, it should be possible to maintain ordinals in
+    the DEF file, and still export the symbols by name.  Ordinals
+    exist in every DLL, and even if the dynamic linking performed
+    at the DLL startup is searching for names, ordinals serve as
+    hints, for a faster name lookup.  However, if the DEF file
+    contains ordinals, the Microsoft linker automatically builds
+    an implib that will cause the executables linked to it to use
+    those ordinals, and not the names.  It is interesting to
+    notice that the GNU linker for Win32 does not suffer from this
+    problem.
+
+    It is possible to avoid the DEF file if the exported symbols
+    are accompanied by a "__declspec(dllexport)" attribute in the
+    source files.  You can do this in PTlibzippy by predefining the
+    PTLIBZIPPY_DLL macro.
+
+
+ 6. I see that the PTLIBZIPPY1.DLL functions use the "C" (CDECL) calling
+    convention.  Why not use the STDCALL convention?
+    STDCALL is the standard convention in Win32, and I need it in
+    my Visual Basic project!
+
+    (For readability, we use CDECL to refer to the convention
+     triggered by the "__cdecl" keyword, STDCALL to refer to
+     the convention triggered by "__stdcall", and FASTCALL to
+     refer to the convention triggered by "__fastcall".)
+
+  - Most of the native Windows API functions (without varargs) use
+    indeed the WINAPI convention (which translates to STDCALL in
+    Win32), but the standard C functions use CDECL.  If a user
+    application is intrinsically tied to the Windows API (e.g.
+    it calls native Windows API functions such as CreateFile()),
+    sometimes it makes sense to decorate its own functions with
+    WINAPI.  But if ANSI C or POSIX portability is a goal (e.g.
+    it calls standard C functions such as fopen()), it is not a
+    sound decision to request the inclusion of <windows.h>, or to
+    use non-ANSI constructs, for the sole purpose to make the user
+    functions STDCALL-able.
+
+    The functionality offered by PTlibzippy is not in the category of
+    "Windows functionality", but is more like "C functionality".
+
+    Technically, STDCALL is not bad; in fact, it is slightly
+    faster than CDECL, and it works with variable-argument
+    functions, just like CDECL.  It is unfortunate that, in spite
+    of using STDCALL in the Windows API, it is not the default
+    convention used by the C compilers that run under Windows.
+    The roots of the problem reside deep inside the unsafety of
+    the K&R-style function prototypes, where the argument types
+    are not specified; but that is another story for another day.
+
+    The remaining fact is that CDECL is the default convention.
+    Even if an explicit convention is hard-coded into the function
+    prototypes inside C headers, problems may appear.  The
+    necessity to expose the convention in users' callbacks is one
+    of these problems.
+
+    The calling convention issues are also important when using
+    PTlibzippy in other programming languages.  Some of them, like Ada
+    (GNAT) and Fortran (GNU G77), have C bindings implemented
+    initially on Unix, and relying on the C calling convention.
+    On the other hand, the pre- .NET versions of Microsoft Visual
+    Basic require STDCALL, while Borland Delphi prefers, although
+    it does not require, FASTCALL.
+
+    In fairness to all possible uses of PTlibzippy outside the C
+    programming language, we choose the default "C" convention.
+    Anyone interested in different bindings or conventions is
+    encouraged to maintain specialized projects.  The "contrib/"
+    directory from the PTlibzippy distribution already holds a couple
+    of foreign bindings, such as Ada, C++, and Delphi.
+
+
+ 7. I need a DLL for my Visual Basic project.  What can I do?
+
+  - Define the PTLIBZIPPY_WINAPI macro before including "ptlibzippy.h", when
+    building both the DLL and the user application (except that
+    you don't need to define anything when using the DLL in Visual
+    Basic).  The PTLIBZIPPY_WINAPI macro will switch on the WINAPI
+    (STDCALL) convention.  The name of this DLL must be different
+    than the official PTLIBZIPPY1.DLL.
+
+    Gilles Vollant has contributed a build named PTLIBZIPPYWAPI.DLL,
+    with the PTLIBZIPPY_WINAPI macro turned on, and with the minizip
+    functionality built in.  For more information, please read
+    the notes inside "contrib/vstudio/readme.txt", found in the
+    PTlibzippy distribution.
+
+
+ 8. I need to use PTlibzippy in my Microsoft .NET project.  What can I
+    do?
+
+  - Henrik Ravn has contributed a .NET wrapper around PTlibzippy.  Look
+    into contrib/dotzlib/, inside the PTlibzippy distribution.
+
+
+ 9. If my application uses PTLIBZIPPY1.DLL, should I link it to
+    MSVCRT.DLL?  Why?
+
+  - It is not required, but it is recommended to link your
+    application to MSVCRT.DLL, if it uses PTLIBZIPPY1.DLL.
+
+    The executables (.EXE, .DLL, etc.) that are involved in the
+    same process and are using the C run-time library (i.e. they
+    are calling standard C functions), must link to the same
+    library.  There are several libraries in the Win32 system:
+    CRTDLL.DLL, MSVCRT.DLL, the static C libraries, etc.
+    Since PTLIBZIPPY1.DLL is linked to MSVCRT.DLL, the executables that
+    depend on it should also be linked to MSVCRT.DLL.
+
+
+10. Why are you saying that PTLIBZIPPY1.DLL and my application should
+    be linked to the same C run-time (CRT) library?  I linked my
+    application and my DLLs to different C libraries (e.g. my
+    application to a static library, and my DLLs to MSVCRT.DLL),
+    and everything works fine.
+
+  - If a user library invokes only pure Win32 API (accessible via
+    <windows.h> and the related headers), its DLL build will work
+    in any context.  But if this library invokes standard C API,
+    things get more complicated.
+
+    There is a single Win32 library in a Win32 system.  Every
+    function in this library resides in a single DLL module, that
+    is safe to call from anywhere.  On the other hand, there are
+    multiple versions of the C library, and each of them has its
+    own separate internal state.  Standalone executables and user
+    DLLs that call standard C functions must link to a C run-time
+    (CRT) library, be it static or shared (DLL).  Intermixing
+    occurs when an executable (not necessarily standalone) and a
+    DLL are linked to different CRTs, and both are running in the
+    same process.
+
+    Intermixing multiple CRTs is possible, as long as their
+    internal states are kept intact.  The Microsoft Knowledge Base
+    articles KB94248 "HOWTO: Use the C Run-Time" and KB140584
+    "HOWTO: Link with the Correct C Run-Time (CRT) Library"
+    mention the potential problems raised by intermixing.
+
+    If intermixing works for you, it's because your application
+    and DLLs are avoiding the corruption of each of the CRTs'
+    internal states, maybe by careful design, or maybe by fortune.
+
+    Also note that linking PTLIBZIPPY1.DLL to non-Microsoft CRTs, such
+    as those provided by Borland, raises similar problems.
+
+
+11. Why are you linking PTLIBZIPPY1.DLL to MSVCRT.DLL?
+
+  - MSVCRT.DLL exists on every Windows 95 with a new service pack
+    installed, or with Microsoft Internet Explorer 4 or later, and
+    on all other Windows 4.x or later (Windows 98, Windows NT 4,
+    or later).  It is freely distributable; if not present in the
+    system, it can be downloaded from Microsoft or from other
+    software provider for free.
+
+    The fact that MSVCRT.DLL does not exist on a virgin Windows 95
+    is not so problematic.  Windows 95 is scarcely found nowadays,
+    Microsoft ended its support a long time ago, and many recent
+    applications from various vendors, including Microsoft, do not
+    even run on it.  Furthermore, no serious user should run
+    Windows 95 without a proper update installed.
+
+
+12. Why are you not linking PTLIBZIPPY1.DLL to
+    <<my favorite C run-time library>> ?
+
+  - We considered and abandoned the following alternatives:
+
+    * Linking PTLIBZIPPY1.DLL to a static C library (LIBC.LIB, or
+      LIBCMT.LIB) is not a good option.  People are using the DLL
+      mainly to save disk space.  If you are linking your program
+      to a static C library, you may as well consider linking PTlibzippy
+      in statically, too.
+
+    * Linking PTLIBZIPPY1.DLL to CRTDLL.DLL looks appealing, because
+      CRTDLL.DLL is present on every Win32 installation.
+      Unfortunately, it has a series of problems: it does not
+      work properly with Microsoft's C++ libraries, it does not
+      provide support for 64-bit file offsets, (and so on...),
+      and Microsoft discontinued its support a long time ago.
+
+    * Linking PTLIBZIPPY1.DLL to MSVCR70.DLL or MSVCR71.DLL, supplied
+      with the Microsoft .NET platform, and Visual C++ 7.0/7.1,
+      raises problems related to the status of PTLIBZIPPY1.DLL as a
+      system component.  According to the Microsoft Knowledge Base
+      article KB326922 "INFO: Redistribution of the Shared C
+      Runtime Component in Visual C++ .NET", MSVCR70.DLL and
+      MSVCR71.DLL are not supposed to function as system DLLs,
+      because they may clash with MSVCRT.DLL.  Instead, the
+      application's installer is supposed to put these DLLs
+      (if needed) in the application's private directory.
+      If PTLIBZIPPY1.DLL depends on a non-system runtime, it cannot
+      function as a redistributable system component.
+
+    * Linking PTLIBZIPPY1.DLL to non-Microsoft runtimes, such as
+      Borland's, or Cygwin's, raises problems related to the
+      reliable presence of these runtimes on Win32 systems.
+      It's easier to let the DLL build of PTlibzippy up to the people
+      who distribute these runtimes, and who may proceed as
+      explained in the answer to Question 14.
+
+
+13. If PTLIBZIPPY1.DLL cannot be linked to MSVCR70.DLL or MSVCR71.DLL,
+    how can I build/use PTLIBZIPPY1.DLL in Microsoft Visual C++ 7.0
+    (Visual Studio .NET) or newer?
+
+  - Due to the problems explained in the Microsoft Knowledge Base
+    article KB326922 (see the previous answer), the C runtime that
+    comes with the VC7 environment is no longer considered a
+    system component.  That is, it should not be assumed that this
+    runtime exists, or may be installed in a system directory.
+    Since PTLIBZIPPY1.DLL is supposed to be a system component, it may
+    not depend on a non-system component.
+
+    In order to link PTLIBZIPPY1.DLL and your application to MSVCRT.DLL
+    in VC7, you need the library of Visual C++ 6.0 or older.  If
+    you don't have this library at hand, it's probably best not to
+    use PTLIBZIPPY1.DLL.
+
+    We are hoping that, in the future, Microsoft will provide a
+    way to build applications linked to a proper system runtime,
+    from the Visual C++ environment.  Until then, you have a
+    couple of alternatives, such as linking PTlibzippy in statically.
+    If your application requires dynamic linking, you may proceed
+    as explained in the answer to Question 14.
+
+
+14. I need to link my own DLL build to a CRT different than
+    MSVCRT.DLL.  What can I do?
+
+  - Feel free to rebuild the DLL from the PTlibzippy sources, and link
+    it the way you want.  You should, however, clearly state that
+    your build is unofficial.  You should give it a different file
+    name, and/or install it in a private directory that can be
+    accessed by your application only, and is not visible to the
+    others (i.e. it's neither in the PATH, nor in the SYSTEM or
+    SYSTEM32 directories).  Otherwise, your build may clash with
+    applications that link to the official build.
+
+    For example, in Cygwin, PTlibzippy is linked to the Cygwin runtime
+    CYGWIN1.DLL, and it is distributed under the name CYGZ.DLL.
+
+
+15. May I include additional pieces of code that I find useful,
+    link them in PTLIBZIPPY1.DLL, and export them?
+
+  - No.  A legitimate build of PTLIBZIPPY1.DLL must not include code
+    that does not originate from the official PTlibzippy source code.
+    But you can make your own private DLL build, under a different
+    file name, as suggested in the previous answer.
+
+    For example, PTlibzippy is a part of the VCL library, distributed
+    with Borland Delphi and C++ Builder.  The DLL build of VCL
+    is a redistributable file, named VCLxx.DLL.
+
+
+16. May I remove some functionality out of PTLIBZIPPY1.DLL, by enabling
+    macros like NO_GZCOMPRESS or NO_GZIP at compile time?
+
+  - No.  A legitimate build of PTLIBZIPPY1.DLL must provide the complete
+    PTlibzippy functionality, as implemented in the official PTlibzippy source
+    code.  But you can make your own private DLL build, under a
+    different file name, as suggested in the previous answer.
+
+**
+
+This document is written and maintained by
+Cosmin Truta <cosmint@cs.ubbcluj.ro>
diff --git a/archived/ptlibzippy/win32/Makefile.bor b/archived/ptlibzippy/win32/Makefile.bor
new file mode 100644
index 0000000000..3b635b87b8
--- /dev/null
+++ b/archived/ptlibzippy/win32/Makefile.bor
@@ -0,0 +1,109 @@
+# Makefile for PTlibzippy
+# Borland C++ for Win32
+#
+# Usage:
+#  make -f win32/Makefile.bor
+
+# ------------ Borland C++ ------------
+
+# Optional nonstandard preprocessor flags (e.g. -DMAX_MEM_LEVEL=7)
+# should be added to the environment via "set LOCAL_PTLIBZIPPY=-DFOO" or
+# added to the declaration of LOC here:
+LOC = $(LOCAL_PTLIBZIPPY)
+
+CC = bcc32
+AS = bcc32
+LD = bcc32
+AR = tlib
+CFLAGS  = -a -d -k- -O2 $(LOC)
+ASFLAGS = $(LOC)
+LDFLAGS = $(LOC)
+
+
+# variables
+PTLIBZIPPY_LIB = ptlibzippy.lib
+
+OBJ1 = adler32.obj compress.obj crc32.obj deflate.obj gzclose.obj gzlib.obj gzread.obj
+OBJ2 = gzwrite.obj infback.obj inffast.obj inflate.obj inftrees.obj trees.obj uncompr.obj ptzippyutil.obj
+#OBJA =
+OBJP1 = +adler32.obj+compress.obj+crc32.obj+deflate.obj+gzclose.obj+gzlib.obj+gzread.obj
+OBJP2 = +gzwrite.obj+infback.obj+inffast.obj+inflate.obj+inftrees.obj+trees.obj+uncompr.obj+ptzippyutil.obj
+#OBJPA=
+
+
+# targets
+all: $(PTLIBZIPPY_LIB) example.exe minigzip.exe
+
+.c.obj:
+	$(CC) -c $(CFLAGS) $<
+
+.asm.obj:
+	$(AS) -c $(ASFLAGS) $<
+
+adler32.obj: adler32.c ptlibzippy.h ptzippyconf.h
+
+compress.obj: compress.c ptlibzippy.h ptzippyconf.h
+
+crc32.obj: crc32.c ptlibzippy.h ptzippyconf.h crc32.h
+
+deflate.obj: deflate.c deflate.h ptzippyutil.h ptlibzippy.h ptzippyconf.h
+
+gzclose.obj: gzclose.c ptlibzippy.h ptzippyconf.h ptzippyguts.h
+
+gzlib.obj: gzlib.c ptlibzippy.h ptzippyconf.h ptzippyguts.h
+
+gzread.obj: gzread.c ptlibzippy.h ptzippyconf.h ptzippyguts.h
+
+gzwrite.obj: gzwrite.c ptlibzippy.h ptzippyconf.h ptzippyguts.h
+
+infback.obj: infback.c ptzippyutil.h ptlibzippy.h ptzippyconf.h inftrees.h inflate.h \
+ inffast.h inffixed.h
+
+inffast.obj: inffast.c ptzippyutil.h ptlibzippy.h ptzippyconf.h inftrees.h inflate.h \
+ inffast.h
+
+inflate.obj: inflate.c ptzippyutil.h ptlibzippy.h ptzippyconf.h inftrees.h inflate.h \
+ inffast.h inffixed.h
+
+inftrees.obj: inftrees.c ptzippyutil.h ptlibzippy.h ptzippyconf.h inftrees.h
+
+trees.obj: trees.c ptzippyutil.h ptlibzippy.h ptzippyconf.h deflate.h trees.h
+
+uncompr.obj: uncompr.c ptlibzippy.h ptzippyconf.h
+
+ptzippyutil.obj: ptzippyutil.c ptzippyutil.h ptlibzippy.h ptzippyconf.h
+
+example.obj: test/example.c ptlibzippy.h ptzippyconf.h
+
+minigzip.obj: test/minigzip.c ptlibzippy.h ptzippyconf.h
+
+
+# For the sake of the old Borland make,
+# the command line is cut to fit in the MS-DOS 128 byte limit:
+$(PTLIBZIPPY_LIB): $(OBJ1) $(OBJ2) $(OBJA)
+	-del $(PTLIBZIPPY_LIB)
+	$(AR) $(PTLIBZIPPY_LIB) $(OBJP1)
+	$(AR) $(PTLIBZIPPY_LIB) $(OBJP2)
+	$(AR) $(PTLIBZIPPY_LIB) $(OBJPA)
+
+
+# testing
+test: example.exe minigzip.exe
+	example
+	echo hello world | minigzip | minigzip -d
+
+example.exe: example.obj $(PTLIBZIPPY_LIB)
+	$(LD) $(LDFLAGS) example.obj $(PTLIBZIPPY_LIB)
+
+minigzip.exe: minigzip.obj $(PTLIBZIPPY_LIB)
+	$(LD) $(LDFLAGS) minigzip.obj $(PTLIBZIPPY_LIB)
+
+
+# cleanup
+clean:
+	-del $(PTLIBZIPPY_LIB)
+	-del *.obj
+	-del *.exe
+	-del *.tds
+	-del ptlibzippy.bak
+	-del foo.gz
diff --git a/archived/ptlibzippy/win32/Makefile.gcc b/archived/ptlibzippy/win32/Makefile.gcc
new file mode 100644
index 0000000000..bb035d6545
--- /dev/null
+++ b/archived/ptlibzippy/win32/Makefile.gcc
@@ -0,0 +1,178 @@
+# Makefile for PTlibzippy, derived from Makefile.dj2.
+# Modified for mingw32 by C. Spieler, 6/16/98.
+# Updated for PTlibzippy 1.2.x by Christian Spieler and Cosmin Truta, Mar-2003.
+# Last updated: Mar 2012.
+# Tested under Cygwin and MinGW.
+
+# Copyright (C) 1995-2026 Jean-loup Gailly.
+# Copyright (C) 2026 Project Tick.
+# For conditions of distribution and use, see copyright notice in ptlibzippy.h
+
+# To compile, or to compile and test, type from the top level PTlibzippy directory:
+#
+#   make -fwin32/Makefile.gcc;  make test testdll -fwin32/Makefile.gcc
+#
+# To install libptlibzippy.a, ptzippyconf.h and ptlibzippy.h in the system directories, type:
+#
+#   make install -fwin32/Makefile.gcc
+#
+# BINARY_PATH, INCLUDE_PATH and LIBRARY_PATH must be set.
+#
+# To install the shared lib, append SHARED_MODE=1 to the make command :
+#
+#   make install -fwin32/Makefile.gcc SHARED_MODE=1
+
+# Note:
+# If the platform is *not* MinGW (e.g. it is Cygwin or UWIN),
+# the DLL name should be changed from "ptlibzippy1.dll".
+
+STATICLIB = libptlibzippy.a
+SHAREDLIB = ptlibzippy1.dll
+IMPLIB    = libptlibzippy.dll.a
+
+#
+# Set to 1 if shared object needs to be installed
+#
+SHARED_MODE=0
+
+#LOC = -DPTLIBZIPPY_DEBUG -g
+
+PREFIX =
+CC = $(PREFIX)gcc
+CFLAGS = $(LOC) -O3 -Wall
+
+AS = $(CC)
+ASFLAGS = $(LOC) -Wall
+
+LD = $(CC)
+LDFLAGS = $(LOC)
+
+AR = $(PREFIX)ar
+ARFLAGS = rcs
+
+RC = $(PREFIX)windres
+RCFLAGS =
+
+STRIP = $(PREFIX)strip
+
+CP = cp -fp
+# If GNU install is available, replace $(CP) with install.
+INSTALL = $(CP)
+RM = rm -f
+
+prefix ?= /usr/local
+exec_prefix = $(prefix)
+
+OBJS = adler32.o compress.o crc32.o deflate.o gzclose.o gzlib.o gzread.o \
+       gzwrite.o infback.o inffast.o inflate.o inftrees.o trees.o uncompr.o ptzippyutil.o
+OBJA =
+
+all: $(STATICLIB) $(SHAREDLIB) $(IMPLIB) example.exe minigzip.exe example_d.exe minigzip_d.exe
+
+test: example.exe minigzip.exe
+	./example
+	echo hello world | ./minigzip | ./minigzip -d
+
+testdll: example_d.exe minigzip_d.exe
+	./example_d
+	echo hello world | ./minigzip_d | ./minigzip_d -d
+
+%.o: %.c
+	$(CC) $(CFLAGS) -c -o $@ $<
+
+%.o: %.S
+	$(AS) $(ASFLAGS) -c -o $@ $<
+
+$(STATICLIB): $(OBJS) $(OBJA)
+	$(AR) $(ARFLAGS) $@ $(OBJS) $(OBJA)
+
+$(IMPLIB): $(SHAREDLIB)
+
+$(SHAREDLIB): win32/ptlibzippy.def $(OBJS) $(OBJA) ptlibzippyrc.o
+	$(CC) -shared -static-libgcc -Wl,--out-implib,$(IMPLIB) $(LDFLAGS) \
+	-o $@ win32/ptlibzippy.def $(OBJS) $(OBJA) ptlibzippyrc.o
+	$(STRIP) $@
+
+example.exe: example.o $(STATICLIB)
+	$(LD) $(LDFLAGS) -o $@ example.o $(STATICLIB)
+	$(STRIP) $@
+
+minigzip.exe: minigzip.o $(STATICLIB)
+	$(LD) $(LDFLAGS) -o $@ minigzip.o $(STATICLIB)
+	$(STRIP) $@
+
+example_d.exe: example.o $(IMPLIB)
+	$(LD) $(LDFLAGS) -o $@ example.o $(IMPLIB)
+	$(STRIP) $@
+
+minigzip_d.exe: minigzip.o $(IMPLIB)
+	$(LD) $(LDFLAGS) -o $@ minigzip.o $(IMPLIB)
+	$(STRIP) $@
+
+example.o: test/example.c ptlibzippy.h ptzippyconf.h
+	$(CC) $(CFLAGS) -I. -c -o $@ test/example.c
+
+minigzip.o: test/minigzip.c ptlibzippy.h ptzippyconf.h
+	$(CC) $(CFLAGS) -I. -c -o $@ test/minigzip.c
+
+ptlibzippyrc.o: win32/ptlibzippy1.rc
+	$(RC) $(RCFLAGS) -o $@ win32/ptlibzippy1.rc
+
+.PHONY: install uninstall clean
+
+install: ptlibzippy.h ptzippyconf.h $(STATICLIB) $(IMPLIB)
+	@if test -z "$(DESTDIR)$(INCLUDE_PATH)" -o -z "$(DESTDIR)$(LIBRARY_PATH)" -o -z "$(DESTDIR)$(BINARY_PATH)"; then \
+		echo INCLUDE_PATH, LIBRARY_PATH, and BINARY_PATH must be specified; \
+		exit 1; \
+	fi
+	-@mkdir -p '$(DESTDIR)$(INCLUDE_PATH)'
+	-@mkdir -p '$(DESTDIR)$(LIBRARY_PATH)' '$(DESTDIR)$(LIBRARY_PATH)'/pkgconfig
+	-if [ "$(SHARED_MODE)" = "1" ]; then \
+		mkdir -p '$(DESTDIR)$(BINARY_PATH)'; \
+		$(INSTALL) $(SHAREDLIB) '$(DESTDIR)$(BINARY_PATH)'; \
+		$(INSTALL) $(IMPLIB) '$(DESTDIR)$(LIBRARY_PATH)'; \
+	fi
+	-$(INSTALL) ptlibzippy.h '$(DESTDIR)$(INCLUDE_PATH)'
+	-$(INSTALL) ptzippyconf.h '$(DESTDIR)$(INCLUDE_PATH)'
+	-$(INSTALL) $(STATICLIB) '$(DESTDIR)$(LIBRARY_PATH)'
+	sed \
+		-e 's|@prefix@|${prefix}|g' \
+		-e 's|@exec_prefix@|${exec_prefix}|g' \
+		-e 's|@libdir@|$(LIBRARY_PATH)|g' \
+		-e 's|@sharedlibdir@|$(LIBRARY_PATH)|g' \
+		-e 's|@includedir@|$(INCLUDE_PATH)|g' \
+		-e 's|@VERSION@|'`sed -n -e '/VERSION "/s/.*"\(.*\)".*/\1/p' ptlibzippy.h`'|g' \
+		ptlibzippy.pc.in > '$(DESTDIR)$(LIBRARY_PATH)'/pkgconfig/ptlibzippy.pc
+
+uninstall:
+	-if [ "$(SHARED_MODE)" = "1" ]; then \
+		$(RM) '$(DESTDIR)$(BINARY_PATH)'/$(SHAREDLIB); \
+		$(RM) '$(DESTDIR)$(LIBRARY_PATH)'/$(IMPLIB); \
+	fi
+	-$(RM) '$(DESTDIR)$(INCLUDE_PATH)'/ptlibzippy.h
+	-$(RM) '$(DESTDIR)$(INCLUDE_PATH)'/ptzippyconf.h
+	-$(RM) '$(DESTDIR)$(LIBRARY_PATH)'/$(STATICLIB)
+
+clean:
+	-$(RM) $(STATICLIB)
+	-$(RM) $(SHAREDLIB)
+	-$(RM) $(IMPLIB)
+	-$(RM) *.o
+	-$(RM) *.exe
+	-$(RM) foo.gz
+
+adler32.o: ptlibzippy.h ptzippyconf.h
+compress.o: ptlibzippy.h ptzippyconf.h
+crc32.o: crc32.h ptlibzippy.h ptzippyconf.h
+deflate.o: deflate.h ptzippyutil.h ptlibzippy.h ptzippyconf.h
+gzclose.o: ptlibzippy.h ptzippyconf.h ptzippyguts.h
+gzlib.o: ptlibzippy.h ptzippyconf.h ptzippyguts.h
+gzread.o: ptlibzippy.h ptzippyconf.h ptzippyguts.h
+gzwrite.o: ptlibzippy.h ptzippyconf.h ptzippyguts.h
+inffast.o: ptzippyutil.h ptlibzippy.h ptzippyconf.h inftrees.h inflate.h inffast.h
+inflate.o: ptzippyutil.h ptlibzippy.h ptzippyconf.h inftrees.h inflate.h inffast.h
+infback.o: ptzippyutil.h ptlibzippy.h ptzippyconf.h inftrees.h inflate.h inffast.h
+inftrees.o: ptzippyutil.h ptlibzippy.h ptzippyconf.h inftrees.h
+trees.o: deflate.h ptzippyutil.h ptlibzippy.h ptzippyconf.h trees.h
+uncompr.o: ptlibzippy.h ptzippyconf.h
+ptzippyutil.o: ptzippyutil.h ptlibzippy.h ptzippyconf.h
diff --git a/archived/ptlibzippy/win32/Makefile.msc b/archived/ptlibzippy/win32/Makefile.msc
new file mode 100644
index 0000000000..0d75772d55
--- /dev/null
+++ b/archived/ptlibzippy/win32/Makefile.msc
@@ -0,0 +1,159 @@
+# Makefile for PTlibzippy using Microsoft (Visual) C
+# PTlibzippy is copyright (C) 1995-2017 Jean-loup Gailly and Mark Adler
+#
+# Usage:
+#   nmake -f win32/Makefile.msc                          (standard build)
+#   nmake -f win32/Makefile.msc LOC=-DFOO                (nonstandard build)
+
+# The toplevel directory of the source tree.
+#
+TOP = .
+
+# optional build flags
+LOC =
+
+# variables
+STATICLIB = ptlibzippy.lib
+SHAREDLIB = ptlibzippy1.dll
+IMPLIB    = zdll.lib
+
+CC = cl
+AS = ml
+LD = link
+AR = lib
+RC = rc
+CFLAGS  = -nologo -MD -W3 -O2 -Oy- -Zi -Fd"ptlibzippy" $(LOC)
+WFLAGS  = -D_CRT_SECURE_NO_DEPRECATE -D_CRT_NONSTDC_NO_DEPRECATE
+ASFLAGS = -coff -Zi $(LOC)
+LDFLAGS = -nologo -debug -incremental:no -opt:ref
+ARFLAGS = -nologo
+RCFLAGS = /dWIN32 /r
+
+OBJS = adler32.obj compress.obj crc32.obj deflate.obj gzclose.obj gzlib.obj gzread.obj \
+       gzwrite.obj infback.obj inflate.obj inftrees.obj inffast.obj trees.obj uncompr.obj ptzippyutil.obj
+OBJA =
+
+
+# targets
+all: $(STATICLIB) $(SHAREDLIB) $(IMPLIB) \
+     example.exe minigzip.exe example_d.exe minigzip_d.exe
+
+$(STATICLIB): $(OBJS) $(OBJA)
+	$(AR) $(ARFLAGS) -out:$@ $(OBJS) $(OBJA)
+
+$(IMPLIB): $(SHAREDLIB)
+
+$(SHAREDLIB): $(TOP)/win32/ptlibzippy.def $(OBJS) $(OBJA) ptlibzippy1.res
+	$(LD) $(LDFLAGS) -def:$(TOP)/win32/ptlibzippy.def -dll -implib:$(IMPLIB) \
+	  -out:$@ -base:0x5A4C0000 $(OBJS) $(OBJA) ptlibzippy1.res
+	if exist $@.manifest \
+	  mt -nologo -manifest $@.manifest -outputresource:$@;2
+
+example.exe: example.obj $(STATICLIB)
+	$(LD) $(LDFLAGS) example.obj $(STATICLIB)
+	if exist $@.manifest \
+	  mt -nologo -manifest $@.manifest -outputresource:$@;1
+
+minigzip.exe: minigzip.obj $(STATICLIB)
+	$(LD) $(LDFLAGS) minigzip.obj $(STATICLIB)
+	if exist $@.manifest \
+	  mt -nologo -manifest $@.manifest -outputresource:$@;1
+
+example_d.exe: example.obj $(IMPLIB)
+	$(LD) $(LDFLAGS) -out:$@ example.obj $(IMPLIB)
+	if exist $@.manifest \
+	  mt -nologo -manifest $@.manifest -outputresource:$@;1
+
+minigzip_d.exe: minigzip.obj $(IMPLIB)
+	$(LD) $(LDFLAGS) -out:$@ minigzip.obj $(IMPLIB)
+	if exist $@.manifest \
+	  mt -nologo -manifest $@.manifest -outputresource:$@;1
+
+{$(TOP)}.c.obj:
+	$(CC) -c $(WFLAGS) $(CFLAGS) $<
+
+{$(TOP)/test}.c.obj:
+	$(CC) -c -I$(TOP) $(WFLAGS) $(CFLAGS) $<
+
+{$(TOP)/contrib/masmx64}.c.obj:
+	$(CC) -c $(WFLAGS) $(CFLAGS) $<
+
+{$(TOP)/contrib/masmx64}.asm.obj:
+	$(AS) -c $(ASFLAGS) $<
+
+{$(TOP)/contrib/masmx86}.asm.obj:
+	$(AS) -c $(ASFLAGS) $<
+
+adler32.obj: $(TOP)/adler32.c $(TOP)/ptlibzippy.h $(TOP)/ptzippyconf.h
+
+compress.obj: $(TOP)/compress.c $(TOP)/ptlibzippy.h $(TOP)/ptzippyconf.h
+
+crc32.obj: $(TOP)/crc32.c $(TOP)/ptlibzippy.h $(TOP)/ptzippyconf.h $(TOP)/crc32.h
+
+deflate.obj: $(TOP)/deflate.c $(TOP)/deflate.h $(TOP)/ptzippyutil.h $(TOP)/ptlibzippy.h $(TOP)/ptzippyconf.h
+
+gzclose.obj: $(TOP)/gzclose.c $(TOP)/ptlibzippy.h $(TOP)/ptzippyconf.h $(TOP)/ptzippyguts.h
+
+gzlib.obj: $(TOP)/gzlib.c $(TOP)/ptlibzippy.h $(TOP)/ptzippyconf.h $(TOP)/ptzippyguts.h
+
+gzread.obj: $(TOP)/gzread.c $(TOP)/ptlibzippy.h $(TOP)/ptzippyconf.h $(TOP)/ptzippyguts.h
+
+gzwrite.obj: $(TOP)/gzwrite.c $(TOP)/ptlibzippy.h $(TOP)/ptzippyconf.h $(TOP)/ptzippyguts.h
+
+infback.obj: $(TOP)/infback.c $(TOP)/ptzippyutil.h $(TOP)/ptlibzippy.h $(TOP)/ptzippyconf.h $(TOP)/inftrees.h $(TOP)/inflate.h \
+             $(TOP)/inffast.h $(TOP)/inffixed.h
+
+inffast.obj: $(TOP)/inffast.c $(TOP)/ptzippyutil.h $(TOP)/ptlibzippy.h $(TOP)/ptzippyconf.h $(TOP)/inftrees.h $(TOP)/inflate.h \
+             $(TOP)/inffast.h
+
+inflate.obj: $(TOP)/inflate.c $(TOP)/ptzippyutil.h $(TOP)/ptlibzippy.h $(TOP)/ptzippyconf.h $(TOP)/inftrees.h $(TOP)/inflate.h \
+             $(TOP)/inffast.h $(TOP)/inffixed.h
+
+inftrees.obj: $(TOP)/inftrees.c $(TOP)/ptzippyutil.h $(TOP)/ptlibzippy.h $(TOP)/ptzippyconf.h $(TOP)/inftrees.h
+
+trees.obj: $(TOP)/trees.c $(TOP)/ptzippyutil.h $(TOP)/ptlibzippy.h $(TOP)/ptzippyconf.h $(TOP)/deflate.h $(TOP)/trees.h
+
+uncompr.obj: $(TOP)/uncompr.c $(TOP)/ptlibzippy.h $(TOP)/ptzippyconf.h
+
+ptzippyutil.obj: $(TOP)/ptzippyutil.c $(TOP)/ptzippyutil.h $(TOP)/ptlibzippy.h $(TOP)/ptzippyconf.h
+
+gvmat64.obj: $(TOP)/contrib\masmx64\gvmat64.asm
+
+inffasx64.obj: $(TOP)/contrib\masmx64\inffasx64.asm
+
+inffas8664.obj: $(TOP)/contrib\masmx64\inffas8664.c $(TOP)/ptzippyutil.h $(TOP)/ptlibzippy.h $(TOP)/ptzippyconf.h \
+		$(TOP)/inftrees.h $(TOP)/inflate.h $(TOP)/inffast.h
+
+inffas32.obj: $(TOP)/contrib\masmx86\inffas32.asm
+
+match686.obj: $(TOP)/contrib\masmx86\match686.asm
+
+example.obj: $(TOP)/test/example.c $(TOP)/ptlibzippy.h $(TOP)/ptzippyconf.h
+
+minigzip.obj: $(TOP)/test/minigzip.c $(TOP)/ptlibzippy.h $(TOP)/ptzippyconf.h
+
+ptlibzippy1.res: $(TOP)/win32/ptlibzippy1.rc
+	$(RC) $(RCFLAGS) /fo$@ $(TOP)/win32/ptlibzippy1.rc
+
+# testing
+test: example.exe minigzip.exe
+	example
+	echo hello world | minigzip | minigzip -d
+
+testdll: example_d.exe minigzip_d.exe
+	example_d
+	echo hello world | minigzip_d | minigzip_d -d
+
+
+# cleanup
+clean:
+	-del $(STATICLIB)
+	-del $(SHAREDLIB)
+	-del $(IMPLIB)
+	-del *.obj
+	-del *.res
+	-del *.exp
+	-del *.exe
+	-del *.pdb
+	-del *.manifest
+	-del foo.gz
diff --git a/archived/ptlibzippy/win32/README-WIN32.txt b/archived/ptlibzippy/win32/README-WIN32.txt
new file mode 100644
index 0000000000..4d0144a34f
--- /dev/null
+++ b/archived/ptlibzippy/win32/README-WIN32.txt
@@ -0,0 +1,103 @@
+PTLIBZIPPY DATA COMPRESSION LIBRARY
+
+PTlibzippy 0.0.5.1 is a general purpose data compression library.  All the code is
+thread safe.  The data format used by the PTlibzippy library is described by RFCs
+(Request for Comments) 1950 to 1952 in the files
+https://datatracker.ietf.org/doc/html/rfc1951 (PTlibzippy format), rfc1951.txt
+(deflate format), and rfc1952.txt (gzip format).
+
+All functions of the compression library are documented in the file ptlibzippy.h
+(volunteer to write man pages welcome, contact ptlibzippy@gzip.org).  Two compiled
+examples are distributed in this package, example and minigzip.  The example_d
+and minigzip_d flavors validate that the ptlibzippy1.dll file is working correctly.
+
+Questions about PTlibzippy should be sent to <ptlibzippy@gzip.org>.  The PTlibzippy home page
+is http://projecttick.org/p/zlib/ .  Before reporting a problem, please check this site to
+verify that you have the latest version of PTlibzippy; otherwise get the latest
+version and check whether the problem still exists or not.
+
+PLEASE read DLL_FAQ.txt, and the PTlibzippy FAQ http://projecttick.org/p/zlib/ptlibzippy_faq.html before
+asking for help.
+
+
+Manifest:
+
+The package ptlibzippy-0.0.5.1-win32-x86.zip will contain the following files:
+
+  README-WIN32.txt This document
+  ChangeLog        Changes since previous PTlibzippy packages
+  DLL_FAQ.txt      Frequently asked questions about ptlibzippy1.dll
+  ptlibzippy.3.pdf       Documentation of this library in Adobe Acrobat format
+
+  example.exe      A statically-bound example (using PTlibzippy.lib, not the dll)
+  example.pdb      Symbolic information for debugging example.exe
+
+  example_d.exe    A ptlibzippy1.dll bound example (using zdll.lib)
+  example_d.pdb    Symbolic information for debugging example_d.exe
+
+  minigzip.exe     A statically-bound test program (using PTlibzippy.lib, not the dll)
+  minigzip.pdb     Symbolic information for debugging minigzip.exe
+
+  minigzip_d.exe   A ptlibzippy1.dll bound test program (using zdll.lib)
+  minigzip_d.pdb   Symbolic information for debugging minigzip_d.exe
+
+  ptlibzippy.h           Install these files into the compilers' INCLUDE path to
+  ptzippyconf.h          compile programs which use ptlibzippy.lib or zdll.lib
+
+  zdll.lib         Install these files into the compilers' LIB path if linking
+  zdll.exp         a compiled program to the ptlibzippy1.dll binary
+
+  ptlibzippy.lib         Install these files into the compilers' LIB path to link PTlibzippy
+  ptlibzippy.pdb         into compiled programs, without ptlibzippy1.dll runtime dependency
+                   (ptlibzippy.pdb provides debugging info to the compile time linker)
+
+  ptlibzippy1.dll        Install this binary shared library into the system PATH, or
+                   the program's runtime directory (where the .exe resides)
+  ptlibzippy1.pdb        Install in the same directory as ptlibzippy1.dll, in order to debug
+                   an application crash using WinDbg or similar tools.
+
+All .pdb files above are entirely optional, but are very useful to a developer
+attempting to diagnose program misbehavior or a crash.  Many additional
+important files for developers can be found in the ptlibzippy.zip source package
+available from http://projecttick.org/p/zlib/ - review that package's README file for details.
+
+
+Acknowledgments:
+
+The deflate format used by PTlibzippy was defined by Phil Katz.  The deflate and
+PTlibzippy specifications were written by L.  Peter Deutsch.  Thanks to all the
+people who reported problems and suggested various improvements in PTlibzippy; they
+are too numerous to cite here.
+
+
+Copyright notice:
+
+  (C) 1995-2026 Jean-loup Gailly and Mark Adler
+
+  This software is provided 'as-is', without any express or implied
+  warranty.  In no event will the authors be held liable for any damages
+  arising from the use of this software.
+
+  Permission is granted to anyone to use this software for any purpose,
+  including commercial applications, and to alter it and redistribute it
+  freely, subject to the following restrictions:
+
+  1. The origin of this software must not be misrepresented; you must not
+     claim that you wrote the original software. If you use this software
+     in a product, an acknowledgment in the product documentation would be
+     appreciated but is not required.
+  2. Altered source versions must be plainly marked as such, and must not be
+     misrepresented as being the original software.
+  3. This notice may not be removed or altered from any source distribution.
+
+  Jean-loup Gailly        Mark Adler
+  jloup@gzip.org          madler@alumni.caltech.edu
+
+If you use the PTlibzippy library in a product, we would appreciate *not* receiving
+lengthy legal documents to sign.  The sources are provided for free but without
+warranty of any kind.  The library has been entirely written by Jean-loup
+Gailly and Mark Adler; it does not include third-party code.
+
+If you redistribute modified sources, we would appreciate that you include in
+the file ChangeLog history information documenting your changes.  Please read
+the FAQ for more information on the distribution of modified source versions.
diff --git a/archived/ptlibzippy/win32/VisualC.txt b/archived/ptlibzippy/win32/VisualC.txt
new file mode 100644
index 0000000000..3c8deeaafa
--- /dev/null
+++ b/archived/ptlibzippy/win32/VisualC.txt
@@ -0,0 +1,3 @@
+
+To build PTlibzippy using the Microsoft Visual C++ environment,
+use the appropriate project from the contrib/vstudio/ directory.
diff --git a/archived/ptlibzippy/win32/zlib.def b/archived/ptlibzippy/win32/zlib.def
new file mode 100644
index 0000000000..0fc67248a8
--- /dev/null
+++ b/archived/ptlibzippy/win32/zlib.def
@@ -0,0 +1,104 @@
+; PTlibzippy data compression library
+EXPORTS
+; basic functions
+    ptlibzippyVersion
+    deflate
+    deflateEnd
+    inflate
+    inflateEnd
+; advanced functions
+    deflateSetDictionary
+    deflateGetDictionary
+    deflateCopy
+    deflateReset
+    deflateParams
+    deflateTune
+    deflateBound
+    deflateBound_z
+    deflatePending
+    deflateUsed
+    deflatePrime
+    deflateSetHeader
+    inflateSetDictionary
+    inflateGetDictionary
+    inflateSync
+    inflateCopy
+    inflateReset
+    inflateReset2
+    inflatePrime
+    inflateMark
+    inflateGetHeader
+    inflateBack
+    inflateBackEnd
+    ptlibzippyCompileFlags
+; utility functions
+    compress
+    compress2
+    compress_z
+    compress2_z
+    compressBound
+    compressBound_z
+    uncompress
+    uncompress2
+    uncompress_z
+    uncompress2_z
+    gzopen
+    gzdopen
+    gzbuffer
+    gzsetparams
+    gzread
+    gzfread
+    gzwrite
+    gzfwrite
+    gzprintf
+    gzvprintf
+    gzputs
+    gzgets
+    gzputc
+    gzgetc
+    gzungetc
+    gzflush
+    gzseek
+    gzrewind
+    gztell
+    gzoffset
+    gzeof
+    gzdirect
+    gzclose
+    gzclose_r
+    gzclose_w
+    gzerror
+    gzclearerr
+; large file functions
+    gzopen64
+    gzseek64
+    gztell64
+    gzoffset64
+    adler32_combine64
+    crc32_combine64
+    crc32_combine_gen64
+; checksum functions
+    adler32
+    adler32_z
+    crc32
+    crc32_z
+    adler32_combine
+    crc32_combine
+    crc32_combine_gen
+    crc32_combine_op
+; various hacks, don't look :)
+    deflateInit_
+    deflateInit2_
+    inflateInit_
+    inflateInit2_
+    inflateBackInit_
+    gzgetc_
+    ptError
+    inflateSyncPoint
+    get_crc_table
+    inflateUndermine
+    inflateValidate
+    inflateCodesUsed
+    inflateResetKeep
+    deflateResetKeep
+    gzopen_w
diff --git a/archived/ptlibzippy/win32/zlib1.rc b/archived/ptlibzippy/win32/zlib1.rc
new file mode 100644
index 0000000000..1610f30769
--- /dev/null
+++ b/archived/ptlibzippy/win32/zlib1.rc
@@ -0,0 +1,37 @@
+#include <winver.h>
+#include "../ptlibzippy.h"
+
+VS_VERSION_INFO		VERSIONINFO
+
+  FILEVERSION		PTLIBZIPPY_VER_MAJOR,PTLIBZIPPY_VER_MINOR,PTLIBZIPPY_VER_REVISION,0
+  PRODUCTVERSION	PTLIBZIPPY_VER_MAJOR,PTLIBZIPPY_VER_MINOR,PTLIBZIPPY_VER_REVISION,0
+  FILEFLAGSMASK		VS_FFI_FILEFLAGSMASK
+#ifdef _DEBUG
+  FILEFLAGS		1
+#else
+  FILEFLAGS		0
+#endif
+  FILEOS		VOS__WINDOWS32
+  FILETYPE		VFT_DLL
+  FILESUBTYPE		0	// not used
+BEGIN
+  BLOCK "StringFileInfo"
+  BEGIN
+    BLOCK "040904E4"
+    //language ID = U.S. English, char set = Windows, Multilingual
+    BEGIN
+      VALUE "FileDescription",	"PTlibzippy data compression library\0"
+      VALUE "FileVersion",	PTLIBZIPPY_VERSION "\0"
+      VALUE "InternalName",	"ptlibzippy1.dll\0"
+      VALUE "LegalCopyright",	"(C) 1995-2026 Jean-loup Gailly & Mark Adler\0"
+      VALUE "OriginalFilename",	"ptlibzippy1.dll\0"
+      VALUE "ProductName",	"PTlibzippy\0"
+      VALUE "ProductVersion",	PTLIBZIPPY_VERSION "\0"
+      VALUE "Comments",		"For more information visit http://projecttick.org/p/zlib/\0"
+    END
+  END
+  BLOCK "VarFileInfo"
+  BEGIN
+    VALUE "Translation", 0x0409, 1252
+  END
+END