XBOOT III Problem auf TT mit hoher Auflösung

[Burkhard Mankel]

Burkhard, Du solltest inzwischen wissen, daß ich Warnungen nicht spekulativ ausspreche, sondern daß dahinter immer eine böse Erfahrung steckt! Ein einziger Schreibzugriff kann genügen!

Das Überschreiben einer (NEW)DESK(TOP).INF Datei ist sogar durch die Entwicklung des ST und seiner Nachfolger vorgesehen! Wenn bei einem solchen Vorgehen ein Fehler passiert, hat Deine Platte sicher andere Probs (zumindest auf der Bootpartition) gehabt!
Ich kann mir aber auch vorstellen, daß das häufige Überschreiben der gleichen Sektoren irgendwann dazu führt, daß solche auch mal "hops gehen" und das zur "Zerstörung der gesamten Partition" führt! Um nachhaltige grobe Schäden für mich zu vermeiden, habe ich immer nach gewisser Zeit den Inhalt des Bootdrives auf eine andere Partition kopierte, Drive C: dann komplett neu initialisierte und installierte!

Ganz im Gegenteil!

Doch - meistens braucht man für viele Arbeitsumgebungen einen vergleichbaren Inhalt des AUTO-Ordners; und Du höchstwahrscheinlich auch! Mehrfach das gleiche Programm auf verschiedenen "Ebenen" unter selben OS = Platzverschwendung, auch wenn der benötigte Platz verschwindend gering ausfällt!

[tuxie]

Eine Möglichkeit wäre das man eine Art Init Prozess baut wie es bei Magic gemacht wird. d.h. du hast die autoexec.bat wo die einzelnen Programme drin stehen. Dann hast du mehrere solcher Datein und je nachdem was du haben möchtest wählst du dann aus. Bei auswählen wird dann in der jeweiligen Reihenfolge die Programme in den Auto Ordner kopiert und das Bootprogramm wird beendet. Sollte wohl nicht ewig dauern das Kopieren. Wenn du nix ändern willst beim nächsten boot dann werden die Datein übernommen, ansonsten gelöscht und neu kopiert oder so ähnlich. Man kann auch vergleichen was schon exisitiert und was zu viel ist. Ich finde sowas auch übersichtlicher. Man könnte dazu auch extra Ordner machen oder so in der Art.

Autostart
------------->Automint
-------------------------->NVDI.PRG
-------------------------->mint030.prg
------------->Automagic
-------------------------->magx.prg (oder so ähnlich)


Beim Start wird das Verzeichnis Autostart geparst und man wählt dann aus was man haben möchte. Dann wird der Inhalt nach c:/AUTO kopiert und der Bootprozess läuft weiter.

"Nur eine Idee"

[1ST1]

Ob man jetzt die Sachen woanders her in den Autoordner kopiert, oder vorhandenes einfach nur umbenennt, ist doch fast Jacke wie Hose, oder? Nur Umbenennen geht einen Ticken schneller.

Und was die Angst vor Schreibzugriffen angeht: Sofern man kein anderes Set im Bootmanager auswählt, muss ja auch nichts geschrieben werden. Man kann sogar XBoot so einstellen, dass es im Normalfall garnicht erscheint. Das heißt, wenn man das Menü sehen will, muss man zum richtigen Zeitpunkt, wenn also gerade das stumme Xboot aus dem Autoordner gestartet wird, eine definierte Taste drücken. Erst dann kann man ein anderes Set auswählen.

Ansonsten bestünde ja noch die Möglichkeit, es wie unter MS-DOS zu machen: Von ATARI gibts ein command.prg, welcher auch eine autoexec.bat abarbeitet. Die legt man als erstes in den Auto-Ordner. Da schreibt man dann dann seine Befehle rein, die natürlich nicht direkt im Auto-Ordner liegen dürfen (sonst werden sie nochmal ausgeführt, es sei denn der letzte Befehl in der Batch ist mint.prg oder newdesk.prg, sofern man das hat). Diese Shell hat in etwa den selben Befehlsumfang wie MS-DOS 2.x oder 3.x command.com. Aber ganz ehrlich, wenn man erstmal kapiert hat, wie diese Bootmanager funktionieren, insbesondere XBoot, wird man feststellen, auf dem ATARI gehts nicht besser, und eine ganze Ecke komfortabler als eine s:startup-sequence oder eine s:user-startup oder autoexec.bat Textdatei zu füttern ist es auch.

