http://invisible-island.net/
Copyright © 1996-2014,2021 by Thomas E. Dickey


Synopsis

Tin is a full-screen easy to use Netnews reader. It can read news locally (i.e., /usr/spool/news) or remotely (rtin or tin -r option) via a NNTP (Network News Transport Protocol) server. It will automatically utilize nov (news overview) style index files if available locally or via the nntp xover command.

The build-scripts auto-configure tin to a wide variety of UNIX and Posix platforms. Numerous enhancements have been made.

To build tin, you require an ANSI C compiler. ncurses is helpful but not essential.

Background

Initially tin denoted “Tass & Iain's Newsreader” as mentioned in the FAQ included in the source files through version 1.15 (August 1992). However, the FAQ was dropped in subsequent versions, and “tin” ceased to have an official meaning. Some say that it means “threaded internet newsreader” but that also has no official basis.

Most of my involvement has been with the successor to Iain Lea's version (originally referred to as tin-unoff, i.e., “unofficial”).

History

I contributed some portability and bug-fixes to the original (Iain Lea's version) tin. Shortly before he went offline, I was preparing a patch for auto-configuration. Managing the numerous configurations for which tin can be built is one of the two most interesting problems, from my point of view. The other (converting from the low-level screen I/O to a curses-based implementation) is something that everyone wishes someone else would do.

I completed a workable auto-configuration implementation for the successor tin-unoff, a project which is run by Urs Janßsen. More than twenty-five years later, the autoconf script is still in development, since I periodically update it from my collection of macros (my-autoconf).

My Involvement

I have done other work on tin. Refer to the older changelogs and Urs' history outline for context.

Introducing diffstat

While I was at the Software Productivity Consortium, someone in the computer services group downloaded source for several programs, and made them available to the whole organization. One of those programs was tin.

Tin stores the user's record of subscribed and unsubscribed news groups in $HOME/.newsrc, and indicates which article numbers the user has read by their number. Here is an example with three lines (the second may wrap):

gmane.linux.debian.devel.security! 1-57
linux.debian.security: 1-17875,17999-18000,18002,18026,18028-18031,18037,18039,18042,18153,18252,18310,18312,18484,18516,18605
linux.debian.announce.security: 1-1798

The lines can get very long if there are gaps in the sequence of articles. In that example, the second line is 126 characters. My .newsrc file contains a line with 28850 characters.

Newsgroups in 1992 did not have as many articles, but I found that tin would crash if the lines were long enough. I asked the person who had compiled it for the source so that I could provide a fix. After they refused my request, I downloaded it myself and made a fix. I mailed that to Iain Lea. To make the changes easier to understand, I created diffstat and used it to show a summary of the extent of the change.

The email and reply are long gone, but as I recall it, Iain replied that the problem had been fixed in a different way. Judging by the dates in tin.org's snapshots, as well as my comment in diffstat's source citing its creation date, I did this a week or two before tin 1.10 was released in mid-February 1992.

Later, I sent a fix for building tin on an Apollo workstation, which was listed in the changes for tin 1.21 (July 1993):

31) Tom Dickey (dickey@software.org)
    BUG. Would not compile on Apollo machines.
    FIX. config.h - applied supplied patch.

My build-fix was not the first Apollo change. I used an Apollo workstation at the Software Productivity Consortium (a DN3000), but Apollos are first mentioned in tin's source in tin 1.14 (June 1992) when Iain noted in the list of platforms that he had compiled and run it on a DN4500.

Auto-configuring

Initially, tin was built using a makefile that had targets for System V and BSD, along with special targets for platforms which differed from the common distributions. This is a part of the makefile from version 1.10 (February 17, 1992):

all
        @echo "There is no default. Specify one of the following targets."
        @echo "    make bsd       (BSD/Dec/Next/Sun)"
        @echo "    make sysv      (SysV)"
        @echo "    make sysvr4    (SysV R4)"
        @echo "    make sco       (SCO Unix)"
        @echo "    make aix       (IBM AIX)"
        @echo "    make xenix     (Xenix 386)"
        @echo "    make sinix     (SNI SysV)"
        @echo "    make tower     (NCR Tower)"
        @echo "    make minix     (Minix 386)"
        @echo "    make dgux      (DG Aviion)"
 
# For Berkeley systems:
#                        NNTPLIB=clientlib.o \
#
bsd:
        @echo "Compiling for BSD/Ultrix..."
        @$(MAKE) CFLAGS='-c -O -DBSD -DLIBDIR=\"/usr/lib/news\" -DSPOOLDIR=\"/usr/spool/news\"' \
                         LIBS="-lcurses -ltermcap" \
                         EXE=tin linkit
 
