
berlegungen zum Paths-Modul, HomePath und Programm-Environment
---------------------------------------------------------------

Jedes gelinkte Programm hat eine eigene Umgebung:
  - HomePath mit dazu relativ gelegenen Zusatzdateien
  - Stacksize
  - Treibermodule, z.B. Error-Handler & IO-Treiber, auch Treiber, der
    lediglich auf Taste am Ende wartet & Real-Treiber

Genau diese Umgebung mu auch bei Modulen, die unter der Shell gestartet
werden, geschaffen werden.

Zur Definition des Umgebungsfelds werden die MSP-Dateien verwendet.
Sie bestimmen dann:
  - Main-Module
  - HomePath des Main
  - Stacksize
  - Treiber-Module, bzw. Konfiguration, die sonst die Treiber erzeugen
    (z.B. I/O-Modus: GEM oder TOS)
  - Ggf. globale Compileroptions, z.B. f. Range-Check, Debugging, usw.

Es soll mglich sein, hierzu spezifische Impl-Module von den allg. Modulen
zu trennen. Die spezifischen Module drften z.B. in ein anderes Dir
(alle ins selbe) als die allg. Code geschrieben werden. Dies mte anhand
der Vorkommen der Sourcen in verschiedenen Dirs erkennbar sein.
Z.B. knnte man im Umgebungsfeld Source-Dirs definieren, die speziell zu
dem Projekt gehren.

Die Frage stellt sich dann, was mit anderen Modulen geschehen soll, die
unter dieser Umgebung gestartet werden.
  - Zum Teil sind die Utilities, bei denen das egal ist: Compiler, Editor,
    PathEdit, usw
  - Das projektbezogene Modul sollte nur ber eine spezielle Funktion
    ausfhrbar sein - so kan die Shell diesen Start von anderen Modulen
    unterscheiden. Bei den anderen Modulen sollte dann ggf. eine Std-
    Umgebung einstellbar sein, z.B:
      - Flag: Akt. Dir erhalten oder auf Origin-Pfad vom Prg setzen
      - Stacksize

Noch besser wre es, wenn von vornherein jedes startbare Modul eine
extra Umgebung erhalten kann, wie gelinkte Programme. Dann knnte
umgekehrt auch der Linker daraus die erforderlichen Daten (Stack,
Treiber, usw) ermitteln.

Die Frage ist nur, wie diese Umgebung zu finden ist.
- Entweder ist std-mig zu jedem ausfhrbaren Code optional ein
  Environment-File erstellbar, das dann z.B. von der Shell gesucht
  wird (abhngig vom Dateinamen mit anderer Endung, z.B. "ENV" o. "M2E"),
  ggf. knnte auch dessen Name im Code abgelegt werden.
- Oder im Code wird direkt die Infomation mit abgelegt. dann mte sie
  schon beim compilieren bestimmt werden, z.b. ber optionen in der shell.
  dies ist aber wohl zu aufwendig und unflexibel.
Ist keine Umgebungsinfo vorhanden, wird eine default-einstellung (wie bisher)
verwendet.
Nach diesem Konzept mte dann aber das bisherige mit den MSP-Dateien (f.
Projekte) gendert werden, denn bei den MSP wird ja ein Teil des Env. schon
global definiert, eher mte dort die spezielle Env-Datei des Main-files
eingestellt werden oder ber dialoge erstellt werden.


EOT
