Diskussion:TaskMAX

Erstellung als eigenen Artikel

Hinweis: Diese Diskussion wurde aus der Benutzerdiskussion von Y2kbug hier her verschoben.

Hallo, ich wollte dir sagen, dass TaskMAX aus DR-DOS 6.0 eigentlich in einen eigenständigen Artikel gehört und nicht zu ViewMAX. Da TaskMAX komplett unabhängig von ViewMAX direkt aus der Kommandozeile ohne ViewMAX verwendet werden kann. Das ist praktisch ein eigenständiges Programm, das aber auch zusätzlich von ViewMAX aus konfiguriert werden kann, aber ViewMAX ist für die Verwendung von TaskMAX nicht erforderlich. Als IP ist es schwer, eigenständige Artikel zu erstellen. Deswegen habe ich den Absatz gestern in den ViewMAX Artikel eingebaut. Aber eigentlich gehört das getrennt. TaskMAX ist ein TSR Programm mit einer kleinen reinen Zeichenorientierte Benutzerschnittstelle die über die Ausgabe einer bestehenden Zeichenorientierte Benutzerschnittstelle oder auch der Kommandozeile oben rechts eingeblendet wird, wenn die entsprechenden Tastenkombinationen betätigt werden. ViewMAX ist das nicht, das ist rein grafisch und hat daher als GEM Abkömmling eine echte GUI. --93.229.163.76 20:00, 19. Okt. 2023 (CEST)

Ebenfalls hallo. Erstmal danke für deine Arbeit.

Das einzige, was mir noch fehlt, ist irgendeine Quelle, in der steht, wie TaskMAX funktioniert. Siehe dazu WP:Q. Denn das klingt zwar alles in etwa richtig für mich, aber wenn es irgendwo steht, hat das mehr Gewicht als das, was wir zwei glauben zu wissen...