Und im Notfall, wenn man jegliche Schreinzugriffe auf die Platte verhindern muss, bootet man eben - je nach Schweregrad - mit gedrückter CONTROL oder ALTERNATE Taste und tut dann das notwendige.

[tuxie]

Xboot läuft bei mir nicht und der Patch ist wohl für eine andere Version also ist xboot raus.. MCboot nun ja ist viel zu komplex und funktioniert irgendwie auch nicht wie es soll. Bisher habe ich Startup was das tut was es soll. Ob man da Sets anlegen kann, kann ich aktuell noch nicht sagen da ich mich da noch nicht mit beschäftigt habe. Und hier gehts auch nicht darum um das Umbenennen sondern wie @Nervengift   angemerkt hat wenn man alles im Auto Ordner hat dann wächst eine gewisse Unordnung und die Übersichtlichkeit schwindet. Daher kam mir die Idee mit den Verzeichnissen

[Nervengift]

@tuxies Idee mit den Verzeichnissen geht schon in die richtige Richtung, finde ich. Was vielleicht noch besser wäre, wäre wenn TOS selbst unterschiedliche Autoordner erkennen würde. Nicht nur einen. Also meinetwegen "AUTO", "AUTO1", "AUTO2" usw.. In den jeweiligen Ordnern könnte man dann die Programme und Treiber für das jeweilige OS reinlegen. Beim Booten müsste TOS dann nur nach diesen Ordnern kurz Ausschau halten. Erkennt es nur einen, wird dieser soft abgearbeitet. Erkennt es mehrere kommt ein Auswahlmenu welcher abgearbeitet werden soll. Das wäre wohl die eleganteste Lösung, denke ich. Dann muss auch nichts während des Bootens auf der Platte geschrieben werden. Der Haken an der Sache: Man müsste TOS selbst patchen. Aber vielleicht sollte man mal den Entwickler des EmuTOS diesen Vorschlag unterbreiten.  

[tuxie]

Naja ich glaube das bekommt man nicht hin aber mit soeiner ordnerstruktur wäre das möglich.  Neue konfiguration einfach einen neuen ordner anlegen und fertig

[1ST1]

TOS wird man nicht mehr verändern können, das ist so wie es ist. (Ausnahme: EmuTOS, aber das ist kein Standard).

Also wird man sich mit den Möglichkeiten begnügen müssen, die vorhanden sind: Bootmanager oder von verschiedenen Partitionen booten, so wie ari.tao es macht.

[Nervengift]

Ich benutze eine spez. Variante B+EXT.PRG von MCMD.PRG (aus einer früheren MAGIC-Distribution). Aber empfehlen würde ich Dir AUTOMORE von T.Binder!

@ari.tao: Nach "Automore" von Thomas Binder habe ich mal in der allwissenden Müllhalde gesucht und leider nichts gefunden. Weißt Du eine Bezugsquelle für das Programm?

[Burkhard Mankel]

Ich habe mal versucht, mich ein bischen über Xboot 3 schlau zu machen! Wenn ich das richtig verstehem, was in einem ST Computer Artikel über die SETs steht - ich zitiere ...:

Für die SETs gibt es eine Menge verschiedener Anwendungsmöglichkeiten. Naheliegend ist, sich für jede seiner Standardanwendungen ein SET zu erstellen, also zum Beispiel eins für die Arbeit mit der Textverarbeitung, eins für DTP, eins für das Grafikprogramm usw. Dabei bietet es sich natürlich an, für jedes dieser SETS in XBoot zusätzlich einen Autostart anzugeben, damit zum Beispiel bei der Auswahl des SETS Wordplus das Programm WORDPLUS.PRG nach dem Booten automatisch gestartet wird. Der automatische Start von GEM-Programmen funktioniert mit XBoot übrigens auch unter den alten TOS-Versionen 1.0 und 1.2.

