Allgemein Gültige Schnittstelle gesucht...

[ManSues]

Habe lange gesucht und hoffe in diesem Forum richtig zu sein. Ich würde mich freuen wenn es möglichst viele qualifizierte Meinungen zurückgibt.

Hintergrund: (worum geht es)
Seit Windows Vista (7) ist die Welt des programmierens nicht mehr so einfach wie es bei XP war. Durch strikte Sicherheitsbestimmungen kann nicht mehr jeder mit jedem kommunizieren (Messages), und das normale Programm unter User account ist extrem eingeschränkt, auch in Zugriff auf die Registry.
Ich will gar nicht alle Beschränkungen aufzählen, die wohl jeder kennt. Vor diesen Hintergrund ist es aber immer mehr überlegenswert, die Logik zum Beispiel in einen Windows Service zu legen. Dieser hat aber in der "neuen" Umgebung keine Oberfläche mehr. Auch ein Remote Server wäre denkbar. Also muss noch eine Oberfläche her, damit Daten angezeigt oder Befehle erteilt werden können. Diese beiden EXE müssen also miteinander kommunizieren!

Nun gibt es einige Schnittstellen Ansätze. Sockets oder Pipes wären eine Möglichkeit, auch Interfaces oder Web Services könnte eine Lösung sein. Aber was kommt den optimalen am nächsten?

Um es nicht ganz so einfach aussehen zu lassen, ist es bei dem Ansatz ja ohne weiteres denkbar, den Windows Service als Windows 32 API Applikation zu erstellen und die Oberfläche als Java Webseite! Die Schnittstelle sollte also Sprachübergreifend sein (Was zum Beispiel Sockets und Web Services ja sind).

Ich würde gerne eure Meinung hören, und sei sie noch so abgefahren. Ich denke das Thema wird in Zukunft noch mehr beschäftigen und vielleicht bildet sich ja auch ein Standard wie z.B. MIB.

[himitsu]

Das Thema nennt sich IPC (Interprozesskommunikation, bzw. inter-process communication) und eigentlich gibt es dafür tausende Wege.


- Pipes
- TCPIP über localhost
- MMF (memory-mapped files)
- Mailslots
- Man kann von seinem Programm aus auch irgendwie geziehlt Messages freischalten, damit sie auch von Programmen mit weniger Rechten angesprochen werden können (soweit ich mich richtig erinnere)
...


PS: Die Sicherheit ist eigentlich schon seit WinNT an vielen Stellen stärker eingeschränkt, aber seit Vista setzt Microsoft das endlich mal durch, indem es nicht mehr alle Programme sändig mit Adminrechten laufen läßt.

[ManSues]

Ja, OK, aber bin ich denn der Erste, der nach einer allgemein gültigen Definition sucht? Macht denn jeder von z.B. den AntiVirus Leuten ihre Schnittstelle selbst? Oder hat vielleicht Microsoft (ev. mit Sicherheitslöchern) nicht so was in eine der vielen DLLs gepackt?

[Furtbichler]

Wieso sollte es einen Standard geben, wenn die Anwendungsfälle so unterschiedlich sind?

Wieso gibt es keine Standardkommunikation zwischen Menschen?
Weil es so viele unterschiedliche Anwendungsfälle gibt: Nonverbal, Handzeichen, Reden, Schreiben, Fresse hauen. All das sind perfekte Kommunikationsformen für den jeweiligen Anlass...

[Bernhard Geyer]

Zitat:

Zitat von ManSues (Beitrag 1184040)

Seit Windows Vista (7) ist die Welt des programmierens nicht mehr so einfach wie es bei XP war.

Echt? Ist mir noch nicht aufgefallen? Geht doch alles was man machen will.

Zitat:

Zitat von ManSues (Beitrag 1184040)

Durch strikte Sicherheitsbestimmungen kann nicht mehr jeder mit jedem kommunizieren (Messages),

Wird die wenigsten Stören. Solche (Windows-)Messagekommunikation war schon immer problematisch.

Zitat:

Zitat von ManSues (Beitrag 1184040)

und das normale Programm unter User account ist extrem eingeschränkt, auch in Zugriff auf die Registry.

Eigentlich gibts da nur den unterschied das man im HKLM-Bereich als Normaler user nicht mehr schreiben kann. Aber sonst: Voller zugriff.

Zitat:

Zitat von ManSues (Beitrag 1184040)

Vor diesen Hintergrund ist es aber immer mehr überlegenswert, die Logik zum Beispiel in einen Windows Service zu legen. Dieser hat aber in der "neuen" Umgebung keine Oberfläche mehr.

In Windows-Service sollte man nur legen was auch ohne angemeldetn User permanent laufen muss.

Zitat:

Zitat von ManSues (Beitrag 1184040)

Auch ein Remote Server wäre denkbar.

Halte ich nur für sinnvoll wenn die verteilung andere Vorteile bringt.

Zitat:

Zitat von ManSues (Beitrag 1184040)

