[net.micro.pc] More on the SSI WordPerfect package and assembler programming

ted@imsvax.UUCP (Ted Holden) (11/24/85)

Reza Zarafshar replied to my article on WordPerfect:

>>                The niftiest feature  of  WordPerfect  is  an  invisible one
>>           which they  don't really advertise;  the fact that the program is
>>           coded in  PC assembler.   This  makes the  program hellishly fast
>>           compared to  ANY other word processor I've ever dealt with on any
>>           kind of hardware.   WordPerfect can  flash from  one end  of a 50
>>

>        I don't feel that something written in Assembly language these days
>can be considered a "nifty" feature.  While I agree that there are a few
>programmers left that can write faster code than a few non-optimizing
>compilers, it is still a better idea to produce something that is
>maintainable and not a "hack" than something that is just plain fast.
>There are far better reasons for writing in high level languages than
>just speed these days.  Speed is wonderful but if the stuff makes you
>re-boot every once in a while, I think one ends up wasting more time
>than that gained by Assembly language speed.

>>                WordPerfect  has  more  features  than  any  other  PC  word
>>           processor.  It has text, decimal, centered, and right-flush tabs,

>        It is a noble idea to produce "Swiss Army knife", but believe me
>the more features your throw in the thing the more chances of blowing
>yourself out of the water very often, especially when the stuff is written
>in Assembly.
>

     Several things I should point out.  First, I don't normally recommend
programming in assembler to anyone other than masochists;  I use the Mark-
Williams C compiler for all of my own programming work on PCs and suggest most
others writing for PCs do likewise.    The  only  legitimate  NORMAL  uses for
assembler  which  I  could  think  of would be writing compilers and op-system
functions.  However, once you have a certain machine architecture in the hands
of 15 million users (the PC), it BECOMES legitimate to write in assembler when
attempting to produce an ULTIMATE product of a certain genre FOR that machine,
which is what SSI is doing.  

     As far  as having to re-boot or anything of the sort goes, your intuitive
assessment of the situation is wrong.   At  IMS  we  have  one  guy  whose job
includes  finding  and  categorizing  ways  to  blow  up  all of the common PC
software programs, and WordPerfect is the ONLY PC class word  processor he has
never been  able to blow.  Blowing up Multimate (mostly written in C) or Samna
(entirely in C), by contrast, is relatively easy.  

     My own experience with WordPerfect is mostly related  to the  one feature
of WordPerfect  4.1 which  doesn't really  work, the  Navy DIF  section of the
little SSI  Convert Routine;   essentially,  SSI just  took a  literal copy of
NAVDAT 17.11  and wrote  up a  set of  "DIF filters" as if the whole thing was
just a look-up table, not realizing how much more than that is involved in the
Navy's  DIF   effort.     Essentially,  I  deciphered  the  file-structure  of
WordPerfect and wrote a set of real DIF conversion routines which the Navy has
found acceptable  and which  allows IMS  to use  PCs in federal bids involving
word processing which call for DIF (which will soon be all of them).

     All of which gave me an insight as to the final really big edge which SSI
has over  all of  the competition;   their  file structure itself is about 100
times more concise and  intelligently  formulated  than  any  other  I've ever
looked  at.    It  is  totally  modularized,  with  no  pointers  or any other
unnecessary structures, and with the effect  of any  control code  felt at the
point at which it occurs.  

     A WordPerfect code for a margin or tab stop change, for example, contains
both the old  and  new  values,  so  that  the  program  can  make  the proper
adjustment when passing over it going in either direction.   A tab setting for
one of WordPerfect's 160 column ruler lines consists of a  hex c9  followed by
20 characters for the old ruler, then twenty characters for the new ruler, and
then another hex c9.  Each of the twenty characters  represents a  bit pattern
(8 x  20 = 160) with bit n set if a tab stop is set at that column, thus a 160
column ruler line is totally described in 42 bytes, with no need  for pointers
and constant  recalculation of  page size etc. to allow the program to move in
either direction.  Pretty neat, isn't it?

pavlov@hscfvax.UUCP (840033@G.Pavlov) (12/03/85)

 ... maybe you don't have to reboot the system very often, running SSI WP -
     but it does let things get out of control every once in a while (try
     saving a file to a damaged floppy, for example.  You'll recognize the
     "Abort, Retry, or Ignore" message - but will a secretary ? Answer "A"
     and you're back at DOS level - with your work gone -  ).

     The tab stops are a pain, by the way - auto indents work off them - and
     they're absolute. So if you decide, after you've typed in your document,
     to change margins, you have to reset all the tabs as well - else your
     indents are likely to be halfway across the page.

 Or: center a text string, with text already on the line - and then try to de-
     cipher the nonsense that results on the screen.  Yes, you can go into the
     "reveal" screen to see what is "really" there.  But that is a difficult
     thing to understand, if you don't have a good familiarity with PC's.

 It is a good package; I and a group of people that I work with use it exten-
 sively.  But some of the recent comments about it show a lack of perspective.
 It's a good - but still imperfect - piece of software - that may not be ideal
 for many people.