Die SETs eignen sich jedoch auch für ganz andere Dinge. Anwender, die ihren ST sowohl mit dem SM 124 als auch mit einem Farbmonitor betreiben, kennen das Problem: Waren die Fenster- und Icon-Positionen auf dem Desktop in der monochromen Auflösung noch in Ordnung, so treiben in der mittleren oder niedrigen Auflösung "übereinandergestapelte" Icons und nicht oder kaum erreichbare Fenster den Anwender oft zur Weißglut. Ähnliche Sorgen plagen auch die Besitzer von Großbildschirmen. Mit den Infodateien in XBoot bekommt man solche Ärgernisse sicher und schnell in den Griff. Dazu wird lediglich für jede der Bildschirmauflösungen ein eigenes Desktop erstellt und mit Arbeit sichern abgespeichert. Nach dem Abspeichern muß die entstandene Datei DESKTOP.INF noch umbenannt werden, damit sie nicht beim nächsten Speichern überschrieben wird. Am besten gibt man den auflösungsabhängigen DESKTOP.INF-Dateien Namen wie DESK HI.INF (hohe Auflösung), DESK MED.INF (mittlere Auflösung) und DESK LOW.INF (niedrige Auflösung). Nach diesen jede der Auflösungen ein eigenes SET erstellt werden, für das man die zugehörige alternative DESKTOP.INF-Datei bestimmt. So arbeitet man immer auf einem aufgeräumten Desktop.

Natürlich kann man neben den "Standard"-Desktops auch für jede Anwendung ein individuelles Desktop benutzen. Wie wäre es zum Beispiel, wenn bei der Auswahl des SETs Wordplus auf dem Desktop sofort die Fenster mit den Ordnern geöffnet würden, in denen sich Wordplus und die gespeicherten Textdokumente befinden? Dazu verfährt man genauso wie oben beschrieben und nennt die neue DESKTOP.INF-Datei einfach DESKWORD.INF. Nun muß diese Datei nur noch beim nächsten Systemstart in das SET Wordplus übernommen werden.

... dann muß ich sagen: "Das - oder ähnliches - kann Startup auch!" Ich möchte mir eine Arbeitsumgebung für TeX anlegen;
- Wahl der be(treffend/nötigt)en automatisch zu startenden PRGs im AUTO-Ordner
- Speichern der Wahl - ich glaube mit einer Tastenkombi in Verbindung mit der Taste <S> (es wird eine Eingabezeile geöffnet, in der man bis zu 8 Zeichen - hier sinnvoller Weise "TeX" - eingeben kann)
- Nach Bestätigung wird im Root eine Detei nmit dieser Zeichenkette und dem Zusatz "*.STP" (hier also "TEX.STP") angelegt
- Im Desktop wird der passende D...p angelegt (zB. ein Fenster für TeX und eins für MetaFont) und mit "Arbeit sichern" abgespeichert.
- Die abgelegte DESKTOP.INF (bzw. NEWDESK.INF) wird nun in TEX.STD umbenannt
Wenn man in Zukunft unter TeX arbeiten will, wählt man den entsprechenden Desktop-Eintrag und hat gleich die betreffenden Auto-Programme an- und abgewählt!

Ich finde das sogar bei Startup einfacher zu handhaben als bei dem Beitrag über Xboot beschrieben!

[1ST1]

XBoot lässt sich mit der Maus bedienen. Innerhalb XBoot kann man die Startreihenfolge im Autoordner, bei ACCs und CPXen ändern. Im übrigen kann XBoot auch CPXe verwalten. XBoot kann auch die Assign.sys für GDOS/NVDI verwalten, und man kann eine weitere Datei verwalten, egal welche, kann man aussuchen. Und noch einiges mehr.

[kcr]

Xboot III bombt bei mir auch zu 50:50 oder gar 60:40 am TT. Habe nicht gezählt, aber sind schon mehr als vier Bomben, vielleicht 10 oder so. Bombt er, so wird die zuletzt gewählte Konfiguration geladen und man kann normal arbeiten. Ist nur etwas lästig, wenn man etwas ändern will. Muß dann mehrmals neu starten...

Keine Ahnung woran das liegt, schent ein Bug im Programm zu sein. Passiert bei mir auch nur am TT. Egal ob Kalt- oder Warmstart.

[Burkhard Mankel]

XBoot lässt sich mit der Maus bedienen.

Benötige ich nicht!

Innerhalb XBoot kann man die Startreihenfolge im Autoordner... ändern.

Wozu sollte das gut sein, wenn man doch weiß, daß der ST gerne Bombenhagel losläßt, wenn PRG Z vor PRG A gestartet wird!

Innerhalb XBoot kann man die Startreihenfolge ... bei ACCs ... ändern.

Da verschließt sich mir völlig der Sinn - ich kenne kein ACC, bei dem es wichtig wäre, vor einem Anderen gestartet zu werden!

Innerhalb XBoot kann man die Startreihenfolge ... bei ... CPXen ändern.

dto.

Im übrigen kann XBoot auch CPXe verwalten.

XControll adé?

