Some important notes on specific crashes and crashing conditions
 ================================================================

 Hard/Software Conflicts
 ~~~~~~~~~~~~~~~~~~~~~~~

 IDE-MaxTransfer Problem
 -----------------------
 Since superview.library usually holds very large buffers within
 memory, it also likes to read and write these completely from and to
 disk. This means, that the specific device drivers are confronted with
 quite large values of bytes to be read or written, which perhaps
 usually does not happen very often.

 Sometimes the firmware of IDE-Harddrives, like used with the
 A4000/030-040 or A1200HD, does not support transfers of blocks
 larger than 64K (65535 Bytes) during one single write operation.
 Ususally the DOS splits larger writing calls to take care of this
 restriction. But since this is just a lack of performance and actually
 does not comply to the IDE/AT standard, the default value for
 this "MaxTransfer" is not 0xFFFF (64K) but 0xFFFFFF or 0xFFFFFFFF instead.

 If any written graphics files are mysteriously damaged or will be
 read incorrectly (writing is more critical than reading), you should
 start your "HDToolBox" and select "Partition Drive" for the concerned
 HardDrive. After that activate "Advanced Options" and chose "Change".
 Modify the "MaxTransfer" field, so that it does reflect "0xFFFF" then.
 After that leave all the windows by confirming "OK" and select
 "Save Changes to Drive" (no longer disabled) on the first window.

 >>> Do not change any other settings within "Partition Drive", if
     you don't know, what you're doing, since actually partitioning
     your HardDisk would cause your complete data to be lost.
     If you'd changed something you didn't want to change, just
     "Cancel" and start from the beginning <<<

 Perhaps you'd like to know, why I did mention this here ?!
 Well, some weeks after I bought a new M*xt*r 540 MB HD,
 superview.library did seem to have x-time more bugs than before, which
 almost all could not be explained rationally: writing a "clean"
 buffer to disk in several file formats (did not matter), with this
 buffer still beeing valid after the write operation, resulted in
 damaged graphics after loading. If uncompressed, the data still was
 all there, but like a kind of mosaic, with always some blocks at the
 wrong places...
 It took me some weeks to actually realize the bug itself and
 approximately two days to find out, *why* it happened... %-(


 Crashes caused by other Programs
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 Here's an alphabetical list of programs, which either cause
 superview.library to crash, or which do crash relatively
 often and unexpected (so that it might seem, as if superview.library
 crashed):

    - AutoCLI V2.xx © by Nic Wilson

      Problem:
      AutoCLI sometimes might crash, when there's no appropriate
      window available when e.g. trying to open a shell via Hotkey.

      Solution:
      (don't use the hotkey feature)

    - EGS libraries V6.x/7.x © VIONA Development

      Problem:
      When flushing the EGS libraries (at least after using the Amiga
      emulation mode), it seems that the libraries will cause recoverable
      alerts with OS 3.x. Maybe on some systems crashes will occur.
      Don't know, whether the libraries are really the source,
      but it's likely.

      Solution:
      (don't flush)

    - NewMode V3.3 (and below) © 1992-95 by Andreas Linnemann

      Problem:
      Has been reported to cause serious problems when running together
      with e.g. SuperView (when attaching a fixed ViewMode to the program).

      Solution:
      (Already fixed for newer versions.)

    - SnoopDos 3.00 © Eddy Carrol, September 1994

      Problem:
      When monitoring OpenLibrary() calls with SnoopDos 3.0,
      while loading the libraries into RAM, ramlib will _sure_
      crash with an "...3 odd address" guru when loading one of
      the SVObjects.
      This does not happen when the libraries have already been
      loaded into RAM before and does also not happen with older
      SnoopDos releases.
      Can't say, whether this is a problem of SnoopDos, ramlib
      or the library, but maybe it has s.th. to do with trashed A0/A1.

      Solution:
      Deactivate "OpenLibrary" under "Functions" and save the preferences.
      You will still be able to see, which libraries are loaded (LoadSeg),
      but can't detect any version numbers (use an older SnoopDos for this).

    - SuperDark 1.5c,V2.1a © by Thomas Landspurg

      Problem:
      Some of the Screen Blanker modules will crash on AGA OS3.x systems.

      Solution:
      Find out, which of them do so (e.g. ASwarm, as far as I know) and
      deactivate them !

    - VMM

      Problem:
      Someone told me, that VMM caused SuperView(-Library) crashing
      because of Enforcer Hits, which did not happen without it.
      May be a bug of VMM or the library.

      Solution:
      (if it does not work, don't use it with SuperView)


 Conditional Configuration Crashes (CCC ;-)
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 Some very special configurations (which occur when people do configure
 their programs wrong, or installation programs do weird things) may
 cause the whole system to crash.




 If you know more about such crashing conditions, please report it to me.

 - Andy, 30.7.95