Subject:	Re: Less for DOS
To:	leisner AT sdsp DOT mc DOT xerox DOT com (Marty Leisner)
Date:	Sun, 31 Jul 1994 13:10:33 -0600 (CDT)
Cc:	eliz AT is DOT elta DOT co DOT il, djgpp AT sun DOT soe DOT clarkson DOT edu
From:	mcastle AT umr DOT edu (Mike Castle)

Amazingly enough Marty Leisner said:
> less 2.00 was just released on prep...
> 
> When we settle down on djgcc 2.0, it would be worthwhile to port...
> 
> Also, is there a port of elvis to djccc?
> 
> When we get version 2.0 stable, I'm going to look into porting nvi to
> dos...

Are these worthwhile ports to DJGPP?  DJGPP provides a great
enviroment for porting/developing memory hungry and cpu
intenstive programs, but for file intensive programs, it just
plain sucks.  Take a look at the port of the FSF fileutils:
they're just plain slow.  Unless someone wanted to take the time
to write a lowlevel 32bit interface to the hardware so that you
don't have all those RM/PM switches, this isnt' going to change
(well, actually I shouldn't say that:  does DPMI work better when
it provides the file services?)

All three of these programs are very disk intensive.  Both elvis
and nvi do not keep much of the file they're editting in memory;
instead they keep incremental changes in a temp file (that's why
you're able to recover so cleanly when using vi and your editting
session is interrupted).  Becasue of this, using them will be
pretty slow.

Also I believe all of these packages use termlib rather than
curses.  This means that termlib will have to be ported, and the
user must use some sort of ansi.sys terminal interface.  I
believe that these outputs will result in a RM/PM change for
every screen update, so even that will be slow.

About the only possible way to make performance accetable to be
to do some tremendous hacking of termlib:  The output routins
(tputs and company) would have to be rewritten to go to an
interanl interpreter that would take the "escape sequences" and
do the screen updates itself the same way the curses does, that
is with direct screen writes, rather than going through doprt or
puts, whichever it does.  Not an insignifcant project by any
means.

I'm not saying that these shoudln't be done, but if you want to
be able to show off DJGPP, try a useful package that would be
better suited to the environemnt.  How about Oleo, the FSF's
spreadsheet package?  Certainly it would be about evenly divided
between being memory/cpu bound and io bound.  Heck, you could
even do an X port of it if you have DV/X.  Hey, how about a port
of emacs that supports X for use with DV/X?  

I think more care should go into what one should consider to
port.  Rather than doing everything in site, take a closer look
and see if it will benefit from what DJGPP has to offer.  I would
hate to see ports done, and then be unacceptable, perhaps even
unusable due to perfromance reasons; and I honestly feel these
three proposed packages would suffer.  If they do have the poor
performance (or even slower performance compared to their 16bit
cousins) then it will reflect poorly upon DJGPP.

-- 
Mike Castle .-=NEXUS=-.  Life is like a clock:  You can work constantly
  mcastle AT cs DOT umr DOT edu     and be right all the time, or not work at all
   mcastle AT umr DOT edu       and be right at least twice a day.  -- mrc
    We are all of us living in the shadow of Manhattan.  -- Watchmen

- Raw text -