[32;1mC SECTION PROGRAMMING - PROJECTS.                               JJB TEMPLAR[m

                       (1) Ty1.3
                       (2) Text display programs.
                       (3) WB Pseudo-residency.

[32m>>  1   Ty1.3.[m

    The ty1.3 project is under way. The main transformation details are:

        ty1.2:  Opened up a "RAW:etc" file, and used that for output and
                user input.
        ty1.3:  Opens up an Intuition window, and attaches a console.device
                to it. The console.device is used for output, and the IDCMP
                port of the window is used for user input.

                This has allowed the attachment of lots of little gadgets
                in the borders of the window.

    A number of other modifications to suit the main goal have also been
    made. The poor sod who's been doing all this is... me, with advice and
    suggestions from Tony Wills. A number of "nice features" have not been
    implemented yet, and are begging for one of you expert types to have a
    go at:

        1)  Search for regular-expressions.
        2)  Detection of binary files, and having a hex output option like
            "type foo opt h" produces.
        3)  Paging, based on ^L characters. Basically just detecting ^L
            characters, and treating them as a temporary EOF.

    If anyone is interested in improving ty, send me a disk for the source.
    It would help if you used Lattice C (or were willing to do a little
    porting).

    A problem that has arisen is the imagery of the gadgets. My original
    4-color gadgets have come in for some criticism with regard to the way
    they look under the normal WB colors (blue-white-black-orange). When I
    drew the gadgets in the first place, I used my own color scheme, which
    is black-grey-white-red. I drew basically white gadgets with a black
    shadow on a grey background. This comes out as black gadgets with a
    blue shadow on a white background for the ordinary WB setup, which
    obscures the gadget imagery quite well. So if anyone feels they possess
    some artistic talent, I can provide a picture of the gadgets for you to
    improve upon. This only requires you to have a paint program, and a
    blank disk, but if you also have Lattice C v5 (or above) then I can
    provide the source too so you can see what your gadgets look like in
    action.


[32m>>  2    Text display programs.[m

    With regard to the ty1.3 project, it may be useful to know something
    about the "competition". Any useful features of these other programs
    could eventually be grafted onto ty, if practical. Much of this
    information is from Tony Wills, who tested (and discovered) many of the
    features/bugs of each program. Some possible categories for comparison
    are:

  [32mDisk- vs RAM-based:[m

    To start with, I will categorise text display programs into two main
    types: disk-based or RAM-based. A disk-based program is one that, like
    ty, does not require an entire file to be loaded into memory. Instead,
    these programs read parts of the file from disk as required. RAM-based
    programs do require the entire file to be in RAM.

    I do not believe RAM-based programs are adequate for general use, since
    the files they can handle are limited to the amount of memory you have.
    For many people this will be from 512K to 1Meg. This is a problem with
    PD disk lists, and material downloaded en masse from bulletin boards or
    networks like BIX, CompuServe, etc. However, they have a number of
    significant advantages over disk-based programs:
        - Very accurate line checking can be kept, which makes for easy
          implementation of vertical scroll bars (and no doubt other
          niceties).
        - Having the entire file in RAM makes the input routines required
          significantly simpler, so RAM-based programs are much easier to
          implement.
        - Movement through the file is (or should be) very fast. This is
          often the overriding concern of the implementors of RAM-based
          programs.
        - Display location is simpler, so RAM-based programs could easily
          include images integrated into the text.

  [32mThe variety of basic operations available:[m

    As the prototype I will use Commodore's "more" program, which should be
    available to all Amiga owners. There are at least two versions, 3.23
    and 3.27. I will consider 3.23, since I believe 3.27 was a step
    backward featurewise for the sake of program size.

    See the file "table" in projectsdir. The basic features are the top
    section of the table.

  [32mThe variety of esoteric operations available:[m

    See the file "table" in projectsdir. I may have missed some features,
    and may have gotten some wrong. In addition, there are more features
    that people could want that do not appear in any of the programs I have
    looked at.

  [32mThe "friendliness" of the controls for those operations:[m

    Basically, a program is defined as being more friendly if it has more
    Intuition support. However, an ideal program should have extensive
    control via both Intuition and the keyboard. I feel it is a reasonable
    desire to want programs used from WB to have Intuition support, since
    the user will have invoked the program via mouse (and thus will have
    adopted a casual posture: slouching over to the right, mouse in one
    hand and a cup of coffee in the other), and may not want to have to use
    the keyboard.

    Another contributing factor to "friendliness" is the "convenience" of
    some operations. This means things like:
        - Repeating arrow gadgets.
        - Minimal screen-flashing. Someone has to implement a bug-free
          general bell! Screen-flashing invariably makes me nauseous.
        - Repeating cursor keys.
        - Single key or click commands. Multiple mouse operations are what
          make menus extremely inconvenient for moving forward by lines,
          etc.

    This is clearly a more general issue than the variety of operations a
    program has, and many people may disagree with what I consider to be
    "friendly" controls.

  [32mMiscellaneous:[m

    This covers things like:
        - Bugs.
        - The "appearance" or "feel" of the program.
        - The availability of the source code.
        - The language the program was written in.

                  [32;1;4m So moving onto specific programs [m

    I will look at the following text display programs:
        - More v3.23, v3.27.        - Amiga LESS 1.3.
        - Ty 1.3.                   - Most.
        - MuchMore.                 - TextDisplay.
        - View.                     - Viewer.
        - MouseReader.              - Vmore.
        - Vnews.

  [32mMore v3.23:[m

    By:   CBM.                      Size: 10912 (3.27 is 9052).
    Type: Disk-based.

    Friendliness:
        - Basically one-key commands.
        - Has full help info.
        - No Intuition support, but handles Window resizing properly.
        - Doesn't handle repeating "forward-line" command.
        - Little support for backward movement.
    Miscellaneous:
        Well, this is the one I use from the CLI. It is fast, clean, pure,
        and comes from Commodore. I would assume it is written in C or
        assembler, and that the source is not generally available.

        I would also assume it is based on the UNIX "more" command.

  [32mAmiga LESS 1.3:[m

    By:   Bob Leivian.              Size: 28848.
    Type: Disk-based.

    Friendliness:
        - Again, mostly single-key commands.
        - Has full help info.
        - No Intuition support.
        - Does NOT handle resizing properly.
    Miscellaneaous:
        This is used by Fred Fish on the AmigaLibDisks. However, it is very
        easy to crash, by pressing the cursor keys a few times, say. It is
        based on the same "less" program ty evolved from, and that in turn
        was based on the UNIX "more" command. Ty is based on "less v48". I
        believe "Amiga LESS" is based on "less v70-something".

        It was probably written in C, and the source may be available from
        Fred Fish or Bob Leivian.

  [32mMouseReader I:[m

    By:   William J Betz.           Size: 41024
    Type: Disk-based.

    Friendliness:
        - Control is via direction gadgets, a vertical scroll bar, and a
          menu.
        - There are no keyboard controls.
        - The vertical bar behaves wierdly on large files, and also like ty
          a pass through the file is required to determine the file's
          length (in lines, I assume). Nice to see someone else had the
          same problems I had with a scroll bar.
        - Uses a "real" file requester. Looks like a "cheath" job.
    Miscellaneous:
        This program was on Fish 57, and is a shareware program. There is
        (or was) an enhanced version available to registered users.

        This program has some of the basic features that went into ty1.3.
        Pity I discovered this prog after I'd done the ty1.3 stuff.

  [32mVmore  '87:[m

    By:   Stephen Vermeulen.        Size: 6868.
    Type: Disk-based.

    Friendliness:
        - Very easy to use, primarily 'cause there aren't many controls.
        - Movement keys repeat.
    Miscellaneous:
        Found on Fish 117. To do with the Canadian group AMUC. Has three
        controls, quit, next-page and prev-page. There is no resize gadget.
        Doesn't handle "dirty" data too well. Has been known to GURU, but
        in unclear circumstances. And may do something wierd to free RAM.
        Still, Vermeulen is an Amiga guru from way back.

  [32mVnews 1.1 (87):[m

    By:   Stephen Vermeulen.        Size: 12472
    Type: Disk-based.

    Friendliness:
        - All controls are gadgets.
        - Looks a little strange due to use of multiple (and borderless)
          windows.
    Miscellaneous:
        Found on Fish 107. Used on AMUC equivalent of our Newsdisks to show
        directories of Usenet messages (which don't have ANSI codes).
        It is written in Aztec C, source available. It has no resize
        gadget. On the subject of Aztec C, there is an obvious mis-
        pronunciation that allows us Lattice C users revenge for the
        Lettuce crack. But it's not for a family thingymajig like this,
        unless we're talking about donkeys, etc (A?s-tech :D).

  [32mMost v1.20:[m

    By:   Richard Wynn.             Size: 11324.
    Type: RAM-based.

    Friendliness:
        - Has HELP info for key commands.
        - Has a very nice BIG vertical scroll bar, that works accurately.
        - Has up/down arrow gadgets, which repeat.
        - All operations are available from the menu.
        - The key commands for next-line, prev-line do not repeat.
        - Has no resize gadget (but does automatically size itself to the
          size of the WB screen).
        - It won't resize to a vscreen sized screen - noted by Tony.
    Miscellaneous:
        This program was written in assembler, for the Australian()
        "MEGADISC" ... um ... thingymajig. It is also used by the AmigaTECH
        people. It is copyright '89 by Richard Wynn, all rights reserved,
        so I don't suppose the source is available.

        It GURUed on the AmigaLibDisk file (407K), noted by el Prez. The
        fact it got as far as a GURU is significant, since Tony runs GOMF.

  [32mMuchMore v1.8:[m

    By:   Fridtjof Siebert.         Size: 19436.
    Type: RAM-based.

    Friendliness:
        - Generally single-key controls.
        - Has help info for keys.
        - Mouse can be used to stop/start scrolling, but basically a
          keyboard oriented program.
    Miscellaneous:
        This program's biggest strength is its scrolling. It is very
        smooth, can be toggled between slow and fast, can go forwards or
        backwards, etc. Very nice. Fred Fish is thinking of using this on
        the AmigaLibDisks instead of Less. I tend to think of "less" as
        family, since it shares its parentage with ty, but MuchMore would
        be a nice replacement.

        It is written in a mix of Modula-2 and assembler, and the source is
        freely available and modifiable.

        Note that MuchMore uses a seperate task to load the file, so if
        you try to read a file larger than your available RAM, you can zip
        along fine until RAM runs out, then GURU. Most RAM-based programs
        attempt to load the file before starting to display it, so they do
        not allow you to read anything.

        Also note that whether the thing GURUs or not seems to be up to
        the Modula code, which sometimes brings up an alert, and sometimes
        doesn't. Modula-2 is quite protective, eh?.

  [32mTextDisplay v1.1:[m

    By:   Roger Fischlin.           Size: 5748.
    Type: RAM-based.

    Friendliness:
        - Very simple, all control through 6 big gadgets.
        - Scrolls quickly.
        - Apparently won't resize wider than 80 columns (on vscreen
          expanded WB), notes Tony (this obsession with vscreen!).
        - Also apparently "hogs machine so multitasking is difficult".
          Looking at the thing with AskTask, it seems to busy-wait on the
          IDCMP port. Must be a logical explanation...
    Miscellaneous:
        Don't know what this was written in (assembler?). Source code not
        available. This program's saving grace is its small size and
        simplicity, the smallest of all those listed here.

  [32mView:[m

    By:   Bryan Ford.                   Size: 7592.
    Type: RAM-based.

    Friendliness:
        - Movement only control, all through vertical scroll bar and arrow
          gadgets.
        - Tony reports that it seemed to hang on exiting after reading a
          400K file. I think what happens is it takes a LONG time to free
          the memory it allocates. And even then manages to lose a lot
          somewhere.
    Miscellaneous:
        Yeah. Again, another simple program. You decide whether a scroll
        bar is better than just TextDisplay's up and down gadgets.

  [32mViewer v1.00:[m

    By:   Martin Taillefer.             Size: 9460.
    Type: RAM-based.

    Miscellaneous:
        Has fast scrolling (uses its own 2-color screen). Written for
        AMNews (eh?). Screen is 320x200. No resize. Source is available.

  [32mTy 1.3:[m

    By:   On the Amiga first Tony then me.  Size: varies (at least 26K).
    Type: disk-based.

  Friendliness:
        - Attempts to use commands compatible with both "more" and "ty 1.2"
          where possible.
        - Full help information for keyboard commands.
        - Loaded with gadgets (for which there is no help).
        - Tried to make the gadgets look nice, but really requires someone
          good at that sort of thing.
        - Doesn't pipe (used to...).
        - Vertical scroll bar is... weird. I don't like it.
        - Has an audible bell, since I find using DisplayBeep a lot has an
          adverse effect on my peace of mind.
  Miscellaneous:
        This is written entirely in Lattice C v5.0. I currently have the
        most recent source, and anybody who wants to is welcome to make
        modifications.

        Note that only "ty" and "more" handle all the ANSI combinations,
        because they use the console.device for their output, and pass ESC
        through.


[32m>>  3   WB Pseudo-residency.[m

    I looked at the source code to the cres startup module (c.a), and it
    seems to me that the resident stuff is performed even if the program is
    started from the Workbench. So programs that use cres could be made
    resident in a Workbench environment, if Workbench had a resident
    capability.

    Pondering on this, I thought of the following:
        ׻ When program starts, SetFunction() LoadSeg and UnLoadSeg.
        ׻ The function to intercept LoadSeg works as follows:
            if the node part of "name" is equivalent to the program, just
                return segment pointer from Process structure
            else go through to real LoadSeg
        ׻ The function to intercept UnLoadSeg works as follows:
            if the segment pointer is the same as the program's, just
                return
            else go through to real UnLoadSeg
        ׻ The program itself would have to avoid terminating until it was
           sure any copies of itself had ended.

    This seemed really simple to me, so I implemented the basics in ty1.3.
    I wrote segha.c and segdamn.a (in the projectsdir) to grab the vectors
    and then put them back. To start with, I put the vectors back straight
    after taking them, to see if SetFunction() would work without
    complications.

    Well, it didn't work. After I've put the vectors back, the program
    crashes when it terminates (when UnLoadSeg is called on it). I am
    intercepting LoadSeg alright, as I've tested it with a printf, but as
    for what I'm putting back... I tried just replacing LoadSeg, and
    leaving UnLoadSeg alone. The program terminates OK, and for the next
    couple of programs things are alright. Then GURU.

    If someone knows what's happening, I'd like to know. If this can be
    persuaded to work, WB resident programs would be a small step away.

    Some notes for a general WB resident program manager:
        ׻  The LoadSeg wrap function could detect if WB was calling it by
            the following expedient:
                ׻  Call FindTask(NULL)
                ׻  Compare task name to "Workbench"
            In fact, the main program could find the Workbench task, and
            cache the pointer away somewhere for quick comparison by the
            wrap function.

            So it would be possible to intercept just WB calls. This is
            necessary to avoid zapping the WShell, ARP and 1.3 resident
            capabilities.

        ׻  It should eventually be able to traverse the WShell, ARP and
            1.3 resident lists. This would avoid having to have duplicates
            in our list and the others.