Und was das Übrige betrifft: mit GDOS und NVDI befasse ich mich erst seit kurzem (eigentlich bislang noch gar nicht, da mein Mega ST4+ noch nicht für den Dauereinsatz bereit ist und ich mich bislang um andere wichtige Familienangelegenheiten kümmern mußte, die wichtiger sind als mein Hobby) - also noch keinerlei Erfarung und darum auch kein Grund umzusteigen!

Nein - dadurch kannst Du mich auch nicht bekehren!

[1ST1]

XBoot lässt sich mit der Maus bedienen.

Benötige ich nicht!

Möchte ich nicht mehr missen. Tastaturbedienung geht natürlich auch. Ist so halt flexibler.

Innerhalb XBoot kann man die Startreihenfolge im Autoordner... ändern.

Wozu sollte das gut sein, wenn man doch weiß, daß der ST gerne Bombenhagel losläßt, wenn PRG Z vor PRG A gestartet wird!

Ja, genau dafür. Du weißt sicher wie aufwändig das sonst ist. In XBoot verschiebe ich das Programm einfach dahin wo ich es haben will.

Innerhalb XBoot kann man die Startreihenfolge ... bei ACCs ... ändern.

Da verschließt sich mir völlig der Sinn - ich kenne kein ACC, bei dem es wichtig wäre, vor einem Anderen gestartet zu werden!

Z.B. damit man im ACC-Menü eine bestimmte Reihenfolge hat.

Innerhalb XBoot kann man die Startreihenfolge ... bei ... CPXen ändern.

dto.

Die wichtigsten CPXe oben, die unwichtigen unten.

Im übrigen kann XBoot auch CPXe verwalten.

XControll adé?

Wenn ich kein MiNT boote, brauche ich auch kein Mint.cpx. Wenn ich keinen NVDI boote, brauche ich auch kein NVDI.CPX, ... Kann ich also schön an meine Startkonfig anpassen.

Und was das Übrige betrifft: mit GDOS und NVDI befasse ich mich erst seit kurzem (eigentlich bislang noch gar nicht, da mein Mega ST4+ noch nicht für den Dauereinsatz bereit ist und ich mich bislang um andere wichtige Familienangelegenheiten kümmern mußte, die wichtiger sind als mein Hobby) - also noch keinerlei Erfarung und darum auch kein Grund umzusteigen!

Nein - dadurch kannst Du mich auch nicht bekehren!

Ich will niemanden bekehren. Dich schon garnicht. Denn gegen (Irr)Glauben ist kein Kraut gewachsen. Ich kann nur (duch sachliche Argumente) überzeugen. Das ist ein riesen Unterschied.

[ari.tao]

... wie es bei Magic gemacht wird. 

Ja tuxie, geht mit einem sep. CLI/BATcher auch mit MiNT und anderswo, nicht bloß genauso, sondern sogar besser! Und dann kann man den auch für Magic benutzen und ist nicht mehr auf das in Magic eingebaute, sehr primitive Ding angewiesen!

... die Programme in den Auto Ordner kopiert ... 

Nein, die *Programme* müssen gar nicht kopiert werden. Die werden einfach von da gestartet, wo sie liegen - irgendwo auf der Platte! MaW.: Bis auf wohlbegründete Ausnahmen (siehe mein ScreenShot) ist der CLI das einzige ausführbare Prg. im \AUTO\. Das restliche Volk im \AUTO\ besteht aus Konfigurations-Dateien und .BATs!

Umbenennen geht einen Ticken schneller. 

Noch einen Tick schneller geht ´drüberbügeln´ (ie. der .BAT- & Konfig.-Dateien).

... zum richtigen Zeitpunkt ... Taste drücken ... 

Bitte nicht niesen! Und hoffentlich kommt keine BusyBee dazwischen! 
Was meine Warnung vor Schreibzugriffen _aus_dem_\AUTO\_ angeht, so betrifft es diejenigen, die so wie ich abwechselnd MAGX und MiNT nutzen. Das in MAGX_6.21 eingebaute FAT32 hat anscheinend einen üblen Bug, der es imho nötig macht, solche Partitionen mit Schreibschutz zu versehen. Ich erinnere daran, daß auch Umbenennungen bereits einen Schreibzugriff bedeuten!

Von ATARI gibts ein command.prg ... 

Geht vielleicht auch, habe ich nicht ausprobiert. So komfortabel wie der MCMD sind nur wenige CLIs.

...  es sei denn der letzte Befehl in der Batch ist mint.prg oder newdesk.prg ... 