Ja, TaskMAX sollte ein eigener Artikel sein. Nachdem das jetzt auch so ist, kannst du gerne alles über TaskMAX in den entsprechenden Artikel verschieben (Copy&Paste, bei ViewMAX entfernen, bei TaskMAX einfügen, die #WEITERLEITUNG einfach löschen). Die Einleitung muss dazu allerdings umformuliert werden, siehe etwa DESQview. Ich würde auch ein "Siehe auch" hinzufügen, das auf DESQview verlinkt.

Was die Formulierungen mit dem XMS betrifft: für das Programm, das im Real Mode läuft, gibt es keinen Zugriff auf XMS, denn das DOS-Programm kennt nur konventionellen Speicher (ein Name, der später vergeben wurde). Ist das nicht ebenso verwirrend? "Wieso kann ein Real-Mode-Programm plötzlich auf XMS-Speicher zugreifen?" Daher würde ich diese Information einfach weglassen, sie ist ohnehin im Artikel Virtual 8086 Mode besser beschrieben, der ja verlinkt ist. Oder nicht?

‣Andreas•⚖ 21:18, 19. Okt. 2023 (CEST)

Die Quelle ist das Programm. Eine bessere Quelle gibt es nicht. In einem Emulator mit Debugger ist das auch überprüfbar, in welchem Zustand, Protected Mode oder Real Mode sich die Maschine befindet.

Das habe ich auch nie behauptet. Bitte richtig verstehen. Die VM86 nutzt XMS Speicher für das Real Mode Programm, das in der VM läuft. Das Real Mode Programm weiß nicht, um was für einen Speicher es sich handelt, sie hält es für konventionellen und UMB Speicher. Das ist auch anders gar nicht machbar, denn sonst könnten die VM86 nie genug Speicher zur Verfügung stellen, wenn sich alle VM86 den konventionellen Speicher teilen müssten.

Nein, ich halte diese Information für wichtig, eben weil so klar ist, dass jede RM Anwendung so nahezu 640 KiB haben kann, was ansonsten nicht möglich wäre. --93.229.163.76 22:34, 19. Okt. 2023 (CEST)

Ja, natürlich ist das wichtig, darum steht es ja im Artikel zum VM86-Modus. Und wenn steht, dass jedes Programm die vollen 640 KB erhalten, oder wenn steht, dass im VM86-Modus jedes DOS-Programm (jedoch Real-Mode-only) kein Speicherproblem mehr hat, dann reicht das, weil es ja im VM86-Mode impliziert ist. Mit anderen Worten: ich muss nicht jedes Mal, wenn ich schreibe, dass etwas im VM86-Modus läuft, dazuschreiben, wie dieser funktioniert. Sonst müsste ich auch bei Multitasking jedesmal dazuschreiben, dass das heißt, dass mehrere Programme quasi parallel ablaufen. Das mache ich aber nicht, weil es mit "Multitasking" impliziert ist, dass das so ist, und genaueres erfährt man dann sowieso im verlinkten Artikel zum Multitasking.

Man müsste es nur dann erwähnen, wenn etwas besonders oder anders als normalerweise abläuft. Wenn ein VM86-Programm also etwas macht, was normalerweise gar nicht üblich ist.

‣Andreas•⚖ 22:57, 19. Okt. 2023 (CEST)

Multitasking kennt jeder, VM86 müssten viele erst nachlesen. Und aus Anwendersicht wollen die Anwender nur wissen, ob sie auch den vollen "konventionellen" RAM bei TaskMAX nutzen können oder ob das mit jeder weiteren geladenen Anwendung immer weniger wird oder die Anwendung, wie bei der DOSShell sogar auf die Platte ausgelagert werden muss. Es ist im TaskMAX Artikel ja nur ein informativer Nebensatz und keine Doktorarbeit, aus diesen beiden Gründen würde ich diese Information drin lassen. Schaden tut es nicht und wenn man den TaskMAX Abschnitt aus dem ViewMAX Artikel extrahiert, dann ist das momentan erst einmal recht wenig Text, da kann weiterer Inhalt nicht schaden. --93.229.163.76 00:46, 20. Okt. 2023 (CEST)

Bis hier fand die Diskussion auf der Benutzerseite von Y2kbug (Andreas) statt. ‣Andreas•⚖ 09:31, 20. Okt. 2023 (CEST)

Ich hab' jetzt mal den Anfang gemacht und den eigenständigen Artikel, wie besprochen, erstellt. Über die Details können wir uns hier besser "streiten". Ich hoffe, die Formulierung passt so, ich habe sie nämlich etwas überarbeitet.

‣Andreas•⚖ 09:34, 20. Okt. 2023 (CEST)

Unter folgendem Link gibt es noch unter Abschnitt "VII.2. i. Multitasker" Informationen zu TaskMGR im Zusammenhang mit VCPI Anwendungen.

https://web.archive.org/web/20191221014613/http://www.antonis.de/dos/dos-tuts/mpdostip/html/nwdostip.htm

Diese müssen wie bei einem Taskswitcher ausgesetzt werden, laufen also nicht im Hintergrund weiter, bis sie wieder in den Vordergrund geholt werden. Das VCPI-Protokoll hat keine Multitasker Unterstützung. --93.229.163.76 03:34, 23. Okt. 2023 (CEST)

QS

Ich habe den TaskMAX und TaskMGR jetzt umfangreich in einer emulierten Umgebung mit Bochs und dessen integriertem Debugger angesehen. Der Vorteil von BOCHS und dessen intergrierter Debugger ist, dass ich damit vom Hostsystem aus sofort sehe, ob die emulierte CPU in den echten Real Mode, in den Protected Mode oder den VM86 Mode geschaltet wird. Die Untersuchung ergab:

• Mit nur 1 MiB RAM wird, egal welche CPU, nur der Real Mode für TaskMAX und die einzelnen Tasks verwendet. TaskMax läuft hier nur als Taskswitcher, mehr siehe weiter unten.
• Mit mehr als 1 MiB RAM und einer CPU ab dem 286 und ausgeschaltetem DPMI, also bei EMM386 DPMI=OFF wird für TaskMax der Protected Mode verwendet, während die Task weiterhin im echten Real Mode arbeiten. TaskMax läuft hier nur als Task Switcher, auch wenn es ein 386er ist.
• Damit die Tasks in ihren VM86 Umgebungen laufen muss DPMI=ON stehen und die CPU ein 386 oder besser sein. TaskMAX läuft dabei im PM und die Tasks im V86 Modus. Der echte Real Mode wird nicht mehr erreicht, es sei denn TaskMax und alle davon abhängigen Prozesse wird beendet. Dieser Modus ist der Multitasking Modus von TaskMax und so steht es auch im DOSBOOK Handbuch.

Weiter ergab:

• TaskMAX kennt im Grunde zwei Modi. Beim ersten funktioniert es als Task Switcher. D.h. Prozesse werden auf Festplatte ausgelagert, oder falls der PM und mehr RAM zur Verfügung steht, in höhere RAM Bereiche ausgelagert. Dieser Modus ist recht anfällig für Amok gelaufene Tasks.
• Beim zweiten Modi funktioniert es als Multitasking Modi. D.h. die Tasks bleiben immer im RAM und verwenden den VM86 des 386 und aufwärts. Zwischen den VM86-Tasks kann dann schnell hin und her geschaltet werden. Dieser Modus ist ausgesprochen robust, mir ist es nicht passiert, dass TaskMAX die Kontrolle nicht zurückerlangen konnte. Allerdings habe ich nur einfache Textprogramme und reine Real Mode Spiele mit Standardgrafik Modi 320x200 (VGA, CGA, EGA) ausprobiert. Zwischen den Spielen konnte hin und her geschaltet werden. Spiele mit speziellen Grafikmodi (VESA, 320x240 usw.), eigenem Keyboard Handler, VCPI und DPMI Dos Extender und EMS Memory habe ich nicht getestet. Hier wäre es denkbar, dass diese (VPCI) wie bei Windows nicht mit dem TaskMAX funktionieren oder der Keyboard Handler dazu führt, dass man TaskMax nicht mehr per Tastenkombination aufrufen kann, weil das Spiel den anderen Keyboard Handler in Beschlag nimmt und alle Eingaben abfängt. Sollte so ein Spiel abstürzen, wird man vermutlich nicht mehr zu TaskMax zurückkehren können, aber das ist nur eine Vermutung. Vielleicht löst TaskMax auch ab und zu Interrupts aus, um als PM Anwendung die Kontrolle automatisch und kurzfristig zurück zu erlangen, das wäre eine Möglichkeit und das könnte ein anderer Keyboard Handler der im VM86 läuft dann auch nicht verhindern. DPMI DOS Extender Programme laufen selbst im PM, hier weiß ich es nicht.

Ich habe den Artikel daher mal komplett überarbeitet. Außerdem fand ich es noch wichtig zu erwähne, dass Microsoft keinerlei Motivation haben konnte, ihre DOS Shell nach MS-DOS 4.x aufzuwerten, denn 1990 gab es bereits Windows 3.0 und das konnte bereits alle notwendigen Funktionen, die man von einem DOS Task Switcher und DOS Multitasker erwarten kann. Hätte Microsoft diese Fähigkeit in die DOS Shell eingebaut, dann hätte es weniger Gründe für die Nutzer gegeben, Windows 3.x zu kaufen. Das war also eine Marketingstrategie, die DOS Shell hier nicht weiter aufzuwerten. Beim Konkurrenten Digital Research war es mit TaskMAX logischerweise ganz anders herum, schließlich hatte man nichts, was man Windows 3.x entgegen setzen hätte können. GEM lief nur im Real Mode und hatte daher ein Speicherplatzproblem für Anwendungen, die darauf laufen sollten. Ein Problem, das Windows 3.x im Standard und Enhanced Mode dank Protected Mode und der Fähigkeit, auf 286er CPUs in den Real Mode zurückschalten zu können, nicht hatte. Außerdem war GEM in Assembler programmiert, was ein Ändern teuer und zeitaufwendig gemacht hätte. Der Wettkampf war für Digital Research damit praktisch schon verloren. Es ist daher auch nicht verwunderlich, dass Garry Kildall DR-DOS nach Version 6.0, also bereits Mitte 1992 an Novel verkaufte, als Windows 3.1 auf dem Markt kam. Er wusste, dass der Zug abgefahren war und DR DOS und GEM langfristig keine Chancen mehr haben würde. Nur Novel hat das nicht gesehen oder sie hatten andere Pläne für DOS oder zu viel Geld. --93.229.164.202 01:35, 2. Nov. 2023 (CET)

Danke für deine Arbeit. Was fehlt, sind WP:Q. Es muss doch irgendetwas im Internet zu finden sein, dass all diese Aussagen -- zumindest die wichtigsten -- belegt.

Darauf bezieht sich auch der QS-Baustein.

‣Andreas•⚖ 07:29, 2. Nov. 2023 (CET)

Den QS Baustein kannst du jetzt entfernen, denn das ist jetzt alles durch den Emulator, dessen Debugger und den Programmcode eindeutig belegt. Einen Artikel speziell über die Funktionsweise von TaskMax wirst du sehr wahrscheinlich niemals finden, denn da er bei DR DOS mitgeliefert wurde, dürfte er lediglich als Randnotiz in einem DR DOS Artikel erwähnt worden sein. Und DR DOS war nicht das meistverbreitete OS, insofern wird das sehr wahrscheinlich auch in keinem Tutorial Artikel wie man Multitasking unter DOS benutzt einer alten Computerzeitschrift vorkommen und in dem Detail, wie ich das oben ausgearbeitet habe, also in welche Modi die CPU geschaltet wird, sowieso nicht. Aber du kannst gerne nach Artikeln suchen. Nach spätestens einer Woche Suche solltest du den Baustein dann aber entfernen wenn du nichts findest. --93.229.164.202 14:01, 2. Nov. 2023 (CET)

Ergänzung, vieles, nicht alles, was im Artikel steht, kannst du auch aus dem DOSBOOK einer DR DOS Installation ab Norton DOS entnehmen. In DR DOS 6.0 ist das DOSBOOK noch sehr dürftig.

• Befehl: DOSBOOK TASKMGR

DOSBOOK ist das Hilfeprogramm für DR DOS, vergleichbar mit HELP.COM ab MS-DOS 6.0. --93.229.164.202 14:51, 2. Nov. 2023 (CET)

Gliederung

Man könnte den Artikel noch untergliedern in die Abschnitte Taskswitching Modus und Multitasking Modus. Dann wäre der Unterschied besser herausgearbeitet. Im Abschnitt Vergleich mit der DOS-Shell könnte man auf den Taskswitching Modus Abschnitt verweisen, mit dem Hinweis, dass die DOS-Shell keine Tasks in höhere Speicherbereie auslagern kann, also zum Auslagern nur Dateien pro Task verwendet und ein Copy&Paste von Strings nicht möglich ist. Ergänzend hierzu könnte man noch eine Tabelle machen, wie im Windows 3.x Artikel, das die beiden Modi und ihre Fähigkeiten miteinander vergleicht. In den Zeilen könnte man dann noch eine Zeile für jeweils DPMI und VCPI Programme einbauen, die man gegebenenfalls später füllen könnte und in denen dann aufgezeigt wird, ob DPMI oder VCPI Programme mit TaskMAX/TaskMGR funktionieren. --93.229.164.202 15:28, 2. Nov. 2023 (CET)

Ja, definitiv. Ich hatte genau denselben Gedanken. ‣Andreas•⚖ 15:40, 2. Nov. 2023 (CET)