# For System V:
#                        NNTPLIB=clientlib.o \
#                        NETLIBS="-lnet -lnsl_s" \
#
sysv:
        @echo "Compiling for System V..."
        @$(MAKE) CFLAGS='-c -O -DAUTO_RESIZE -DLIBDIR=\"/usr/lib/news\" -DSPOOLDIR=\"/usr/spool/news\"' \
                         LIBS="-lcurses -ltermcap" \
                         EXE=tin linkit
 

Iain's INSTALL file listed platforms on which tin had been successfully built:

Compiled & installed on the following machines
----------------------------------------------

1) * Dec 5000/Vax & Ultrix 4.1/4.2
2) * Vax 11/785 & BSD 4.3
3) * 386 PC & Xenix 2.3/ATT SysVr4.0/SCO SysVR3.2/ISC SysVR3.2
3) * Sun 3/4/IPC/SS1/SS2 & SunOS 4.0.3/4.1/4.1.1
4) * Sony News & SysVR4/BSD 4.3
5) * SNI MX300/MX500 & Sinix 5.22/5.23/5.24
6)   ICL DRS6000 & SysVR4.0
7)   Atari STe & Minix 1.5.10.3b
8)   Apricot VX/FT & SCO 3.2.2
9)   DIAB DS90 & D-NIX 5.3
10)  Amdahl & SysVR3
11)  HP 9000/845 & HP-UX 7.0
12)  IBM RS/6000 & AIX 3.1.5
13)  NCR Tower & SysV
14)  Atari STe & Minix 1.5.10.3b
15)  386 PC & Minix 386
16)  DG Aviion & DG-UX

* = compiled, installed and used by author

The first public version of tin was 1.00, in August 1991. The subsequent patchs up to 1.10 (1.1 PL 0) were focused on making it more functional and robust. The patches from 1.1 (February 1992) through 1.2 (September 1993) aimed at making it more portable. Doing that for an increasing number of platforms required a more lengthy makefile to address the special cases:

Date Version INSTALL Makefile
Total *-Marked Targets Lines
1992/02/13 1.10 16 5 43 323
1992/03/03 1.12 19 7 50 382
1992/06/22 1.14 23 8 49 450
1992/08/11 1.15 29 8 52 482
1992/09/14 1.16 30 8 55 507
1992/11/15 1.17 30 8 57 529
1992/12/06 1.18 30 8 56 525
1993/03/20 1.19 30 8 56 524
1993/05/25 1.20 30 9 56 529
1993/07/14 1.21 31 3 56 656
1993/09/25 1.22 31 3 55 684

The drop from 9 to 3 platforms probably denotes a loss of access to the related machines, e.g., Apollo. However, with tin 1.2, there are additional makefiles for Amiga, Borland C (MS-DOS) and IBM Workframe/2 (OS/2).

Starting with tin 1.2, Iain was mailing from Siemens (no longer a university student). Almost two years passed before the next published update to tin. In between, there was email.

I gave feedback on several unpublished versions during 1994-1995. The email which I retained mentions betas 940606, 941010, 950211, 950611 and 950725.

Iain was the first to mention a configure script:

Date: Tue, 11 Oct 1994 09:06:40 +0000 (GMT)
From: Iain Lea <iain@anl433.erlm.siemens.de>
To: "T.E.Dickey" <dickey@clark.net>
Subject: Re: 941010 beta
X-Mailer: ELM [version 2.4 PL23]

Hi,

> It seems to work properly with no new bugs on Solaris.

Phew! thats a relief. I will be adding an autoconf script in the next couple
of betas. Would you be interested in trying it on Solaris. On linux it works
ok but ISC Unix does not like the shell script :( ?

> Will your next employer let you work on tin, or will that get pushed aside?

I will be staying at Siemens but am being loaned out for a year to SCN
(scn.de) Siemens Corparate Network to build up a firewall and add all the
new internet services. Sometimes life is hard :-)))))

The scn customers were only using nn but when I went for the interview I
had a copy of tin on a floppy and complied it for them. The next day all
the customers switched to tin. I must be doing something right!

--
iain.lea@erlm.siemens.de  +49-9131-7-43402
 'Raus aus dem Alltag, rein in die Kiste'
  

Later, I reminded him of this:

Date: Sun, 11 Jun 1995 12:02:26 -0400 (EDT)
To: Iain Lea <iain.lea@erlm.siemens.de>
Subject: tin vs autoconf
X-Mailer: ELM [version 2.4 PL24alpha3]

