view release on metacpan or  search on metacpan

unzip-6.0/proginfo/ZipPorts  view on Meta::CPAN

      changes into the existing code (e.g., unzpriv.h).  If it's close enough
      to an existing port that piggybacking is a temptation, define a new
      "combination macro" (e.g., "CMS_MVS") and replace the old macros as
      required.  (This last applies to UnZip, at least; the old preference
      in Zip was fewer macros and long #ifdef lines, so talk to Onno or Jean-
      loup about that.)  See also rule 0.1.

      (Note that, for UnZip, new ports need not attempt to deal with all
      features.  Among other things, the wildcard-zipfile code in do_wild()
      may be replaced with a supplied dummy version, since opendir/readdir/
      closedir() or the equivalent can be difficult to implement.)


  (1) NO FEELTHY TABS

      Some editors and e-mail systems either have no capability to use
      and/or display tab characters (ASCII 9) correctly, or they use non-
      standard or variable-width tab columns, or other horrors.  Some edi-
      tors auto-convert spaces to tabs, after which the blind use of "diff
      -c" results in a huge and mostly useless patch.  Yes, *we* know about
      diff's "-b" option, but not everyone does.  And yes, we also know this
      makes the source files bigger, even after compression; so be it.  If
      we *really* cared that much about the size of the sources, we'd still
      be writing Unix-only utilities.

      Bottom line:  use spaces, not tabs.

      Exception:  some of the makefiles (the Unix one in particular) require
      tabs as part of the syntax.

      Related utility programs:
          Unix, OS/2 and MS-DOS:  expand, unexpand.
          MS-DOS:  Buerg's TABS; Toad Hall's TOADSOFT.
          And some editors have the conversion built-in.


  (2) NO FEELTHY CARRIAGE RETURNS

      All source, documentation and other text files shall have Unix style
      line endings (LF only, a.k.a. ctrl-J), not the DOS/OS2/NT CR+LF or Mac
      CR-only line endings.

      Reason:  "real programmers" in any environment can convert back and
      forth between Unix and DOS/Mac style.  All PC compilers but a few old
      Borland versions can use either Unix or MS-DOS end-of-lines.  Buerg's
      LIST (file-display utility) for MS-DOS can use Unix or MS-DOS EOLs.
      Both Zip and UnZip can convert line-endings as appropriate.  But Unix
      utilities like diff and patch die a horrible death (or produce horrible
      output) if the target files have CRs.

      Related utilities:  flip for Unix, OS/2 and MS-DOS; Unix "tr".

      Exceptions:  documentation in pre-compiled binary distributions should
      be in the local (target) format.


  (3) NO FEELTHY 8-BIT CHARS

      Do all your editing in a plain-text ASCII editor.  No WordPerfect, MS
      Word, WordStar document mode, or other word processor files, thenkyew.
      No desktop publishing.  *Especially* no EBCDIC.  No TIFFs, no GIFs, no
      embedded pictures or dancing ladies (too bad, Cave Newt).  [Sigh... -CN]

      Reason:  compatibility with different consoles.  My old XT clone is
      the most limited!

      Exceptions:  some Macintosh makefiles apparently require some 8-bit
      characters; the Human68k port uses 8-bit characters for Kanji or Kana
      comments (I think); etc.

      Related utilities:  vi, emacs, EDLIN, Turbo C editor, other programmers'
      editors, various word processor -> text conversion utilities.


  (4) NO FEELTHY LEFT-JUSTIFIED DASHES

      Always precede repeated dashes (------) with one or more leading non-
      dash characters:  spaces, tabs, pound signs (#), comments (/*), what-
      ever.

      Reason:  sooner or later your source file will be e-mailed through an
      undigestifier utility, most of which treat leading dashes as end-of-
      message separators.  We'd rather not have your code broken up into a
      dozen separate untitled messages, thank you.


  (5) NO FEELTHY FANCY_FILENAMES

      Assume the worst:  that someone on a brain-damaged DOS system has to
      work with everything your magic fingers produced.  Keep the filenames
      unimaginative and within MS-DOS limits (i.e., ordinary A..Z, 1..9,
      "-$_!"-type characters, in the 8.3 "filename.ext" format).  Mac and
      Unix users, giggle all you want, but no spaces or multiple dots.

      Reason:  compatibility with different file systems.  MS-DOS FAT is the
      most limited, with the exception of CompuServe (6.3, argh).

      Exceptions:  slightly longer names are occasionally acceptable within
      OS-specific subdirectories, but don't do that unless there's a good
      reason for it.


  (6) NO FEELTHY NON-ZIPFILES AND NO FEELTHY E-MAIL BETAS

      Beta testers and developers are in general expected to have both
      ftp capability and the ability to deal with zipfiles.  Those without
      should either find a friend who does or else learn about ftp-mailers.

      Reason:  the core development team barely has time to work on the
      code, much less prepare oddball formats and/or mail betas out (and
      the situation is getting worse, sigh).

      Exceptions:  anyone seriously proposing to do a new port will be
      given special treatment, particularly with respect to UnZip; we
      obviously realize that bootstrapping a completely new port can be
      quite difficult and have no desire to make it even harder due to
      lack of access to the latest code (rule 0.2).

      Public releases of UnZip, on the other hand, will be available in
      two formats:  .tar.Z (16-bit compress'd tar) and .zip (either "plain"
      or self-extracting).  Zip sources and executables will generally only