Ja klar es gibt Möglichkeiten um Hooks oder LSPs in WinSock einzuschieben, aber das ist recht aufwendig.
[...]
Die Anwendung bekommt schon beim Start einen Interfacezeiger übergeben.
... auch wenn sie nie vorhat die Funktionen zu verwenden, nehme ich mal an? Klingt wie eine von diesen Funktionen mit 33 Parametern - nur daß es hier noch mehr werden würden.
Die Anwendung funktioniert genau gleich wie vorher, nur mit dem Unterschied, dass das Betriebssystem seine
API-Dienste anbietet anstatt dass die Anwendung festgelegte APIs aufruft.
Das tut das
OS bereits und die
API-Funktionen sind einfach nur das Format in welchem die Dienste angeboten werden.
Man nehme die guten alten Callbacks, verpacke sie in
OOP und nenne das "Inversion of Control"
Hab ich es richtig verstanden?
Würde nun diese Host-Anwendung eine andere Anwendung starten, dann würde sie sämtliche WinSock-Aufrufe mitbekommen.
Jupp. Könnte sie. Wäre nicht mal so doof, wenn man das bei Diensten benutzen könnte. Nur leider habe ich keine Kontrolle über die Hostanwendung von Diensten.
Jetzt wäre es ein Leichtes, wenn die Host-Anwendung alle Netzwerkaufrufe tunneln würde.
Stimmt. Dumm nur, daß auf der anderen Seite des Tunnels das gleiche Prinzip herrschen müßte. Da sind mir die transparenten VPNs, wie es sie bereits gibt, schon lieber.
Somit wurde die WinSock-
API virtualisiert, weil die ursprüngliche Anwendung gar nicht merkt, dass seine Aufrufe abgefangen und verändert werden.
Stimmt. Und es klingt danach, daß sich die Supportabteilungen aller Softwarefirmen darauf einstellen müssen in Zukunft auch Probleme zu bearbeiten, die von amateurhaft geschriebenen "Hostanwendungen" erzeugt werden.
Oder man denke nur an Softwaretests und die Möglichkeiten einfach so Mock-Objekte für Windows-
API-Aufrufe zu erstellen.
... du schreibst deinen Code also vermutlich so, daß du direkt die
API-Funktionen aufrufst und, sagen wir mal bei Registryfunktionen, das Ganze nicht zuvor in eine Klasse kapselst deren Schnittstellen man auch ohne Unterstützung des Betriebssystems "mocken" kann? Hab das etwas anders gelernt.
Würde es dieses utopische Betriebssystem geben, dann wäre es einfach, alles mögliche umzuleiten und zu verändern.
Schonmal versucht einen Dateisystemfiltertreiber zu debuggen? Was du hier vorschlägst ist die Ausdehnung des Prinzips auf alles. Chaos pur. Bei Treibern ist man nämlich auch auf die Kooperation anderer Treiber angewiesen. Und selbst wenn ein Fehler in einem anderen Treiber im Filterstack hervorgerufen wird, kann es sein, daß dein eigener Treiber beim BSOD als Verursacher dargestellt wird (siehe "Supportabteilung" weiter oben).
Der Trend geht ganz klar in Richtung Virtualisierung und so darf ruhig ein bisschen darüber nachdenken was denn wäre, wenn alle APIs virtuell wären.
Der kleine aber feine Unterschied ist, daß alle anderen Virtualisierungsansätze heutzutage darauf ausgelegt sind, daß die Anwendungen transparent die virtuelle Hardware usw. nutzen können. Bei dir klingt es nach dem genauen Gegenteil. Transparenz ist dann passé.
(und ohne virtuelle Pflänzchen gleich argumentativ niederzuknüppeln)
Gern geschehen. Unsere Diskussion hat mit den VPN-Thema des Fragestellers aber noch immer nicht viel zu tun
...
Ich werf ja auch nicht überall ein: "Ach ja, Okapis sehen süß aus", nur weil jemand "
API" verwendet und diese Buchstabenkombination im "Okapi" vorkommt. Ähnlich beliebig kommt mir deine Vorstellung von von Virtualisierung bei Erwähnung von "Virtual Private Network" vor.