I was going through my old email the other day, and you'd said you were working
on an autoconf script (in december).  Did you abandon that effort, or what?
(I've done some of that, and would be willing to work on it).

--
Thomas E. Dickey
dickey@clark.net

Iain replied that I should send patches for this to him. In turn, I asked what had been done (to use as a basis), but got no response. I began a configure script anyway, and asked for advice:

Date: Sun, 16 Jul 1995 17:25:51 -0400 (EDT)
To: Iain Lea <iain.lea@erlm.siemens.de>
Subject: question
X-Mailer: ELM [version 2.4 PL24alpha3]

I'm about 40% through a configure script for tin, but haven't completed it
because I've been entangled in another program release just now.

I've got a question that you've probably encountered: to avoid conflict of
interest with my employer, I'm using pretty much the same copyright notice that
you've used for tin.  One of the people that I contributed an extension
complains that _that_ would prohibit (I'm not clear why) other people from
making collections (e.g., CDROM) with the software.

Since tin is on more than one CDROM, I'm asking for a few words on how you
answer that sort of question.

Thanks.

--
Thomas E. Dickey
dickey@clark.net

but got only an automated reply because Iain had gone on vacation.

The last mail from Iain was 1995/07/26 for 950726BETA, which had a build-fix for sunos from me:

Date: Wed, 26 Jul 1995 13:10:47 +0200 (MET DST)
From: Iain Lea <iain@scn.de>
To: ok <zahner@informatik.uni-erlangen.de>, alwin@proqnx.in-berlin.de, ok
        <bruceh@hpcvcdv.cv.hp.com>, ok <parry@yoyo.cc.monash.edu.au>, ok
        <luebke@erls02.siemens.de>, ok
        <rfflaxa@immd4.informatik.uni-erlangen.de>, ok
        <Helmut.Geyer@iwr.uni-heidelberg.de>, ok <mark@garden.equinox.gen.nz>,
        schwim@cyclone.stanford.edu, ok <dickey@clark.net>, ok
        <beaty@fc.hp.com>, hm@ix.de, afx@ibm.de, leisner@sdsp.mc.xerox.com,
        steve@cim.mcgill.ca, ok <mjshield@nyx.cs.du.edu>, ok
        <nigele@microsoft.com>, dcs@proton.chem.yale.edu
Subject: TIN beta 950726
X-Mailer: ELM [version 2.4 PL23]

Hi,

The latest beta is at  ftp://ftp.scn.de/pub/news/tin/tin-beta.tar.gz

--950726BETA released--

242) Martin Buck (martin.buck@student.uni-ulm.de)
    BUG. Failed to compile cleanly on HPUX 9.
    FIX. curses.c - applied supplied patch.

...

240) Andrew Greer (Andrew.Greer@vuw.ac.nz)
    ADD. Added ever more VAX/VMS support.
...

235) Tom Dickey (dickey@clark.net)
    BUG. K&R cc on sunos fails to compile due to ansi c usage
    FIX. pgp.c - changed void parameters for 2 functions.

234) Steve Beaty (beaty@fc.hp.com)
    BUG. Reading nntp from another port than 119 does not work
    FIX. nntplib.c - applied supplied patch.

--
Iain Lea                                       RK SCN D, Siemens AG., Germany
iain@scn.de             <http://www.scn.de/~iain>            +49 911 978 3120

The following spring, I noticed the “color-tin” (tin-unoff) project maintained by Urs Janßsen. I asked if Urs had gotten any response from Iain, and mentioned that I had worked on a configure script:

Date: Sat, 11 May 1996 12:18:30 -0400 (EDT)
To: urs@akk.uni-karlsruhe.de
Subject: color-tin
X-Mailer: ELM [version 2.4 PL24alpha3]

Are your getting any response from Iain, or has he dropped tin altogether?
(I was working on an autoconf script last summer, and he stopped responding).

--
Thomas E. Dickey
dickey@clark.net

Urs replied:

Date: Sat, 11 May 1996 18:54:07 +0200 (MET DST)
From: Urs Janßen <urs@akk.uni-karlsruhe.de>
To: "T.E.Dickey" <dickey@clark.net>
Subject: Re: color-tin

hi

> Are your getting any response from Iain, or has he dropped tin altogether?

till 8/24/95 i wrote about 100 e-mails to Iain and got ONE response (about 6
weeks ago: "I did not know that you added so much code to tin, I'll come up
with a new beta release this weekend") - ha ha - nothing.

> (I was working on an autoconf script last summer, and he stopped responding).

autoconf would be nice - do it!

urs
--
"The documentation is in Japanese.  Good luck." Rich $alz

Shortly after, I subscribed to the mailing list:

Here's the general information for the list you've
subscribed to, in case you don't already have it:

tin-unoff is a mailinglist for people talking about the unofficial
version of the usenet newsreader tin.  The official version of tin is
written bei Iain Lea <iain@scn.de> and can be found at
ftp://ftp.scn.de/pub/tin/.  The unofficial version we discuss here is
provided by Urs Janssen <urs@akk.uni-karlsruhe.de> and can be found at
ftp://ftp.akk.uni-karlsruhe.de/pub/tin/.

Be aware to find code diffs here!

My initial changes for the configure script were added at that time:

Date: Fri, 24 May 1996 20:45:09 +0200 (MET DST)
From: Urs Janßen <urs@akk.uni-karlsruhe.de>
To: "T.E.Dickey" <dickey@clark.net>
Subject: Re: tin+autoconf

> There's a cleaner version of my changes for tin+ autoconf in
>
>       ftp.clark.net:/pub/dickey/tin
>                       960522_a.patch.gz
>                       960522_a.tgz
>                       cfg-tin
>
> I sync'd with your 960522, and recompiled on the 10 platforms I've currently
> got available:

:) autoconf is in version 960524 :)

urs
--
"The documentation is in Japanese.  Good luck." Rich $alz

Revisiting Apollo

In October 1996, I worked with Nickolai Zeldovich to help him port tin to Apollo:

--unoff BETA release 961024 --

202) Thomas E. Dickey <dickey@clark.net>
     Nickolai Zeldovich <kolya@zepa.net>
     ADD. apollo porting (still in progress)
     ADD. core test for FreeBSD
     FIX. several supplied patches

--unoff BETA release 961012 --

184) Thomas E. Dickey <dickey@clark.net>
     Nickolai Zeldovich <kolya@zepa.net>
     ADD. apollo porting (still in progress)
     FIX. several supplied patches

Actually that was an updated port (it ran well enough for me in mid-1993).

The updated port used my configure script.

Table-generating

A few months before the Apollo port-update, another developer revised the way the configuration settings were managed:

--unoff BETA release 960815 --

151) Dirk Nimmich <nimmich@uni-muenster.de>
     ADD. rewrote options 'M'enu, add several configurable options
     ADD. getline() now allows to set maximum number of characters to type
          in.
     FIX. several supplied patches

I noticed that it used definitions which could be managed by a program.

Later in 1996, I replaced the header file with a table-generator, named makecfg. Like mktbls in vile, which I'd rewritten in version 3.31 (December 1992), this simplifies the way in which configuration options can be added to tin by generating source code (i.e., tables which represent different aspects of the configuration).

--unoff BETA release 961227 --

260) Thomas E. Dickey <dickey@clark.net>
     ADD. extends 'makecfg' to generate type-specific tables for string and
          char pointers, getting rid of the void* casts in tincfg.h
          modifies config.c and prompt.c accordingly.

--unoff BETA release 961109 --

211) Thomas E. Dickey <dickey@clark.net>
     ADD. replace include/conf.h with an automatically-generated table.
          (This fixes one of the two problems with the config.c rewrite: now
          the enum and table will track together -- the other, making it
          type-clean will be in a later patch -- when I have time).

Introducing the table-generator replaced

At first glance that might appear to be costly, but the table-file is much shorter, and more easily maintained.

In current (2021) code,

The generated code, however, is about a third longer than those files (1182 lines):

Debugging malloc calls

One of the changes which Iain incorporated into the 1.3 betas was a hack which I wrote for ded. I do not have the related email, nor do I see it clearly in the CHANGES file, but this ifdef with DOALLOC in tin.h is one of my changes:

#ifdef  DOALLOC
# if    __STDC__
#  define ANSI_VARARGS 1
#  include <stdarg.h>
# else
#  define ANSI_VARARGS 0
#  include <varargs.h>
#endif
extern  char    *doalloc  P_((char *, size_t));
extern  char    *docalloc P_((size_tsize_t));
extern  void    dofree    P_((char *));
# undef malloc
# undef realloc
# undef calloc
# undef free
# define malloc(n)  doalloc((char *)0, n)
# define realloc    doalloc
# define calloc     docalloc
# define free       dofree
 
extern  void    fail_alloc P_(( char *, char * ));
extern  void    Trace P_(( char *, ... ));
extern  void    Elapsed P_(( char * ));
extern  void    WalkBack P_(( void ));
extern  void    show_alloc P_(( void ));
extern  void    no_leaks P_(( void ));
extern  void    hist_reclaim P_(( void ));
#endif  /* DOALLOC */

I did this early in 1986, using a large array to keep track of malloc- and free-calls. The change is incomplete: only the hist_reclaim function is provided in Iain's sources; to use it required my library. That raises a few issues:

In 1997, we made provision for using a debugging malloc, dbmalloc:

--unoff BETA release 970108 --

275) Thomas E. Dickey <dickey@clark.net>
     ADD. code-cleanup (mainly lint and dbmalloc stuff)
     FIX. several supplied patches

--unoff BETA release 970106 --

273) Nickolay Saukh <nms@nns.ru>
     ADD. dbmalloc support
     FIX. tin.h

