Wenn es einfach werden soll bräuchte man eine völlig neue Architektur von Betriebssystem.
Bitte?
Ein Betriebssystem in dem die Anwendungen nicht einfach so auf die Windows
API zugreifen,
sondern beim Start der Anwendung eine ganze Liste von Schnittstellen mitbekommt.
Eine Anwendung braucht z.B. Schnittstellen zur Tastatur, Maus, Grafikkarte, Netzwerk, Audio, Filesystem und Registry.
Dann ist es ja gut, daß es das alles schon gibt. Oder muß sich dein Programm darum kümmern ob es eine Laptoptastatur oder eine "normale" ist? Von Firma A, B, C oder alle drei gleichzeitig eingesteckt sind? Ob PS/2 oder USB? Nein. Die Abstraktion von der du redest, existiert längst und zwar für "Tastatur, Maus, Grafikkarte, Netzwerk, Audio" und mehr.
Wovon du redest ist (u.a.) exakt der Sprung von den alten DOS-Spielen in denen man Soundblaster mit Port und IRQ einstellen muß (oder ein Dutzend anderer Soundkarten) zu den strukturierten Schnittstellen die bspw.
DirectX bot als es eingeführt wurde.
Wozu du nun das Dateisystem und die Registry mit Hardware in einen Topf wirfst ist mir ohnehin ein Rätsel, aber selbst da hast du auf vielen Systemen eine Lösung bereits eingebaut. Die Lektüre von
Andrew S. Tanenbaum's "Moderne Betriebssysteme" kann ich dir da nur ans Herz legen. Als erster Schritt sozusagen.
So könnte z.B. eine Anwendung "A" eine Anwendung "B" starten und ihr ein Filesystem vorgaukeln,
dass es physikalisch gar nicht gibt.
Auf Windows Vista und 7 hast du FS Virtualization und Registry Virtualization. Auf unixoiden gibt es Jails und allgemein chroot() - kombiniere das mit AUFS oder UnionFS sowie anderen Puzzlesteinen und du hast sehr flexible Wege einem Prozeß etwas vorzugaukeln. Du kannst sogar ne
MySQL-Datenbank als Backend benutzen und ein Dateisystem vorgaukeln. Wo muß die Architektur denn da komplett geändert werden?
Und selbst wenn es das auf
OS-Ebene nicht gibt, kann man noch immer den Kindprozeß so kontrollieren daß man dessen Funktionen und ihre Verwendung hookt (auch auf den meisten unixoiden hat der Elternprozeß komplette Kontrolle über Kindprozesse).
Da Gleiche wäre auch für den Netzwerkzugriff möglich.
Ist es. Phoenix hatte schon einen Weg grob umrissen. LSPs könnten eventuell auch eine Methode sein. Aber ich würde Treiber auch vorziehen, selbst wenn LSPs ultimativ funktionieren könnten.
Anwendung "B" denkt es gäbe eine Netzwerkkarte, aber in Wirklichkeit wird diese nur von Anwendung "A" vorgespiegelt.
Und was hat das mit VPN zu tun? Erstmal garnix. Ein Gateway auf beiden Seiten reicht im einfachsten Fall. Dann noch Verschlüsselung in den Topf und schon haste ein lecker VPN.
Es wäre schlimm, wenn Anwendung B sich auf die Ebene begeben müßte, wo sie auch noch die Netzwerkkarte
kennen muß welche von Anwendung A bereitgestellt wird - wenn wir mal für einen Moment diese Idee mitdenken. Der Sinn eines VPN ist ja gerade, daß alle Anwendungen transparent Zugriff darauf haben ohne sich um die Details zu kümmern.
Selbst wenn du eine beliebige netzwerkfähige Anwendung schreibst, mußt du dich in den seltensten Fällen mit den Details der Hardware auseinandersetzen ...
Das wäre ähnlich wie bei einer virtuellen Maschine, nur dass hier feingranular geregelt wird,
was virtuell ist und was nicht.
Hmm, gehört nur irgendwie nicht in die Diskussion, weil
VPNs wie wir sie heute verstehen etwas komplett anderes sind und auch nicht immer auf eine vorgekaukelte Netzwerkkarte angewiesen sind.
