Re: STiNG, CAB, and Multitasking (strikes back) (fwd)

[hyc@troy.la.platsol.com (Howard Chu)]

  On Wed, 11 Mar 1998, Konrad Kokoszkiewicz wrote:

  > The question isn't whether or not MiNT uses XBRA - it does. We already

  So far, it has only been stated that MiNT provides XBRA headers, that's
  hardly "using" XBRA. "Using" it would mean to exploit XBRA's benefits.

There is no benefit here. XBRA allows you to chain to another handler when
your own handler doesn't want to take care of the current call. The MiNT
priv violation handler will never pass that event down the chain, simply
because it is designed to handle every occurrence of that event.

  > know that. The question is, what parts of the system are appropriate for
  > third-party software to be changing? The privilege-violation vector is
  > unquestionably the property of the operating system, and not an application
 .

  This is the Unix point of view. Under Unix this is true. However, TOS is
  not Unix, and despite your (impressive - I'm not turning it down in any
  way) efforts, TOS plus MiNT isn't Unix either. You've done a great job
  of getting closer to it, but it's not possible to get there, given the
  wealth of existing software that *uses* exception handlers all over the
  place.

There's a difference between exception handlers in general, and the priv
violation handler. Specifically, it is the operating system's job to control
who can and cannot get into Supervisor mode.

  Such hardlinership is seriously threatening general compatibility of MiNT,
  and this cannot do the small Atari world any good. Maybe it's merely
  because some people cannot accept that MiNT is *not* the whole Atari
  world. STinG has *not* been written *for* MiNT. STinG has been written
  such that any system extension that does things in a sensible manner
  will work with it. Unlinking exception handlers is not sensible behaviour.
  A software installs an exception handler for a very good reason. By
  unlinking it, MiNT cripples it. You can say the software is not appro-
  priate for MiNT, but that won't help the user who wants to run both, but
  can't, because of some hardliners, that insist on something "belonging" to
  the system exclusively, which is in no way historically (nor by Atari) 
  justified. Remember, it's not Unix.

  I wonder if you'd change your mind once some important (for you) piece of
  software is affected. Maybe NVDI. The Behnes are good friends of Andreas
  Kromke (MagiC). If they'd decide to use an exception handler that in some
  similar way doesn't work with MiNT, they won't care, since Andreas' MagiC
  does not cause trouble here, neither does any single-TOS. MiNT does not
  play such a big role in Germany, which is the main market for the Behnes.

The fact is, MiNT *does not* unlink any handlers. It *does* use XBRA to
install its own handlers. If this were not true, then no TSR loaded before
MiNT would *ever* work. In fact, NVDI & HSMODEM *do* work, loaded before
MiNT. The problem here is you have a special case handler, that will never
be invoked because MiNT's general case handler will never recognize your
special case. Turning this around - does your privilege violation handler
look specifically for STiNG as the reason it was invoked? And if it discovers
that STiNG was not the reason it was invoked, does it fall through to the
next handler in the chain?

  > TOS already provides several legal, documented calls for getting in and out
  > of Supervisor mode. As such, STiNG's method can only be viewed as a dirty
  > hack. Konrad has also already shown that STiNG's method is slower than a
  > more legitimate approach, in CPU cycles.

  He's shown nothing. I haven't given you the information based on which
  anything could be deduced here. So how could anybody have shown anything ?
  STinG's problem at that position is that it works from an interrupt. So 
  any call to GEMDOS is entirely out of question. The code does not know
  if it was called in Super mode or not, but it's the former case (Super
  mode) when the "transition" must be particularly fast. It had not been a
  problem if Motorola had not made reading the CPU status system byte a
  priviledged instruction.

OK, you're right, something makes no sense here and you haven't given
enough information. If you are in an interrupt handler, then you should
already be in supervisor mode. (But obviously you're not, or else you
wouldn't trip the exception vector.) Also, Supexec is an XBIOS call, and
*is* safe to call from an interrupt. Since you probably know all this already,
but you're still doing something odd, I would like to know more about what
exactly you're doing.

  > So, you have a dirty hack that not
  > only causes problems, but also wastes CPU time.

  The latter is wrong, as I just explained. The former, well, sure it's so
  easy to blame compatibility problems to the other program, saying it uses
  dirty hacks :-( Fact is this method does not violate any specification or
  guideline by Atari. Fact is this method works with all versions of single-
  TOS, all versions of MagiC, MagiCMac on Macintosh, MagiC-PC on PC, AFAIK
  all other emulators on both Mac and PCs. Fact is, a programming practice
  does not become illegal just because you do not like it ! Atari never has
  forbidden linking handlers into exception vectors, after all there is a
  BIOS call to simplify (encourage) it !

Sure, and I can install my own exception handlers for Trap 1, 14, etc.,
with all my own custom code for everything, but then I wouldn't be running
TOS any more, I'd be running *a different OS*.

  Another point : STinG is an OS extension just like MiNT is. So STinG has
  every right, even by your own (questionable) point of view, to use 
  exception handlers.

There's a difference between an exception handler for a Trap, which is
explicitly a software-generated function call, and a handler for an
interrupt, or for a processor error condition. Bus error, address error,
privilege violation - these are all extremely abnormal situations, and
they all indicate a serious fault in the executing code. Relying on these
mechanisms for the normal operation of your code is poor programming practice,
no matter what machine or OS you're programming for. And yes, obviously
a virtual memory handler uses bus error. But this condition is so sensitive
that a second consecutive bus error halts the CPU. This is not an area you
mess with casually.

  > so far in this discussion shows only that MiNT observes all accepted Atari
  > programming standards, and that STiNG is broken. Can we please move on now?

  I consider it precisely the other way round. MiNT chops of other program's
  exception handlers, which is a very questionable thing to do. I cannot see
  which standard I'd broken by installing an exception handler.

  I do not see how we could come to any sensible conclusion, at least as
  long as hardliners dominate the discussion. So it seems there is only one
  thing I can do : Bow out here, and call MiNT broken by standards set by
  Atari whenever anybody complains that STinG run before MiNT does not work.

MiNT has existed since 1989, and this is the first time anyone has encountered
this problem. If MiNT were so incompatible with Atari standards, there should
be a lot more software out there crashing because of it.

As for dominating the discussion - I've been totally quiet until now, I can
hardly see how I've dominated the discussion. I apologize if my tone has been
unfriendly, but I have yet to see anything that indicates anything other than
a poor programming approach in STiNG.
  -- Howard