Re: C-kermit fails

[Frank da Cruz <fdc@columbia.edu>]

On Fri 32 Jul 2020 Maciej W. Rozycki <macro@linux-mips.org> wrote:
> Since you already use #ifdefs to provide code alternatives then may I
> suggest that you keep the relevant piece for the systems where the gain
> from using getchar/getc is actually noticeable and switch to documented
> standard interfaces for contemporary systems?
>
That's what I have always done since C-Kermit first appeared in 1985, and
it's why C-Kermit is so full of #ifdefs.  Although I'm not sure I accept it
is incumbent on developers to stop using fread because somebody can't be
bothered to implement a politically correct way to peek into the buffer to
see if any characters are there.  This is necessary to prevent the program
from blocking on an input request at a time when it might productively be
doing something else.  Which is a classic problem that must be solved in
every terminal emulator.  Of course there are more modern ways to write
terminal emulators, e.g. using threads or whatever, but these are not
available on all the platforms where C-Kermit runs.  Not even select() is
available on all those platforms. But the whole point of C-Kermit is to not
have to write a whole new program for each platform, but to have a single
code base that is portable among as many platforms as possible.

I have no control over what operating-system makers do (or the makers of
glibc), and if they think it's OK to break existing applications I'll have
to program around it when I could likely be doing something more useful.
But ever since Unix went public, and especially since the free versions
appeared, I find that I spend more time redoing everything I already did
before than I spend doing anything new.  Software development was not like
this when computing was dominated by companies like IBM and DEC, who were
dedicated to preserving their customers' investments in software because if
they didn't, they'd lose those customers.

- Frank


On Fri, Jul 31, 2020 at 8:41 AM Maciej W. Rozycki <macro@linux-mips.org>
wrote:

> On Fri, 24 Jul 2020, Frank da Cruz wrote:
>
> >  The reason I use getchar/getc is that Kernighan and Plauger recommend it
> > because it's buffered and avoids needless context switches.  I'm sure you
> > guys don't care much about the efficiency of character loops, but some of
> > the ancient machines where C-Kermit runs are pretty slow.
>
>  I can't speak for other people, but myself I do care, and I also enjoy
> using vintage computers, although maybe not as old as DECSYSTEM-20 (a VAX
> is probably the oldest piece I have).
>
>  Since you already use #ifdefs to provide code alternatives then may I
> suggest that you keep the relevant piece for the systems where the gain
> from using getchar/getc is actually noticeable and switch to documented
> standard interfaces for contemporary systems?
>
>  This way you'll keep the benefits for everyone: much needed performance
> for the old systems and portability for current systems where any gain
> from fiddling with libc internals accidentally exposed is lost in the
> noise?
>
> >  Computers and
> > operating systems are supposed to serve the needs of human beings.  But
> > when you make non-backward-compatible changes to operating systems that
> > break existing applications, you force people to stop what they are
> working
> > on (a cure for some deadly disease, perhaps) and search for a new version
> > of the application they were using that "complies" with the new
> "standard",
> > and then, not finding one, hunt down and contact the developers, if they
> > are still alive, and beg them to "update" their software.
>
>  Yes, this is painful indeed, and much overlooked by software developers
> nowadays IMO.
>
> > At Columbia U the transition from DEC-20 to Unix (DEC Ultrix at first)
> was
> > a massive job; NO software could be ported, all the applications had to
> be
> > rewritten from scratch, in C of course.  But going from Ultrix to SunOS
> to
> > Solaris and finally to Linux was relatively painless.  So I think the
> > objective of Unix OS developers should be *towards* compatibility rather
> > than away from it, as seems to be the case with glibc.
>
>  This is why we have a set of standards for the interfaces we promise to
> support.  Please try and stick to them.
>
>   Maciej
>