I had been using dbmalloc for a while (my change-log suggests late 1992). When I began developing with Linux, I made improvements to dbmalloc, and provided the improved version in my ftp area. Others found it useful (perhaps Nickolay used my version):

Later, Urs introduced me to valgrind, but dmalloc, dbmalloc and the ad hoc code which I adapted from ded were the starting point for our work to improve tin's internals.

Converting to standard C

Starting in January 1997, I began converting the program from K&R C to ANSI C.

While tin 1.0 had built with K&R C or ANSI C compilers, its source was more cluttered than necessary. Initially Iain had used cproto to generate the proto.h header, formatting it into sections for ANSI C versus K&R C (like the -b option added to cproto in patch 5, December 1992). But doing it that way meant that occasionally a declaration would be missed, or would have the wrong return type if Iain forgot to run cproto to update the proto.h file. While developing the 1.3 betas in 1995, Iain began using the -m option of cproto (patch 7, June 1993), which formats the two types of declarations into a single line using the P_ macro.

I removed that

--- proto.h     1997/01/25 00:47:56     1.54
+++ proto.h     1997/01/27 01:57:06     1.55
@@ -2,535 +2,535 @@
 #define PROTO_H 1
 
 /* active.c */
-extern int get_active_num P_((void));
-extern int resync_active_file P_((void));
-extern int parse_active_line P_((char *line, long *max, long *min, char *moderated));
-extern void read_news_active_file P_((void));
-extern void read_group_times_file P_((void));
-extern void write_group_times_file P_((void));
-extern void load_newnews_info P_((char *info));
-extern void read_motd_file P_((void));
-extern void vMakeActiveMyGroup P_((void));
+extern int get_active_num (void);
+extern int resync_active_file (void);
+extern int parse_active_line (char *line, long *max, long *min, char *moderated);
+extern void read_news_active_file (void);
+extern void read_group_times_file (void);
+extern void write_group_times_file (void);
+extern void load_newnews_info (char *info);
+extern void read_motd_file (void);
+extern void vMakeActiveMyGroup (void);
 
 /* actived.c */

and used unproto with the SunOS and HP-UX machines, or gcc for building tin thereafter. Just revising the way prototypes are generated is only a small part of ansification.

--unoff BETA release 970214 --

316) T.E.Dickey <dickey@clark.net>
     ADD. several 'const'
     BUG. tabs before preprocessor symbols (introduced in 312)
     FIX. several supplied patches

--unoff BETA release 970202 --

...

307) T.E.Dickey <dickey@clark.net>
     ADD. more fallback prototypes (e.g., atoi), from warnings I got
          running with gcc -traditional on Linux 2.0.0
     ADD. makes the gcc warnings autoconfigured
     ADD. makes strings 'const' (tested with gcc -Write-strings).
     FIX. several supplied patches

--unoff BETA release 970127 --

...

302) T.E.Dickey <dickey@clark.net>
     ADD. even mode K&R -> ANSI
     FIX. several supplied patches

Urs Janßsen and Jason Faultless also worked on the conversion, e.g.,

-- pre-1.4 release 971102 --

467) Urs Janssen <urs@tin.org>
     ADD. minor code cleanup; cosmetic patch
     FIX. several supplied patches

...

465) Jason Faultless <jason@radar.demon.co.uk>
     ADD. varargs *_message() functions
     BUG. 'm'ove group was broken
     ADD. minor code cleanup; cosmetic patch
     FIX. several supplied patches

--unoff BETA release 971018 --

454) Thomas E. Dickey <dickey@clark.net>
     ADD. rewrote prototype for OUTC_ARGS
     FIX. aclocal.m4, tin.h

--unoff BETA release 970930 --

452) Urs Janssen <urs@tin.org>
     ADD. replaced explicit 'TRUE' comparisons
     BUG. adjusted prototype for OUTC_ARGS (needed for HP-UX)
     FIX. aclocal.m4, curses.c, feed.c, filter.c, page.c, rfc1522.c

Besides making the program simpler, it let me use const, and get better type-checking. Using <stdarg.h> rather than <varargs.h> was Jason's idea:

Date: Tue, 02 Jul 1996 05:57:59 -0400 (EDT)
From: Jason Faultless <jxfaultl@bechtel.com>
To: "T.E.Dickey" <dickey@clark.net>
Subject: varargs

> That's a whole subtopic.  For simple stuff, you can use <stdarg.h> or
> <varargs.h>, according to which the machine has.  If you want to pass
> that argument-list around to lower-level functions it can get complicated.

Nothing complex at all.

I was wanting to redo the {info,error,warning,etc..}_message routines
with variable arguments. tin is littered with bits of code like

char buf[BUFSIZ];

sprintf(buf, "Here is the real message %d\n", i);
info_message("Warning: ", buf);

because the current functions can only take char * arguments.

Jason.

From termcap to curses

