An genau dem gleichen Punkt war ich auch, vor etwa zwei Jahren: "
Wäre es nicht total cool, diese Anwendung auf eine Multi-Prozess-Architektur umzubauen?".
Als Beispiel hatte ich auch die Browser Chrome und Internet Explorer gefunden, Firefox hatte das dann später auch. Genau die Stabilität ist von den entsprechenden Entwicklern auch immer als Kriterium angeführt worden weshalb man sich dafür entschieden hat.
Um den Aufwand zu rechtfertigen führte ich noch weitere Vorteile an:
- Steuerung von Lastverteilung mittels Windows-Jobs möglich: Einzelnen Programmteilen können so gezielt Ressourcen zugewiesen werden, wichtige Bestandteile können bevorzugt werden.
- Einzelne Bestandteile könnten auf entfernte Rechner und Nicht-Windows-Systeme ausgelagert werden
Im Endeffekt hatte ich also genau das vor was du mit "
Hauptanwendung (-Prozess) mit Tabs in je einem eigenen Prozess." umschreibst.
Um es kurz zu machen: Es war eine absolute Fehlentscheidung. Es hat Zeit gefressen. Es wurde viel gelernt. Heute ist die entsprechende Software immer noch ein monolithisches Projekt und läuft besser und stabiler als jemals zuvor.
Zum einen war der, schon angesprochene, gewaltige Aufwand einzelne Teile zu isolieren und allen die gemeinsame
IPC/RPC-Schnittstelle einzupflanzen. Profis hätten da sicher mit (D)
COM irgendetwas gedreht. Bei uns kannte sich damit aber niemand gut genug aus und gerade bei "
DCOM-Problemen" wurden mir mit leerem Blick und zitternden Händen wahre Schauergeschichten erzählt.
Angenommen man hat diese Hürde nun gemeistert und sein Programm in einzelne Teile zerlegt die nun untereinander kommunizieren. Lief es schneller? Keineswegs. Lief es stabiler? Nein, die Fehlersuche/Debugging wurde dafür aber um eine Zehnerpotenz komplizierter.
Das an sich hätte man noch vertragen können. Der Punkt an dem mir klar wurde dass ich einfach nicht auf Schmerzen stehe ist als die "Minor changes" des Alltags kamen. Kleine Querverknüpfungen, Kunden Sonder-Wünsche. Für jeden kleinen Mist musste eine Schnittstelle geschaffen werden. Für einen kleinen Sonderfall mussten auf einmal Programmteile miteinander sprechen die das Konzept eigentlich penibel sauber getrennt hatte. Wozu hatten wir den Mist eigentlich aufgeteilt?
Grade Delphi ist eine Tool mit welchem man, wenn es schnell gehen muss, auch fünf mal grade sein lassen kann. Für den einen Kunden-Sonderwunsch den er zwei mal im Jahr braucht kann man es auch mal dreckig werden lassen und eine Abhängigkeit schaffen die in einer perfekten Welt nicht da ist. In einer so penibel sauber aufgeteilten Multi-Prozess-Welt in welcher der eine Prozess A jetzt plötzlich Daten aus einem anderen Prozess B haben muss, dieser aber bislang nur mit dem Hauptprogramm Prozess C spricht und diese Daten noch nicht einmal rausgibt ist so etwas ein absoluter Albtraum. In einem monolithischen Programm ist das, je nachdem wie man grade drauf ist, schnell erledigt.
Lange Rede, kurzer Sinn:
Ich stimme Bernhard Geyer voll zu und rate dir es nicht zu tun. Es hört sich in der Theorie toll an. Für die Entwicklung der Browser war das auch die richtige Entscheidung. Die Zuständigkeiten sind hier fest geregelt und jeder Tab tut im Endeffekt das gleiche. Aber auf die wohl meisten Software-Produkte tut man sich mit so etwas keinen Gefallen.
PS: Ja, du kannst z.B. über
SetParent(..) Fenster aus anderen Anwendungen einbetten. Der alte Windows-Bildschirmschoner-Dialog ist ein Beispiel dafür.
Aber schau mal welche Erfahrungen man damit auch machen kann:
-
http://stackoverflow.com/q/16817112 (Meine Erfahrung)
-
https://blogs.msdn.microsoft.com/old...412-00/?p=4683