oder SET_ENV.PRG oder AUT?X.PRG oder ....

...eine ganze Ecke komfortabler ... 

Obwohl ich mich nie mit MSDOS abplagen mußte und trotz meiner heißen Vorliebe für GUIs bevorzuge ich im \AUTO\ einen CLI  ! Ich würde tuxie und Nervengift dies und Burkha rd einen BootSetter empfehlen  !

  ... jegliche Schreinzugriffe ... 

Wer seinen Schrein liebt, der hat min. zwei Backup-Platten (& nicht bloß eine Partition wie unser leichtsinniger B.!).

... Übersichtlichkeit  ... 

Ja !!! Das ist das wichtigste aller Kriterien!

Also meinetwegen "AUTO", "AUTO1", "AUTO2" usw.. 

Wie wär´s mit A:\AUTO, B:\AUTO, C:\AUTO usw.?

Ich benutze eine spez. Variante B+EXT.PRG von MCMD.PRG (aus einer früheren MAGIC-Distribution). Aber empfehlen würde ich Dir AUTOMORE von T.Binder!

@ari.tao: Nach "Automore" von Thomas Binder habe ich mal in der allwissenden Müllhalde gesucht und leider nichts gefunden. Weißt Du eine Bezugsquelle für das Programm?

Allwissende Müllhalde? lol ! Weiß nicht mehr @Nervengift , woher ich´s habe, aber schau mal in den Anhang. Ist ja Freeware.

Xboot III bombt bei mir ... 

Siehe auch Posting #34.
-------

Ich hänge noch drei Textdateien an.
1) !A_POOL.LEA enthält eine Sammlung von Regeln für \AUTO\-Prge.
2) !AUTO.LEA enthält kurze Infos zu \AUTO\-Prgen., die ich selbst nutze.
3) BOOT.LOG ist ein durch MAGX erzeugtes LogFile aus meiner Praxis.
Während die letzteren beiden nur als Bspe. zur Veranschaulichung  gut sind  (da sie meine pers. Umstände betreffen), ist das erste von allgemeinem Interesse. Ich rufe Euch dazu auf, mir Vorschläge zur Ergänzung zukommen zu lassen (am besten hier posten, oder auch PM an mich).

[Burkhard Mankel]

Möchte ich nicht mehr missen. Tastaturbedienung geht natürlich auch. Ist so halt flexibler.

Cursortasten und <TAB> (bzw. <A> - zum Wechsel zwischen PRG und ACC) - mehr brauche ich auch idR nicht!

Ja, genau dafür. Du weißt sicher wie aufwändig das sonst ist. In XBoot verschiebe ich das Programm einfach dahin wo ich es haben will.

Einmal einrichten - und wenn neue PRG dazukommen und die Stelle weiß, wo es am Besten zu starten wäre physikalisch per Hand neu sortieren reicht doch wohl völlig!

Z.B. damit man im ACC-Menü eine bestimmte Reihenfolge hat.

Pustekuchen! Ich habe experimentiert, um eine bestimmte Reihenfolge der ACC in den Slots unterm DESK-Menü zu erhalten, funzt net! Egal in welcher Reihenfolge ich die ACCs physikalisch laden lasse, sie erhalten bei mir immer den gleichen Slot!

Die wichtigsten CPXe oben, die unwichtigen unten.

Mir nicht wichtig - alle CPX, die ich in XControl aktiviert habe, sind mir "wichtig" und die unwichtigen sind deaktiviert!

Wenn ich kein MiNT boote, brauche ich auch kein Mint.cpx. Wenn ich keinen NVDI boote, brauche ich auch kein NVDI.CPX, ... Kann ich also schön an meine Startkonfig anpassen.

Kann man auch erreichen, wenn man für ein Nachlade-OS eine eigene CPX-Verwaltung nutzt ...!
Und was den "(Irr)Glauben" betrifft ...

Wie wär´s mit A:\AUTO, B:\AUTO, C:\AUTO usw.?

Willst Du allen Ernstes bei Plattennutzung AUTO-Ordner von Disklaufwerken nutzen? 

[Arthur]

Hab gerade mal das hyp zu AutoMore überflogen und die Möglichkeiten sind wirklich vielfältig und praxisgerecht. Die Argumente von Burkhard hören sich für mich nach Polemik an. 

[Lukas Frank]

Hatte wie gesagt bei mir auf diversen TTs nie Probleme. Versucht doch mal z.B. mit QED die SET Datei zu leeren oder vielleicht mal mein SET nutzen ...