Nun gibt es einige Schnittstellen Ansätze. Sockets oder Pipes wären eine Möglichkeit, auch Interfaces oder Web Services könnte eine Lösung sein. Aber was kommt den optimalen am nächsten?

Jede schnittstelle hat ihre Vor- und Nachteile. Der Anwendungsfall entscheidet.

Zitat:

Zitat von ManSues (Beitrag 1184040)

.... und die Oberfläche als Java Webseite

Wenn du mit "Java Webseite" meinst eine Java-Applet. Das ist am Sterben wie Flash und Silverlight auch. Die Zukunft ist HMLT5+JS

Zitat:

Zitat von ManSues (Beitrag 1184040)

Ich würde gerne eure Meinung hören, und sei sie noch so abgefahren

Wenn du was auf einem Server installieren kannst dann gehört HTML5(+JS/CSS/...) die Zukunft. Hier kann man aus einer "Exe" alle Zielplattformen von PC, Tablets und Smartphones bedienen. Wenn's native sein soll dann wirds komplizierter da jedes Plattform (iOS, Android, Windows RT) hier versucht ein abgeschottetes System aufzubauen. Hier gibt aber auch Ansätze die HTML5/JS-Lösung zu "kompilieren" und dann native Laufen zu lassen. Stichworte wären z.B. PhoneGap und Co.

[mkinzler]

Zitat:

Eigentlich gibts da nur den unterschied das man im HKLM-Bereich als Normaler user nicht mehr schreiben kann. Aber sonst: Voller zugriff.

Das konnte man als normaler Benutzer noch nie. Die UAC sorgt nun aber dafür, dass man auch als Admin nur mit Userrechten arbeitet, aber seine Rechte "erhöhen" kann.

[Bernhard Geyer]

Zitat:

Zitat von mkinzler (Beitrag 1184468)

Zitat:

Eigentlich gibts da nur den unterschied das man im HKLM-Bereich als Normaler user nicht mehr schreiben kann. Aber sonst: Voller zugriff.

Das konnte man als normaler Benutzer noch nie.

"Damals" war halt der normale User auch Mitglied der lokalen Admingruppe und die Prozesse haben automatisch diese Rechte geerbt.
Aber nix was großartig Probleme bei der SW-Entwicklung bereitet das man hier jetzt nicht mehr schreiben darf.

[Phoenix]

Zitat:

Zitat von ManSues (Beitrag 1184040)

Durch strikte Sicherheitsbestimmungen kann nicht mehr jeder mit jedem kommunizieren (Messages), und das normale Programm unter User account ist extrem eingeschränkt, auch in Zugriff auf die Registry.

Solange Du keine Software schreibst die zwangsläufig Admin-Rechte benötigen würde, sollten Dich diese (im übrigen sehr sinnvollen) Restriktionen nichtmal ansatzsweise tangieren.

Was ist denn Dein konkreter(!) Einsatzzweck? Was muss Dein Code machen, was er aktuell nicht darf?

[ManSues]

Ja, prima, so langsam kommt die Diskussion in Gang.
Aber Vorweg: Nicht das ihr mich falsch versteht. Ich bin ein absoluter Verfechter der Windows 7 (NT5) Sicherheitsmaßnahmen.

Nun zum konkreten Beispiel:
Unter XP entstanden einige Server, halt ganz normale EXE die Daten über Socket Verbindung (TCP/IP) an die Clients liefern. Da gibt es z.B. IO-Server (Datenlieferant von untergelagerten Systemen), Security-Server (Benutzerverwaltung mit Rechten) oder Language-Server (der zur ID und LCID den Text liefert). Es gibt noch eine Menge mehr, aber als Beispiel sollte es genügen. Diese Server laufen auf irgendeinen PC und beliefern die Anfragen von Clients auf anderen PCs. Nun sollen diese Server als Windows Dienste umgebaut werden, was auch einleuchtend ist, da diese sowieso schon Aufgaben von Diensten erfüllen.
Jetzt kommen wir zum Pudels Kern...
Alle diese Server haben eine Oberfläche (Form) zum Konfigurieren, analysieren und warten. Diese Oberfläche fällt beim Windows 7 Dienst weg. Es muss also die Form von der Logik getrennt werden, Form als EXE und Windows Dienst mit Logik, wobei die Oberfläche nicht zwangsläufig eine Form sein muss. Es ist auch eine Webseite denkbar.
Aber Bedienoberfläche und Dienst müssen kommunizieren. Und da suche ich eine Lösung. Anzumerken sei vielleicht noch, dass der Dienst nur Daten zur Oberfläche liefert oder bekommt. Wie die Oberfläche aussieht, entscheidet der Designer der Oberfläche (vielleicht ein wenig so wie XAML und CodeBehind)

[Bummi]

Named Pipes mit Rechtevergabe auf Benutzerebene über eine beiliegende Dummydatei wäre meine erste Wahl.
TCP/IP 2. Wahl
INI-Dateien 3. Wahl