Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!lll-crg!rutgers!sri-spam!sri-unix!hplabs!ucbvax!CORY.BERKELEY.EDU!dillon
From: dillon@CORY.BERKELEY.EDU (Matt Dillon)
Newsgroups: net.micro.amiga
Subject: The Screwups Most Companies Make (TSMCM) and the WorkBench
Message-ID: <8610072043.AA18045@cory.Berkeley.EDU>
Date: Tue, 7-Oct-86 16:43:42 EDT
Article-I.D.: cory.8610072043.AA18045
Posted: Tue Oct  7 16:43:42 1986
Date-Received: Wed, 8-Oct-86 08:22:08 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: University of California at Berkeley
Lines: 90

>Steve Walton writes:
>     One further note:  I compiled Matt's original Shell program with Manx.
>I added some #define's in shell.h to get rid of most of his xstdio routines
>so that the only routine I needed from MY.LIB was xprintf, and that only to
>get fprintf() to an AmigaDOS file handle.  (Memory allocated with malloc()
>with Manx is automatically free()'d upon return from main() or upon a call
>to exit()).  The resulting executable was 23K plus a bit long.  I believe
>this compares favorably to what Matt gets with Lattice and MY.LIB.  One has
>to wonder about a company whose library can be bettered by one guy working
>in his spare time...

P.S. this is not a flame or anything, just a phase shift from a general
point to what, in my opinion, are facts on a parallel line of reasoning.

(In other words, I'm changing the subject)

The difference is that I wrote it mainly for me, myself, and I, and thus
didn't fudge on any of the routines.  Lattice and Manx, on the other hand,
do not have the quality of their libraries and compilers #1 on their list...
they have other, more important (in their eyes) things to worry about.
Certainly there are the programmers who write the stuff, and they may care,
but they are still bound by a beaurocracy that wants certain results within
a certain time-limit.

What most companies don't understand is that it is the quality of their
product that determines it's livability in the long-run.   The following
are true IN THE LONG RUN and eventually determine a product's fate.

As applied to computers:

    -Hardware will never go beyond the design potential of the machine
    -Hardware that does go beyond the machine's design will never
     integrate well with the machine.
    -Software, no matter how good, will never be able to make up for
     deficiencies in the hardware. (assuming that in the long run
     a given software package will be available on ALL the machines in
     question)
    -Software, no matter how good, will never be able to make up for
     deficiencies in the OS.
    -Software that does attempt to go beyond the OS by bypassing it will
     never integrate well with the machine's design intentions.
    -A well designed machine will have rock-solid design intentions.
     (the MAC was rock-solid, but also surpressive.  The Amiga is 
      rock-solid.)

The moral is that if you find a deficiency in your OS, FIX IT IMMEDIATELY.
Do not worry about incompatibilities.  Hardware is a different matter since
you cannot easily propogate the changes to all concerned.  In the same way,
deficiencies in software should be fixed as soon as possible.  The latter
doesn't fit in well with most Companies since it involves a new release and
updates, but fits extremely well with PD software.  This is why there are
umpteen revisions of most good PD programs, because the writer cares and
because she/he can distribute a new version at any time. 

Example: (TSMCM-WB)
    The current Amiga's Directory structure is incompatible with the
    way WorkBench works.

    Neither the Workbench or the Directory structure is at fault, they
    just don't blend together well.

    The question is, which should you modify to become compatible with
    the other?

Solution:
    In this case, it is obvious that the WorkBench ICON structure should
    be modified.  Specifically, it is obvious that the ICON's should all
    be stored in a single file for each folder because this is what
    DOS is best at... finding a known file and reading its contents.
    The results:

        (A) No directory searches need be done
        (B) Window openning becomes an order of magnitude faster
        (C) The directory/folder structure is retained
        (D) The fix can be propogated without invalidating any software
            to date by the simple distribution of a new workbench and a
            utility to convert from the old (multiple files) to the new.

    It does not make sense to modify DOS:

        (A) Directory searches for most applications are now almost completely
            eliminated so modifing DOS may become superfluous.
        (B) Applications now have a new way of finding specific information
            (like DPAINT files) by having that information be represented
            by N ICONS (all of which can be accessed almost instantaniously).
        (C) Changing DOS would break everything in existance that does funny
            things with the disks, and probably more.
    

                                -Matt