Tin's manual page contains a section CREDITS, which among other things says

Dave Taylor
author of curses.c from the elm(1) mailreader.

That is misleading, because src/curses.c was not a curses interface, but rather a termcap interface, inspired to some extent by functions in the curses library.

It evolved:

Here are links to curses.c from:

However far it evolved, though, the functions borrowed from elm were just termcap or (as in the case of Amiga and VMS) a collection of hard-coded escapes. It was neither extensible nor efficient.

We discussed this:

Date: Tue, 21 Jan 1997 19:00:55 -0500 (EST)
From: "T.E.Dickey" <dickey@clark.net>
To: Jason Faultless <jxfaultl@bechtel.com>
Cc: Unofficial TIN <tin-unoff@rhein.de>
Subject: Re: Problem with quoted highlighting

> > > but it would be great to be
> > > able to scroll 'n' lines at a time.
> > it'd be simple (relatively) using SVr4 curses.  But that would inflict an
> > additional load on portability.
>
> Would it be possible to write it in such a way that the set of valid
> values for 'n' is restricted (to 1 page) for less capable curses libs ?
I've been debating that (with myself ;-).

Here's what I have in mind, wrt the issues I'm interested in:

        + the configuration stuff I've been working on is fairly stable
          (more than 90% done).

        + lint-wise, there's the int  vs long issue (article numbers vs
          array indices).

        + resize doesn't work properly (if I'm editing a reply, tin repaints
          the screen).

        + painting the screen is inefficient.

The last is what we're talking about (though any solution will impact the
resizing).  Basically, if you implement using curses, you lose the ability
to resize tin, except by making assumptions about the libraries you link
with.  Also, it severely limits the non-UNIX hosts that you might want to
port to (though that doesn't seem to be of interest at the moment).  Also,
unless you're using a SVr4 curses (such as ncurses) you won't have color.

So there's 3 choices:
        + make a layer (call it tcurses) that implements the core
          set of curses functions that're used in tin that're readily
          implementable in termcap (i.e., use printf #define'd to printw, etc).

        + implement with curses, ifdef'ing the color and/or resizing according
          to which is doable.

        + leave it as is.

I called it “tcurses” because this reminded me of what I had done for ded late in 1985. The curses library did not work, so I wrote an imitation of the curses interface using termcap. The “t” denotes “termcap” in that name.

In March 1997, I began developing a curses driver which may be used in place of the older termcap driver.

--unoff BETA release 970303 --

329) Thomas E. Dickey <dickey@clark.net>
     ADD. support configuration with termcap/terminfo vs curses
          implements color support from the curses library.

While the curses.c file was intended to imitate the curses library, most of its functions did not behave like curses. I solved that problem in tcurses by adding macros and writing functions which used the curses library to imitate the Elm-based curses.c file. When tin was configured to use the tcurses module, the curses.c file was ifdef'd out.

Making it all work properly took some time, but from that point it was possible to build a workable tin using termcap, terminfo, or curses (either BSD and SVr4).

At the time, there was no wide-character support in tin. That came later, after I started developing this in ncurses in June 2001, with help from Sven Verdoolaege. However, the related work in tin was done by others, mainly Michael Bienia. I gave advice.

-- 1.5.15 release 20021115 "Spiders" --

U119) Michael Bienia <michael@vorlon.ping.de>
      Urs Janssen <urs@tin.org>
      ADD. start multibyte/wide char support
      BUG. TeX2ISO didn't work with UTF-8 locales
      FIX. configure[.in], aclocal.m4, autoconf.h[in], proto.h, tcurses.h
           tin.h, charset.c, group.c, screen.c, string.c, tcurses.c, thread.c

VMS redux

Tin had been ported to VMS, but not kept up to date. This posting in 1996 illustrates that::

Dear NewsReaders,

  please find enclosed some basics in using newsgroups.  On both systems,
UNIX and VAX, just type "tin" at the prompt and then hit enter.  The
process will look as follows:

* on a UNIX machine:
  titan% tin
  tin 1.3 950824BETA PL0 [UNIX] (c) Copyright 1991-94 Iain Lea.

* on a VAX machine:
  $ tin
  tin_vax 1.2 PL2v [VAX/VMS] (c) Copyright 1991-93 Iain Lea & Tod McQuillin.

The quote is misleading, because tin 1.2 PL2 did not have that support. Iain incorporated changes later, in his series of betas toward 1.3 in mid-1995:

--950822BETA released--

253) Andrew Greer (Andrew.Greer@vuw.ac.nz)
    ADD. Added still more VAX/VMS support.

--950726BETA released--

240) Andrew Greer (Andrew.Greer@vuw.ac.nz)
    ADD. Added ever more VAX/VMS support.

--950619BETA released--

