OS/2 Shareware BBS: 9 Archive/09-Archive.zip/UnzpHist.zip/History.398

Text File | 1990-10-22 | 12KB | 248 lines

Well, David made the mistake of letting me put together the 3.98 beta
release--sooner or later he's going to learn not to do that--so here's
my summary of what went into it.  In brief [OK, so it's not so brief...
I DID try, however.  It's just the sign of a guilty conscience when I
start trying to justify everything...]:

  - the Classic Antoine Patches (MTS version of set_file...close(),
    unsigned CRCs, unsigned makelong function new ULONG typedef,
    character-set-independent signature bytes, fixes to the EBCDIC
    stuff I broke, rearranged ebcdic[] table).  (Btw, "Antoine" refers
    to Antoine Verheijen, [e-mail])
  - the New Antoine Patch (rewrite of a_to_e()).
  - incorporation of globals.h into unzip.h, per Antoine's lead and
    Larry Jones's comment.  Also, updates of all the makefiles to
    reflect the absence of globals.h.
  - a new VMS return-code interpreter thing, so all those hard-won
    return codes don't go completely to waste under VMS.  This is
    tucked away in misc.c along with the other oddities and nonsense.
  - addition of the MIPS system to the makefile (with just a warning
    about that weird missing header file, until other MIPS users pipe
    up and say yea or nay).  From Peter Jones, [e-mail]
    (the boys north of the border have been busy this week...must be
    wearing their thinking-tuques, eh?  Beauty.)

That's the stuff most everybody already knew about.  The more alert
units amongst you might have caught a fleeting reference to some other
changes in one of my recent messages:

  - all (former) longints in the header structs are now ULONGs, not
    just the CRCs; this follows from Phil Katz's definition of the
    header fields.  Accordingly, the LONGI and LONGIP macros are now
    called ULONG_ and ULONGP; portions of the code which actually
    wanted a signed long now have explicit typecasts.  The total num-
    ber of casts is about the same, but this way there are no silent
    conversions (some of which came from the makelong() modification).
  - as a result of my somewhat more-thorough-than-usual testing of all
    this, I finally tracked down a bug stemming from the shared storage
    areas used by unShrink/unReduce/unImplode.  On most machines the
    main work area used by unReduce and unShrink is about the same size;
    but on machines with long integers the unShrink area is much larger
    (unShrink uses ints whereas unReduce uses chars).  Unfortunately, it
    was the unReduce area which was used to allocate the storage, with
    predictable results when unShrink tried to initialize it.  Well,
    actually, they weren't all *that* predictable since the machine was
    busily multitasking, too...a minor detail which I forgot about.  Any-
    way, now the unShrink variables define the size of the storage area
    (since they're always the biggest) and unReduce and unImplode use
    pointers into that area.
  - some added notes in the VMSNOTES file.

And then there were the related and unrelated changes which I didn't bother
to announce:

  - a bunch of unReduce variables which somehow became globals have been
    moved back into unreduce.c.
  - a bunch of (n)unzip.c variables which also became globals have been
    declared static and removed from the extern list in unzip.h.  The re-
    mainder of what used to be globals.h should now truly be just globals:
    each variable appears in more than one file.
  - some unused typedefs removed from unimplod.c and unzip.h.
  - the MSC6 errno fix has been modified so that no explicit definition
    of "MSC6" is necessary; it turns out that there IS a way to distin-
    guish between the different compiler versions.  Thanks to Wim Bonner,
    former Microsoft dude extraordinaire ([e-mail]),
    for discovering this one.
  - a minor tweak to UpdateCRC (not to worry, I've tested this one rather
    carefully).
  - fixed a very sneaky and rather nasty bug in the list_files() function.
    This one only showed up if you had individual member comments and were
    listing only some of the members (at least one of the files with a com-
    ment had to be excluded from the listing).  Thank goodness for heavy
    metal, the most effective bug-killing substance known to man...
  - trimmed down a few of my more long-winded comments; changed most of
    the internal "nunzip" references to "unzip" (the filenames and make-
    files are still unchanged, though, and the usage screen still says
    nunzip); deleted or moved some of the more bogus version histories from
    the source files to the history file (that is, this file--David may
    decide to move the rest in here); and generally did meddlesome things
    wherever the urge struck.  [The revision-history changes were made
    after discussion with David; those things just get bigger and bigger,
    and so do the source files.]
  - revised the MSC makefile so that (maybe) it'll work with Turbo's
    version of make, and replaced some missing tabs in the real Makefile,
    just in case.

That's all I can remember.  I did NOT put the user-query into scan_back()
yet (for the case where the PK signature isn't found right away), pending
further discussion and/or some other tweaks to that function.  I also
left the A_TO_E() macro to Antoine's discretion (the Diet Antoine Patch?)
(no, wait, that one should have to do with Tabs...).



OK, you can stop groaning now.

The new executables are generally a bit smaller than the old ones were,
except under VMS (new function in there).  I think that's because the
unShrink storage was slightly over-generous before (except on Crays).
Now that I think about it, it would be better to malloc() that storage
instead of defining it statically...but this version is ready to go, so
that'll have to wait for 3.99.

The remainder of this file contains the comments which accompanied the
other patches/suggestions.

Greg

-----------------

**** Antoine Patch #1 Comments:

This patch corrects a number of minor problems with the EBCDIC support in
nunzip. In particular:

   1) The definitions for the various headers in unzip.h use the characters
      'P' and 'K' rather than their ASCII code equivalents. This means that
      an EBCDIC system will never recognize a header.

   2) When scanning for the end of the central directory at the start, the
      untranslated input character is compared against the character 'P'
      rather than its ASCII code. Thus, the check fails on an EBCDIC system.

   3) Output characters are never actually converted to EBCDIC, even if the
      -a flag is specified.

   4) The output file on extraction is always opened in binary mode. This
      doesn't really make much sense if translation is being done.

   5) The EBCDIC table in misc.c has the "static" attribute attached to it
      which prevents the linker (on some systems) from seeing it so that
      other modules which require it result in an unresolved symbol.

