To: stik@ON-Luebeck.DE
Subject: Re: [2] STIK: STiK 2.x concerns                                                     


On Thu, 20 Feb 1997 16:57:26 Martin Mitchell <mem@mode wrote: 
>
>On Wed, 19 Feb 1997, Ronald Andersson wrote:
>
>> >As you can see, the module loading was hopeless on the ST. I would expect
>> >a time of 15-20 seconds to be acceptable for the ST.
>> 
>> Yes, that sounds reasonable, and properly used even TOS 1.0 will allow this.
>> 'Properly used' here means that you should install the bugfix patch PINHEAD.
>
>I know about Pinhead, I also know that I don't like it very much. I tried
>it about 7 or 8 years ago, and it caused very many problems with other
>programs on my ST. Therefore I shall never endorse its use, nor would I
>register it with the author.

That is possibly due to the use of a system vector without XBRA (ikbd_vec),
that implements a hot-key function.  The author was aware of a problem with
that function (but seemed unaware of the reason) and has removed that function
in version 2.1 of PINHEAD.  I agree that $15 may seem a lot of money to pay
for something to use mainly with an obsolete TOS, but that is up to you.


>I did however obtain a copy of Pinhead again to test your suggestion. It
>decreased the load time on the ST from 39 to 15 seconds, a figure that I
>think is very acceptable.

That was my point.


>> >However, due to the hopelessly inefficient module loading system, STiK 2.x
>> >fails to meet its requirements abysmally.
>> 
>> No, it is your ST system which is handicapped by missing bugfix patches.
>> Such are needed for various purposes on all TOS machines, since all have bugs.
>> eg: I must have FPATCH2 and HSMODEM installed on my Falcon to cure bugs.
>
>Pinhead is not a bugfix. The ST operates fine without it.

Not when it comes to loading programs quickly.  This is not unique to the
modules of STiK 2, but affects all program loading.  I consider that to be
a bug, and the program that eliminates it to be a bugfix patch.


>It merely replaces the inefficient Pexec routines with better ones.

Replacing inefficient or otherwise faulty routines is what a bugfix does.
I see nothing in this motivating the word "merely".


>It can hardly be compared with FPATCH2 or HSMODEM which are essential for
>correct operation of many programs.

AFAIK (not much really) FPATCH2 is a  collection of patches, making comparison
in detail meaningless.  HSMODEM is more specialized but has a wide variety of
features.  Its main bugfix effect is "merely" to replace the inefficient TOS
routines handling RTS/CTS handshaking.  I find this quite comparable.

The fact that programs loaded with extreme slowness can still function
correctly does not mean that such slow loading itself is correct.


>> >Requirements I hear you say? Well, I require STiK to give adequate
>> >performance on ordinary STs, not just on TTs and Falcons. I hope most of
>> >you would agree with me on this requirement.
>> 
>> Sure, but 'ordinary' is not the same as handicapped.
>
>I suggest that an 'ordinary' ST does not have Pinhead installed. You are
>assuming everyone would set up their ST identically to the way you would
>do it yourself. I'm trying to free STiK from such personal assumptions.

I suggest that without PINHEAD using TOS 1.0 is such a pain that people
will not endure it anyway.  That is my honest opinion.  I'm sorry you had
those problems with early PINHEAD versions, but I don't see why this need
affect your attitude to later improved versions.


>> >I would like to see an immediate improvement in this area, before it is
>> >marginalised to future optimizations.
>> 
>> This is a non-issue.
>
>I find the attitude exhibited here very disappointing. The issue has
>been marginalised as I feared.

This particular issue is only one small part of our debate, and I'm really
surprised that you consider it so important.  For those who insist on using
TOS 1.0 there is a cure for the slow loading.  I don't think your personal
bad experiences with early versions of PINHEAD invalidates that.

As for marginalisation, I have at least not ignored you, but tried to meet
your arguments with information I consider relevant.


>I have a system which can fix all of these problems. I'm suggesting that 
>modules are stored as standard executable files except each has a custom
>header. It is a very simple system, and fast on all systems.

You have hinted at this several times now, for a very long time.  Each time
(plus some times in between) I've asked for more information on it. But for
some reason you have not yet chosen to answer those questions.

In the meantime I have made some speculations myself and can imagine several
different hybrid solutions, but will not suggest any just for the sake of
having a hybrid.  There should be better reasons than that.

I am honestly interested in the system you mention, but you cannot possibly
expect me (or anyone) to be able to evaluate it with no more information
than what you've given above.

-------------------------------------------------------------------------
Regards:  Ronald Andersson                     mailto:dlanor@oden.se
                                               http://www.oden.se/~dlanor
-------------------------------------------------------------------------
