shel_write erfllt ZWEI Zwecke:

1. Man teilt damit einem daraufhin irgendwie gestarteten Programm
  seinen Namen/Pfad sowie die Argumentzeile mit. Das gestartete
  GEM-Programm erfhrt diese Daten durch Aufruf von shel_read().

2. Ein Programm kann ein "Chaining" durchfhren. D.h, es kann
  erreichen, da es selbst terminiert und daraufhin ein anderes
  Programm starten lt.
  Demgegenber kann ein Programm ber "Pexec()" auch jederzeit
  ein anderes Programm als "Unterroutine" starten.
  Whrend beim Chaining dem nachgestarteten Programm wieder aller
  Speicher zur Verfgung steht, ist beim "Unterprogrammaufruf"
  der Speicher knapper, weil ja das startende Prg im Speicher verbleibt.

  Signum startet beispielsweise den Druckertreiber ber diesen
  Chaining-Mechanismus: Dazu ruft Signum "shel_write()" mit dem
  Namen des Druckprogramms als Prgnamen und des bearbeiteten Textes
  als Arg-Zeile auf und terminiert daraufhin. Wurde Signum vom
  Desktop aus gestartet, erkennt dieser nun, da Signum shel_write()
  gerufen hatte und startet nun automatisch das gewnschte Programm.
  Will das Druckprogramm wieder die Kontrolle zurck an Signum geben,
  mu es dies wiederum auf die selbe Weise ber shel_write tun.

  Wird Signum aber beispielsweise von einer anderen Shell aus
  gestartet, mu diese die Funktion des Desktops bernehmen, d.h,
  erkennen, da das vorige Programm "shel_write" rief und entsprechend
  reagieren (Pexec() aufrufen). Das Problem dabei ist aber, da
  dazu leider eine Information fehlt: Wird shel_write gerufen, werden
  nicht nur Progname und Argzeile gemerkt, sondern auch ein Flag
  gesetzt, da den Aufruf anzeigt (seit TOS 1.4 kann dieses Flag
  brigens auch wieder gelscht werden). Der Desktop prft dieses
  Flag, um zu erkennen, da ein shel_write-Aufruf erfolgt war.
  Dann setzt es das Flag zrck und startet das gewnschte Programm.
  Eine andere Shell kann aber dieses Flag nicht abfragen. Stattdessen
  mu es ein anderes Verfahren anwenden: Es geht davon aus, da
  ein Programm niemals sich selbst per Chaining nachstarten wird
  (ist ja wohl sinnlos). Also prft es nach der Rckkehr eines
  gestarteten Programms mit shel_read(), ob noch der selbe PrgName
  wie vor dem Start bestimmt ist. In diesem Fall hat das Prg
  offenbar keinen shel_write-Aufruf durchgefhrt.

  Nur wenige Shells tun auch dieses "Chaining" bercksichtigen, so
  z.B. GEMINI. Neodesk versucht das auch, aber mit einem ganz
  anderen Verfahren (es hngt sich in den AES-TRAP-Vektor und
  setzt sich selbst ein Flag, wenn shel_write gerufen wird) und
  dies geht dann auch bei einigen Dingen in die Hose, so z.B.
  bei der Megamax-Shell, die die seit TOS 1.4 verfgbare Mglichkeit
  des Rcksetzen des internen Flag benutzt, Neodesk das aber noch
  nicht bercksichtigt.

  Ach ja, daraus folgt auch: Wenn ein Programm/Shell ein anderes mit
  Pexec als Unterprg. startet, und es vorher ordnungsgem Prgname/Argzeile
  per shel_write mitteilt, mu es hinterher nicht nur das Flag
  zurcksetzen, damit der Desktop das Programm bei Ende des Shell
  nicht nochmal startet, sondern man mu auch den eigenen Namen
  wieder einsetzen, damit Programme wie GEMINI nicht das Prg nochmal
  starten.

  Und dann gibt's da ja noch die anderen Problemchen, z.B. das Schlieen
  der eventuell offenen ACC-Fenster. Ganz schn aufwendig, das Ganze, nicht?
  Wer mehr wissen will, soll sich das MM2 zulegen - das kann er im
  mitgelieferten Source der Shell alles abgucken :-)

Claus, ist damit Deine Frage beantwortet?

Wird wohl mal wieder Zeit fr einen Artikel, wie?

TT
