campo-sirio/zip/zip/vms/00readme.txt

*****************************************
************ vms/00readme.txt ***********
*****************************************

Additional information for compiling Zip for VMS:

A) Support for storing VMS specific file attributes
   ================================================

The current version of Zip comes with two different types of support
to store VMS file attributes in extra blocks:

  -- the traditional Info-ZIP format in vms/vms_im.c
and

  -- a new PKware (ASI) type extra field structure in vms/vms_pk.c

Both versions should supply exactly the same functionality.
The default configuration is to use the traditional IM style, since it is
well tested and known to be stable.

IMPORTANT: To extract new PK style extra fields, Info-ZIP's
           UnZip version 5.2 or newer is required, previous
           versions will crash with an access violation !!!!
           For this reason, it is strongly discouraged to use
           PK (ASI) style extra fields for distributing VMS Zip
           archives.

If you want to try the new new PK style support (to archive compatibility
with the commercial VMS Zip from PKware), the preprocessor symbol
VMS_PK_EXTRA has to be defined at compile time.

MMS (MMK) users have to edit vms/descrip.mms and add this symbol to
the definition of the COMMON_DEFS macro; for example:

COMMON_DEFS = VMS_PK_EXTRA,

if VMS_PK_EXTRA is the only option. (NOTE the trailing comma!)

Users of the DCL make procedure can select the PK style support by defining
the DCL symbol LOCAL_ZIP as a list of user specific compilation options
(do not forget the trailing comma!!). Example:
$ LOCAL_ZIP == "VMS_PK_EXTRA,"


B) Notes on the compiler switches used on VMS:
   ===========================================

The source has been successfully compiled on VMS 6.1, using
 - DECC 5.0 for Alpha AXP
 - DECC 4.0 for VMS VAX
 - VAXC 3.2

1. Discussion of the /STANDARD switch:

With the exception of some few rough spots in the VMS specific sources,
the code is fully compatible with the "RELAXED_ANSI" mode of the DECC
compilers. The problems found in vmsmunch.c and vms_pk.c are caused
by incompatibles between the system include headers supplied for DECC
(AXP) and DECC (VAX) which cannot get worked around. (Some system
service structure members have type "unsigned int"  in the VAX version,
but "pointer to [miscellanous]" in the AXP headers.)
I consider the AXP headers to show the direction of `future developement'
and have adapted the sources to match the AXP's header files.
This means:
On Alpha AXP, we can equally well use "/STANDARD=RELAXED" instead of
"/STANDARD=VAXC" without getting any warnings.
With the current release of DECC on VAX, the /STANDARD=VAXC switch is
required to suppress the "assignment to incompatible type" warnings.
For the Zip 2.1 release, the compiler mode for Alpha AXP has been changed
to "/STANDARD=RELAX", since the "ANSI mode" executables are slightly smaller.

2. The /PREFIX_LIBRARY_ENTRIES switch:

In (strict and relaxed) ANSI mode on Alpha AXP, only the standard ANSI
RTL function names get prefixed with "DECC$" by the compiler per default.
This results in unresolved references to such functions as "read()", "open()"
"lseek()" at link step. (The same might be true for earlier releases of DECC
on VAX.) To resolve this problem, one has to explicitely request prefixing
of all DECC RTL function by applying the "/PREFIX=ALL" switch.
Although this switch is not needed in "VAXC" mode, it does not hurt either.
Therefore, "/PREFIX=ALL" is applied regardless of the compilation mode,
to avoid any problems when switching over to ANSI standard mode in the future.

C) Support for UX extra field UTC time stamps
   ==========================================
Beginning with Zip 2.1 and UnZip 5.2, the Info-Zip compression utilities
do principally support saving and restoring the modification time of
Zipfile entries as UTC (GMT) universal time. This new information is
stored in an "extra field" labeled "UX" (Unix style GMT modification/access
times, ...).
Previous version of Zip and UnZip used local time, stored in MSDOS compatible
format (as specified by PKware for the Zip file format). This practice caused
a lot of "time synchronization" trouble when transporting Zip archives world
wide between largely different time zones.

Unfortunately, VMS (and the VMS C runtime environment) up to VMS 6.x does not
contain support for timezone handling and assumes "local time == UTC time".
This has changed with the release of VMS 7.0, which does (finally) support
the concept of "universal world time" that is required time synchronization
in intercontinental networks...

For this reason, the UTC time stamp support is disabled in VMS Zip by default,
otherwise users would experience annoying time stamp deviations when
locally transfering Zip archives between VMS nodes and other (UNIX, OS/2,
WinNT/Win95, MSDOS) systems.
But when compiled on a VMS 7.x system, the UTC "UX extra field" support is
automatically enabled.

For users located in the GMT time zone (or a nearby timezone, like CET),
it might be worthwhile to enable UTC support by hand.

The default configuration can be overridden by defining one of the
following preprocessor macro:

  USE_EF_UX_TIME        includes "UX" time stamp support
  NO_EF_UX_TIME         disables "UX" time stamp support

When using MMS/MMK, you should add the appropiate symbol to the "COMMON_DEFS"
list in vms/descrip.mms; if the command procedure is used for compiling,
you can add the macro to the "LOCAL_ZIP" DCL symbol.

04-MAR-1996 Christian Spieler