[tuxie]

Ich muß hier mal ne Bremse rein werfen......

Jeder hat einen anderen Geschmack und jeder hat eine andere Art Ordnung auf seinem Rechner zu halten. Daher gibt es für jeden auch verschiedene Ansätze wie etwas gehandhabt wird. Ich z.b. möchte es simpel und einfach haben. Mausbedienung brauch ich nicht. 1st1 steht darauf das es mit Maus zu bedienen ist und ein anderer sieht es auch wieder anders. Daher belassen wir es bitte bei dem wie es jetzt ist, sonst ist dies auch wieder einer der Threads wo man sich Streitet um Kaiseres Bart..

@ari.tao Die Idee mit einem Prozess der alle einzelnen Programme Lädt hatte ich auch, ich weiß nur nicht in wie weit das Machbar ist, oder vielleicht schon gemacht wurde?

[Nervengift]

Nein, die *Programme* müssen gar nicht kopiert werden. Die werden einfach von da gestartet, wo sie liegen - irgendwo auf der Platte! MaW.: Bis auf wohlbegründete Ausnahmen (siehe mein ScreenShot) ist der CLI das einzige ausführbare Prg. im \AUTO\. Das restliche Volk im \AUTO\ besteht aus Konfigurations-Dateien und .BATs!

@ari.tao: Mich hat jemand verstanden!!! Genauso will ich's im Grunde auch handhaben, um dann ganz bequem per Menüauswahl TOS, MiNT oder Magic zu starten.

Nochmal vielen Dank für die Dateien und "Automore". Ich werde mir das die Tage mal ansehen und gucken, was ich damit so auf meinem Milan anstellen kann.

Jeder hat einen anderen Geschmack und jeder hat eine andere Art Ordnung auf seinem Rechner zu halten. Daher gibt es für jeden auch verschiedene Ansätze wie etwas gehandhabt wird.

Stimmt genau und ich denke, Glaubenskriege gehören ins Mittelalter und nicht ins Computerzeitalter, denn Computer ermöglichen einem Dinge so zu machen wie sie einem gefallen und das soll jeder in der Hinsicht machen wie's ihm gefällt. Alles klar?

[ari.tao]

Die Idee mit einem Prozess der alle einzelnen Programme Lädt hatte ich auch, ich weiß nur nicht in wie weit das Machbar ist, oder vielleicht schon gemacht wurde?

Wie soll ich die Frage verstehen? Ist das eine rethorische Frage? Du mit Deinen 5k Postings hier im Forum kannst doch unmöglich die Antwort nicht wissen  ! Aber ich beantworte sie trotzdem mal:
Jede Shell macht das. Der Desktop ist eine grf. Shell, CLIs sind Shells auf Text-Basis. Zur BootZeit ist Im \AUTO\ bekanntlich GEM noch nicht aktiv, deshalb sind dort CLIs angesagt. Will man in dieser Phase doch ein GUI haben, so muß man die Initlg. zumindest des VDI selber machen, ie. eine ´PhysWorkStation´ öffnen, etc. Manche BootSelektoren machen das (und bieten dann MausKomfort), sind jedoch _keine_ Shells (dh. können keine Prge. nachstarten). Ein ´Desktop für´s \AUTO\´ wäre schlicht ein unverhältnismäßig großer Aufwand.
Ich erinnere daran, daß es außer \AUTO\ und ACCs noch viele weitere Möglichkeiten gibt, Prge. zu Beginn einer Comp.Session automatisch zu starten: Der BootStrap (lädt zB. den HD-Treiber), die #Z-Zeile in (NEW)DESK(TOP).INF, die .CNFs von MiNT, GEM, NAES, GENEVA &c.,  START\ & APPS\ von MAGX & NAES, usw. Dabei gilt: Prge., die GEM brauchen, dürfen nicht in´s \AUTO\´, aber Prge., die _kein_ GEM brauchen, müssen nicht in jedem Falle in´s \AUTO\. Es kommt ganz auf den spez. Zweck an, an welcher Stelle und wie eingereiht ein Prg. stehen muß/darf.
Schließlich gibt es noch (aber _nicht_ im \AUTO\!) sog. LinkLoader (zB. für LPR-M2 & SPC-M2) und interaktive Prg.-Systeme wie zB. SmallTalk....
-------

Edit (10:25h): Nach Gagas Einwand (Posting #61) drei überflüssige Zitate & Antworten gelöscht
Humor ist, wenn man trotzdem lacht.