http://invisible-island.net/
Copyright © 1996-2014,2021 by Thomas E. Dickey
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.
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”).
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).
I have done other work on tin. Refer to the older changelogs and Urs' history outline for context.
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.
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
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.
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
include/conf.h (230
lines), withsrc/makecfg.c (425
lines) andsrc/tincfg.tbl (112
lines).At first glance that might appear to be costly, but the table-file is much shorter, and more easily maintained.
In current (2021) code,
malloc callsOne 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_t, size_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:
At the time that I wrote this, I had no access to usenet. So I wrote my own, and made it part of a library designed to support my tools.
Later, while at the Software Productivity Consortium (SPC), I was aware of vendor-specific debugging-mallocs (such as malloc_debug in SunOS) that would be ready for use.
Other libraries had to be downloaded and compiled.
Making the debugging feature part of the program that I was developing was not a drawback.
doalloc was crude and not as fast as I would
like. But it sufficed to point out memory leaks in
tin, and helped me to provide fixes to
Iain.
The ifdef in tin.h was useful only to me,
until I left SPC and began making my programs available to a
wider audience.
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):
Nickolay's change turned the feature on if
DBMALLOC was defined.
I improved that by adding a configure script option and a configure check for the existence of its header-file and library.
At the same time, I added a similar option and check for dmalloc. I had used dmalloc 3.1.0 since its release in July 1995 (see discussion of these tools).
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.
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.
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:
Iain trimmed the file from 41 functions to 12, 883 lines to 290 in tin 1.0PL0.
Very little of the original file remained:
$ diff -w -u elm2.3/src/curses.c tin-1.00/curses.c|diffstat
curses.c | 865 +++++++++------------------------------------------------------
1 file changed, 136 insertions(+), 729 deletions(-)
$ wc -l elm2.3/src/curses.c tin-1.00/curses.c
883 elm2.3/src/curses.c
290 tin-1.00/curses.c
1173 total
In changes through 1.2PL2, the file grew to 24 functions, 836 lines (14 changes).
In Iain's last 1.3beta, the file had 30 functions, 1031 lines (3 changes).
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
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:
Jerry Leslie continued using it for several years, as indicated in his 2005 postings regarding a clone of the EDT editor
Re: Interest in SEDT (DEC-style) editor on Solaris? comp.unix.solaris December 2, 2005
tonymcg27@yahoo.com.au wrote: : Hi there, : : I've beeen working with VMS for 20 years, but slowly moving to Solaris, : but I cannot function with the EDT keypad. I'm currently trying out the : JED editor which has an EDT emulation mode, but I would also like to : check out SEDT. I remember using SEDT many years ago on Windows PCs. : : Thanks for your efforts in getting it going on Solaris. : Cheers from Down Under, : Tony : There's another freeware editor patterned after EDT: ED http://clio.rice.edu/EDstuff/ED_Overview.txt ED runs on most unix systems, including AIX, HP-UX, Linux, Tru64, Solaris, BSD variants. It runs on Windows systems from a DOS window, and of course it runs on VMS systems, such as this VAXStation 4000 Model 96 running a VMS version of the 'tin' news reader. --Jerry Leslie
Looking for a No Install Text Editor February 24, 2005
2005 thread on comp.os.vms.
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/*
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:
Iain's logs for versions 1.10 to 1.22 lists 154 contributors, totaling 345 changes. Two thirds of those (myself included) are listed once. Iain is credited with about a quarter of the changes.
Iain's 1.3 betas cover about the same time span, with 77 contributors, 256 changes. In that log, my 13 changes rank third, behind Iain (81) and Mark Tomlinson (43).
Urs' logs cover a much longer time span, with 191 contributors, 1123 changes. In that log, my 111 changes rank second, behind Urs' 242 changes.
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.
An example showing tin's color scheme. No, it does not look like dselect:
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.
The latest official release and beta releases are available at: