Hallo, ich will mal an den API Funktionen und der Thread Klasse vorbei Multitasking "von Hand" programmieren, als ob ich ein Betriebssystem vor mir hätte, welches das nicht schon selber kann. Bill Gates, der Erfinder von Windows musste das einst auch tun, weil das alte DOS kein Multitasking konnte. So musste die gesamte Threadlogik erst geschaffen werden als Unterbau von Windows. Diese Vorgehensweise möchte ich gerne nachvollziehen. Wie sollte ich vorgehen? Ich habe für den Registers Typ diese Deklaration gefunden:

markieren

Delphi-Quellcode:

TParameters = packed record
{$IFDEF CPUX86}
    Registers: array[paEDX..paECX] of Cardinal; //gibt es da auch die Konstante paEIP?
    EAXRegister: Cardinal;
    ReturnAddress: Pointer;
{$ENDIF CPUX86}
    Stack: array[0..1023] of Byte;
  end;

In diesem Registers Array könnten also die Registerinhalte schon mal abgelegt werden. Wie komme ich aber da ran, wenn ich nicht das WinAPI zu Hilfe nehmen will, sondern so tun will, als gäbe es Windows noch gar nicht?

Ist ReturnAddress der aktuelle Befehlszählerstand?

Dann hätte ich ja schon mal eine Datenstruktur, welche meine Registerinhalte speichert, wenn ich Taskwechsel vornehmen will. Was muss ich noch beachten. Außer der Synchronisation wenn 2 Threads auf eine Zälervariable zugreifen? Allerdings 1024 Byte Stack kommt mir sehr wenig vor bei heutigen Programmen. Reicht denn das wirklich?

Ich würde Speicherbereiche für meine Programme in einer Liste verwalten welche die Startadressen hält. Dann wäre der jeweilige Befehlszählerstand ein Offset zur Anfangsadresse des Speicherbereiches. Allerdings hat jede .exe Datei ja noch einen Header vorne dran, die Startadresse folgt erst danach Was meint ihr daher zu meiner Idee?

Das Wegsichern der Register ist wohl das kleinste Problem beim Multitasking; um das man sich bei moderneren Prozessoren auch nicht mehr so sehr kümmern muss (Registerrenaming usw.)
Wichtiger ist es wie/wann der Prozesswechsel stattfindet (kooperativ/präemptiv; Zeitscheiben/round-robin; ...), IPC, Speicherverwaltung, Caching, ...

http://www.kolibrios.org/de/
https://github.com/vapaamies/KolibriOS

Mit "kooperativ" habe ich sehr gute Erfahrungen gemacht, selbst auf 8-Bit MCUs.
Mit etwas Disziplin funktioniert das bei moderater Anferorderung and RTOS sehr gut,
und kann sogar in der realen Welt Echtzeitstuerungen übernehmen.
Größere Aufgaben in Teil-Blöcke zerlegen.

Die grobe Überlegung dahinter:
Wenn man eine Haupt-Schleife mit ca. 1 kHZ durchfahren kann, ohne irgendwo länger zu blockieren,
dann reicht das für 99.5% der Fälle im realen Leben aus.
Selbst wenn die 1 kHz nur mit +/- 20% erreicht werden.
Weil die reale Welt da draussen eben nicht so schnell durchläuft, Sensoren nicht so schnell liefern und Aktoren nicht so schnell schalten, ...

Ich habe auch als DOS und Assembler Programmierer angefangen und mir sowas selber gebaut. Als ich dann was unter Windows machen musste kam ich mir vor wie kastriert.
Was da damals in den CPUs implementiert wurde um multithread handling auf CPU Ebene zu ermöglichen halte ich noch immer für eine der genialsten Erfindungen in der Geschichte der Computertechnik.

Um Heutzutage selber das Threadingverhalten zu implementieren würde bedeuten dass Du einen Thread dann aufteilen würdest. Ansonsten müsstest Du auf Kernelebene runter. Und der wird dich nicht lassen.
Was allerdings interessanter wäre, eine Routine zu schreiben die mit einem Ausfürungspfad die Zeitschnipsel verschiedener Threads vereint. Kann mir nicht vorstellen dass das geht.

Ich werde also erst mal probieren Datenstrukturen zu bauen und dann wie ein Kind rumprobieren um erste Erfahrungen zu sammeln.

Zitat von delphifan2004:

Ich werde also erst mal probieren Datenstrukturen zu bauen und dann wie ein Kind rumprobieren um erste Erfahrungen zu sammeln.

Du könntest natürlich auch erstmal dich in das Thema einlesen und versuchen zu verstehen, wie das bspw. in Windows gelöst ist.
Beispiel:
https://www.codeproject.com/Articles...Windows-Thread