230) Andrew Greer (Andrew.Greer@vuw.ac.nz)
    ADD. Beginnings of VAX/VMS support.

Iain's change-log does not mention Tod McQuillin (a student at Duquesne). The tin 1.5.6 manual page said this:

Andrew Greer
for originally porting tin to the VAX/VMS operating system.

That “originally” was added in 2000. The change-log lists at least one other port:

-- pre-1.4 release 981114 "The Watchman" --

621) Michael Stenns <stenns@hal.tci.uni-hannover.de>
     ADD. minor VMS-code cleanup
     FIX. vms/*

-- pre-1.4 release 980514 --

570) Michael Stenns <stenns@hal.tci.uni-hannover.de>
     BUG. negative numerical timezone information was misinterpreted
          on systems with unsigned time_t (i.e. OpenVMS)
     FIX. parsedate.y

-- pre-1.4 release 980202 --

553) Michael Stenns <stenns@hal.tci.uni-hannover.de>
     ADD. VMS port
     FIX. several supplied patches

In 2000, I revived the port to VMS:

-- 1.5.7 release 20001104 "Paradise Regained" --

U051) Thomas E. Dickey <dickey@invisible-island.net>
      BUG. won't compile on termcap systems
      ADD. updated pcre (3.2 -> 3.4)
      ADD. updated some configure script macros
      BUG. vms/parsdate.c required alloca(), regenerated with byacc
      FIX. aclocal.m4, extern.h, proto.h, trace.h, cook.c, curses.c
           feed.c, lang.c, signal.c, tcurses.c, trace.c, pcre/*

-- 1.5.5 release 20000613 "Lucretia" --

U037) Thomas E. Dickey <dickey@invisible-island.net>
      ADD. updated pcre (2.08 -> 3.2)
      ADD. new config.sub/config.guess versions
      BUG. missing cursoron() on exit
      FIX. config.guess, config.sub, configure[.in], mkdirs.sh, autoconf.h[in]
           oldconfig.h, tin.h, misc.c, vms/select.h, pcre/*

Doing that required an account on a VMS system. I mentioned that in a thread on comp.os.vms, in January 2000:

From: "T.E.Dickey" <dickey@shell.clark.net>
Subject: Re: TIN on OpenVMS ?

Peter LANGSTOEGER <eplan@kapsch.net> wrote:
> In article <8671cr$7q1$1@joe.rice.edu>, leslie@clio.rice.edu (Jerry Leslie) writes:
>>Peter LANGSTOEGER (eplan@kapsch.net) wrote:
>>: I've "tin 1.2 PL2v9 [VAX/VMS]".
>>
>>: *) Is there a newer version of TIN ?
>>:     I recently heard of a V1.4. Comments ?

> To answer my own question: V1.4.1 of Dec-1999 is the newest.

>>: *) Is there a newer version of TIN for VMS ?
>>:     I once (1997 ?) saw a V1.3 beta announced here (ftp.*.de ?).
>>:     Did it get official ?

> So far no answer.
> Only some URLs (eg. tango.cchs.su.edu.au, ftp.scn.de) of V1.3 Beta pop up.
> Is this 1995 version really the latest version of TIN ?

950824 is probably it - no one's been porting to VMS afaik.

If someone's interested in reviving it, I can offer advice (I've been working
on TIN off/on since 1993).

(it's been a few years since I had direct access to VMS, and at that point
there was no way to test a news feed on that box - I don't know of anyone
else who was doing more recent work for VMS).

--
Thomas E. Dickey
dickey@clark.net
http://www.clark.net/pub/dickey

Jerry Leslie responded, offering an account on one of the VAXStations managed by Charles Sandmann at Rice University.

Working on this port upgrade required yacc, which led to my porting Berkeley yacc to VMS and converting it from K&R C to ANSI C. I also had to get socketshr to build/work on the VAXStation.

At the time, I did not pay attention to the “curses” driver. The VMS port did not use curses . Instead it used hard-coded strings to approximate the termcap interface used in Iain's version. The VMS-specific code in src/curses.c queried the terminal driver to decide whether those strings should use 8-bit or 7-bit controls.

I could have gone further, and used VMS curses where appropriate. The VMS curses library would have been adequate. VMS curses is basically BSD curses with video attributes such as bold and underline, unlike the hard-coded strings.

On the other hand, VMS has no locale support, and its curses library does not support multibyte characters. When Michael Bienia began using ncurses to develop multibyte/wide-character support in tin two years later, there was no reason to revisit the VMS port and make similar improvements.

The upgraded tin was added to the fifth VMS freeware cdrom late in 2000, as seen here:

https://www.digiater.nl/openvms/freeware/v50/tin-1-4-4/

Jerry Leslie continued using it for several years, as indicated in his 2005 postings regarding a clone of the EDT editor

However, supporting this in the long term was not easy, because it required a machine with enough disk space and a live news feed. I recall discussing it with Urs (but do not see the original email):

Date: Sun, 9 Nov 2003 02:12:44 +0100
From: Urs Janßen <urs@akk.org>
To: tin-dev@tin.org
Subject: Re: [tin 1.7.x [& tin 1.6.x]] -R and server-config dir
Mail-Followup-To: Urs Janßen <urs@akk.org>, tin-dev@tin.org

On Sat, Nov 08, 2003 at 07:52:15PM -0500, Thomas Dickey wrote:
> > > > the patch below converts the spaces in the "reading saved news"
> > > > fake-server name to dashes to avoid a dirname with spaces in it.
> > > Just curious: Why is this a problem?
> > I don't know how portable spaces in file/dirnames are (do they work
> > on VMS?) and IMHO they are ugly.
> They don't work on VMS - but I recall some recent discussion regarding
> removing that port.

Yes, I suggested to remove the VMS bits in tin 1.9.x if nobody is
resurrecting the port before tin 1.9.0 is released. I doubt that
tin 1.6.x works on VMS (IIRC the last version which did compile on
VMS was 1.4.5?). removing the dead code would make the source more
readable.

urs

and Urs removed it:

-- 1.9.0 release 20060228 "Ardlussa" --

U001) Urs Janssen <urs@tin.org>
      ADD. pcre update (6.4 -> 6.6)
      REM. VMS support
      FIX. Makefile, aclocal.m4, attrib.c, curses.c, config.c, header.c
           inews.c, init.c, lang.c, mail.c, main.c, mimetypes.c, misc.c
           newsrc.c, nntplib.c, post.c, read.c, save.c, signal.c, bugrep.h
           tin.h, tnntp.h, version.h, pcre/*, vms/*

Change-logs

Mailing lists and change-logs are useful sources of information when making a history of a project. Tin's change-logs are organized in a different manner than the projects which I develop and maintain (see related discussion).

Iain began making change-log files between patch-releases, discarding each after the patch was released. Doing it that way makes it hard for others to see what has changed over the lifetime of a project. While working on the 1.3 beta, Iain switched to a more complete change-log (without incorporating the older ones), and also changed the order of presentation to the currently used reverse chronological order. Urs continued in this way, though renaming the file to CHANGES.old after releasing tin 2.4.0 in 2016 (i.e., 20 years of development).

Counting change-log entries:

That is a simplification of course. Some change-log entries are more complex, and that is often reflected in their descriptions.

Tin's CREDITS file lists 324 contributors. There is probably some overlap between Iain's and Urs' lists.

According to the change-logs, I've worked on tin longer than anyone, perhaps a year longer than Urs. Urs first appears here, in Iain's change-log:

--950822BETA released--

255) Urs Janssen (ugdf@rz.uni-karlsruhe.de)
    BUG. 'make sol' entry duplicates target label from sysvr4
    FIX. Makefile - applied supplied patch.

Though initially reluctant, Urs is the maintainer:

Date: Fri, 4 Oct 1996 14:08:37 +0100 (MEZ)
From: Urs Janssen <urs@akk.uni-karlsruhe.de>
To: Steve Snodgrass <srs@sysalt.com>
Cc: jxfaultl@bechtel.com, tin-unoff@rhein.de
Subject: Re: Tin Release

> I just want to take a moment to agree with this.  Tin-unoff changes weekly,
> and I never know if any of these versions are stable.  I'd love to see a whole
> new release (maybe version 2.0, with all the changes) that could become a
> standard to patch against.

a non beta release would be great BUT tin-unoff is still buggy...
and just stripping the word beta out of the name won't fix that bugs ;-)

and before doing renaming tin-unoff to tin2.0 or something like that we have
to think about the non-unix suppoprt, what is with all the Win/NT/VMS-stuff?

> Does anyone know if Urs has discussed this with Iain?

haven't talked to Iain for about 6 month now... but I never planed to
"take over" tin - I hope that Iain someday will find the time to work on tin
and that most of the changes will make the way into his release...

urs
--
"The documentation is in Japanese.  Good luck." Rich $alz

The last reference to “tin-unoff” in my email is from a re-subscribe to the mailing list in April 1998. Urs skipped a release for tin 1.3, releasing tin 1.4.0 in November 1999.

Screenshot

An example showing tin's color scheme. No, it does not look like dselect:

Sample screenshot for Tin newsreader

The first mention of color in dselect's changes was in July 2001, while tin has supported color since April 1996. Someone might suggest that dselect imitated tin, but actually the color scheme more closely resembles another program. Either way, the developer did not provide that insight in the change-log or documentation.

Download:

The latest official release and beta releases are available at:

http://www.tin.org/
ftp://ftp.tin.org/