Thie patch also slightly re-organizes the EBCDIC table to make it a bit more
readable in a listing and provides a slightly better description of the
actual translation performed.

-----------------

**** Antoine Patch #2 Comments:

CRC values in .zip files are unsigned 32-bit quantities. Nunzip (and its
predecessor unzip) declare them in their headers as signed 32-bit (long)
values. On systems such as Vax UNIX, this is not a problem because all
arithmetic (including shift operations) on signed and unsigned integer
values are done the same way. For example, logical shifts are used for both
signed and unsigned values.

Some systems, such as MTS for example, treat unsigned and signed values
differently. For example, logical shifts are used for unsigned values
whereas arithmetic shifts are used for signed values. The big difference
between the two, or course, is that the high-order bit is thrown away when
shifting a full 32-bit signed value left on such a system. As a result,
CRC checks fail on these systems when the high-order bit is supposed to be
on.

This patch changes the declaration for the CRC fields in the header
structures so that they are unsigned long values. It also changes the
makelong() routine so that is returns an unsigned value (ie. it always
retains the high order bit). This seems to make everything work properly
on both types of systems (as verified by the local MTS and Vax UNIX systems).

Note that the change is made by defining a new typedef of ULONG. This was
simply done to keep things a little more readable and to retain consistency
with UWORD (unsigned short).


-----------------

**** Antoine Patch #3 Comments:

This patch adds a definition for an MTS-specific set_file_time_and_close()
routine to file_io.c. Like the current VMS one, it only closes the file since
there is no way to set file times in MTS and there likely never will be.

-----------------

**** Antoine Patch #4 Comments:

This patch replaces the a_to_e() routine (which converts a string from
ASCII to EBCDIC) with a version that is smaller both in source and binary
form, and which runs about 40% faster (partly since it makes only one pass
over the string rather than two).

Admittedly this is a rather petty change as it does not change the
functionality of nunzip in any way, but I could see no reason not to make
it more efficient since it's not a major change. If anyone feels that such
changes should not be made, please let me know as I'm still fairly new to
this project and am not completely sure of what constitutes acceptable
change. Obviously, change for the sake of change is idiotic but are minor
changes of this sort appreciated or not? My own personal approach is always
to speed things up whatever way I can but such views are not always
universally held. Thanks.

This patch, of course, only affects EBCDIC systems.

Antoine Verheijen, University of Alberta

-----------------

**** Wim Bonner Comments:

This was in the nunzip97 MAKEFILE.MSC file:

#          (4) If used with MSC 6.0, add "-DMSC6" to the CFLAGS line.  This
#              is necessary because 6.0's errno.h declares the errno variable
#              to be some oddball type; 5.0's errno.h doesn't declare errno
#              at all; and there seems to be no way to determine which com-
#              piler is being used to compile the code.  May Bill Gates trip
#              over his own nose hairs...
#  Greg Roelofs
#  [e-mail]
#  25 September 1990

I may be totally off base here, but at least with version 6 of MSC,
there is a predefined constant listed as "_MSC_VER" which will return
the number 600.  I Found it when I was looking up some constants in the
quickhelp utility.  Unfortunately, I have never managed to find a list
of all predefined constants or what they represent in the MSC Packages,
even when I worked there in product support.

Does anyone know if this works in MSC 5.xx?  (Mine is no longer installed)
The following code demonstrates it...
#include <stdio.h>
void main()
{
printf("%d",_MSC_VER);
}

========================================================================
       Wim Bonner - [e-mail] - V(509)335-8990
                    Have you seen my friend the puca?
========================================================================


-----------------

**** nunzip.c Major-Version History:

     1.2:   original Samuel H. Smith version; spring 1989(?)
     2.0a:  first(?) port to Unix; C. Mascott; Nov 1989(?)
     3.0:   first Info-ZIP release(?); D. Kirschbaum, coordinator; May 1990
     3.1:   second Info-ZIP release; Aug 1990
     4.0:   central directory rewrite; Sept-Oct 1990


(The only file_io.c revision entry which wasn't mine--the OS/2 one--I
stuck in a comment down by the actual OS/2 code.)