Forum: SuRun Beta RSS
SuRun 1.2.0.1
Seite:  1  2  3  4  5  6  nächste 
Kay (Administrator) #1
Benutzertitel: Weltverbesserer
Mitglied seit 11/2007 · 1464 Beiträge · Wohnort: Magdeburg
Gruppenmitgliedschaften: Administratoren, Mitglieder
Profil anzeigen · Link auf diesen Beitrag
...SuRun 1.2 ist zwar raus, aber die "schlechte" Performance auf langsamen PC, die enorm hohe Zahl der Kontext-Wechsel (>400/s) in "SuRun /SysMenuHook" und die Schwierigkeiten mit Domänen haben mich dazu gebracht, eine 1.2.0.1 zu stricken.

Ich habe alle Routinen, die prüfen ob ein Benutzer in der Gruppe SuRunners oder Administratoren ist, angepasst.
Jetzt sind die Kontext-Wechsel im Schnitt bei 3/s.

Die Routinen enummerieren die Benutzer der Gruppen nicht mehr im Kontext von "System", sondern im Kontext der Shell. Damit sollte das auch in Domänen (StefanB ?) funktionieren.

Da sich an den Features nichts, an der Infrastruktur aber viel geändert hat, packe ich das geänderte SuRun mal hier rein.

Bitte schaut mal, ob noch alles geht, wie mit SuRun 1.2.0.0.

Das Problem mit den Domänen sollte weg sein.
Die Auslastung der CPU auf dem Centrino 1700@600MHz auch.
Der Autor hat eine Datei an diesen Beitrag angehängt:
SuRun1201rc1.zip | Speichern   614,1 kBytes, 162 mal heruntergeladen
Cosmo #2
Mitglied seit 03/2008 · 451 Beiträge
Gruppenmitgliedschaften: Mitglieder
Profil anzeigen · Link auf diesen Beitrag
2 Beobachtungen:

Der Kontextmenüeintrag auf dem Desktop für die Systemsteuerung erscheint nur beim uneingeschränkten und eingeschränkten Surunner; er erscheint nicht beim blinden Surunner, Admin und LUA/Nicht-Surunner.

Dasselbe gilt für die Systemmenübefehle. Das kann dann dazu führen, daß für einen Surunner der Zeitdialog für manuellen Start in die Programmliste genommen wurde (und auch funktioniert, indem er "Neustart" aufruft), sobald dieser SuRunner aber blind gemacht wird, kann er da nicht mehr heran.

Das zweite ist vermutlich nicht neu, ist mir jedoch erst jetzt aufgefallen, weil es nur erscheint, wenn man ein neues Konto erstellt, dieses (vom Admin aus) zum uneingeschränkten SuRunner macht bevor man dieses Konto zum ersten Mal öffnet. Windows muß dann ja das Konto körperlich erstellen. Dabei wird ein Setup-Befehl für OE gestartet, von dem SuRun irrtümlich meint, daß erhöhte Rechte erforderlich seien, nur kann SuRun in dieser Situation noch gar nicht auf den sicheren Desktop umschalten und man sieht, daß das ganze erst einmal lange stecken bleibt. Das ganze passiert beim Erstellen eines neuen Kontos zweimal hintereinander. Eventuell ist es erforderlich, das besagte Programm in die Ausnahmeliste vorzudefinieren. (Da für OE IMHO niemals der Bedarf entsteht, es erhöht zu starten - und auch gar nicht genutzt werden sollte - sehe ich da kein Problem, zur Not kann der Anwender diesen Eintrag aus der Ausnahmeliste löschen.)
Thomas
cmb #3
Mitglied seit 11/2007 · 63 Beiträge
Gruppenmitgliedschaften: Mitglieder
Profil anzeigen · Link auf diesen Beitrag
Zitat von Cosmo:
2 Beobachtungen:

Der Kontextmenüeintrag auf dem Desktop für die Systemsteuerung erscheint nur beim uneingeschränkten und eingeschränkten Surunner; er erscheint nicht beim blinden Surunner, Admin und LUA/Nicht-Surunner.

Dasselbe gilt für die Systemmenübefehle. Das kann dann dazu führen, daß für einen Surunner der Zeitdialog für manuellen Start in die Programmliste genommen wurde (und auch funktioniert, indem er "Neustart" aufruft), sobald dieser SuRunner aber blind gemacht wird, kann er da nicht mehr heran.

Das zweite ist vermutlich nicht neu, ist mir jedoch erst jetzt aufgefallen, weil es nur erscheint, wenn man ein neues Konto erstellt, dieses (vom Admin aus) zum uneingeschränkten SuRunner macht bevor man dieses Konto zum ersten Mal öffnet. Windows muß dann ja das Konto körperlich erstellen. Dabei wird ein Setup-Befehl für OE gestartet, von dem SuRun irrtümlich meint, daß erhöhte Rechte erforderlich seien, nur kann SuRun in dieser Situation noch gar nicht auf den sicheren Desktop umschalten und man sieht, daß das ganze erst einmal lange stecken bleibt. Das ganze passiert beim Erstellen eines neuen Kontos zweimal hintereinander. Eventuell ist es erforderlich, das besagte Programm in die Ausnahmeliste vorzudefinieren. (Da für OE IMHO niemals der Bedarf entsteht, es erhöht zu starten - und auch gar nicht genutzt werden sollte - sehe ich da kein Problem, zur Not kann der Anwender diesen Eintrag aus der Ausnahmeliste löschen.)

aha... erklärt das vielleicht auch meine Probleme aus #186?

was ich da skizziert habe ist wirklich lästig, da ich keine Verknüpfung (weder auf dem Desktop noch im QL-Bar noch im StartMenu) mehr per Rechts-Klick als Admin starten kann und statt dessen ggf. direkt die zugehörige exe im Explorer nehmen muss... Rechtsklick auf Desktoip für "Systemst. als Admin" geht mekrwürdigerweise...

wie gesagt auf zwei Maschinen... und das ging früher mal...

- Clemens
Dieser Beitrag wurde am 13.08.2008, 16:12 von cmb verändert.
Kay (Administrator) #4
Benutzertitel: Weltverbesserer
Mitglied seit 11/2007 · 1464 Beiträge · Wohnort: Magdeburg
Gruppenmitgliedschaften: Administratoren, Mitglieder
Profil anzeigen · Link auf diesen Beitrag
Antwort auf Beitrag #2
Zitat von Cosmo:
Der Kontextmenüeintrag auf dem Desktop für die Systemsteuerung erscheint nur beim uneingeschränkten und eingeschränkten Surunner; er erscheint nicht beim blinden Surunner, Admin und LUA/Nicht-Surunner.
Dasselbe gilt für die Systemmenübefehle.

Das ist bei 1.2.0.0 auch schon so und ist so geplant.

Das mit der Systemsteuerung ist ja klar. Die dürfen nur SuRunner als Admin starten.

Der System-Menu-Hook kann nicht unterscheiden, ob das Programm erlaubt ist oder nicht.
Deswegen wird es bei nicht SuRunnern und bei blinden SuRunnern pauschal ausgeblendet.

Zitat von Cosmo:
Wenn man ein neues Konto erstellt, dieses (vom Admin aus) zum uneingeschränkten SuRunner macht bevor man dieses Konto zum ersten Mal öffnet. Windows muß dann ja das Konto körperlich erstellen. Dabei wird ein Setup-Befehl für OE gestartet, von dem SuRun irrtümlich meint, daß erhöhte Rechte erforderlich seien, nur kann SuRun in dieser Situation noch gar nicht auf den sicheren Desktop umschalten und man sieht, daß das ganze erst einmal lange stecken bleibt.

Ja, das war mit SuRun 1.2.0.0 auch schon so, ist saublöd und lässt sich schwer vermeiden.

Microsoft verdeckt die Bildschirmausgabe der eigenen Installer beim Anmelden.
Winlogon lässt den Anmeldebildschirm einfach aktiv, während der Installer läuft.
Nur wird dort statt dem Installer SuRuns Desktop angezeigt.
SuRun kann aber nicht auf den Desktop schalten. Der WatchDog versucht das, aber es geht schief.

Wenn Du nach der Anmeldung lange "Beutzereinstellungen werden geladen" siehst und dann Strg+Alt+Enft drückst, schaltet Windows auf SuRuns Desktop um.

Für OE eine extra-Lösung zu stricken halte ich für wenig sinnvoll. Da muss was besseres her, nur was?

Ich habe das Problem mal in die "Drüber Nachdenken"-Liste gestellt ;-)
Kay (Administrator) #5
Benutzertitel: Weltverbesserer
Mitglied seit 11/2007 · 1464 Beiträge · Wohnort: Magdeburg
Gruppenmitgliedschaften: Administratoren, Mitglieder
Profil anzeigen · Link auf diesen Beitrag
Antwort auf Beitrag #3
Zitat von cmb:
aha... erklärt das vielleicht auch meine Probleme aus #186?

Nein, leider ist das was Anderes.
SuRuns Kontextmenü für "*.LNK"-Dateien steht fest in der Registry.
Wenn "Starte als Administrator" nicht angezeigt wird, liegt dass am Link.
Bei mir z.B. ist "Starte als Administrator" bei Word unsichtbar. (Siehe Anhang)
Der Autor hat eine Datei an diesen Beitrag angehängt:
InkScape1.png | Speichern   7,8 kBytes
Bild
Cosmo #6
Mitglied seit 03/2008 · 451 Beiträge
Gruppenmitgliedschaften: Mitglieder
Profil anzeigen · Link auf diesen Beitrag
Antwort auf Beitrag #4
Zitat von Kay:
Zitat von Cosmo:
Der Kontextmenüeintrag auf dem Desktop für die Systemsteuerung erscheint nur beim uneingeschränkten und eingeschränkten Surunner; er erscheint nicht beim blinden Surunner, Admin und LUA/Nicht-Surunner.
Dasselbe gilt für die Systemmenübefehle.

Das ist bei 1.2.0.0 auch schon so und ist so geplant.

Das mit der Systemsteuerung ist ja klar. Die dürfen nur SuRunner als Admin starten.

Der System-Menu-Hook kann nicht unterscheiden, ob das Programm erlaubt ist oder nicht.
Deswegen wird es bei nicht SuRunnern und bei blinden SuRunnern pauschal ausgeblendet.
Daß ich die eine oder andere Änderung in dem einen oder anderen Build übersehe, ist normal. Mit dem, was du da geplant hast, kann ich auch durchaus leben.

Aber es folgt daraus ein anderes generelles Problem, und das hat mit dem Thema "Dokumentation" zu tun, mit der wir uns ja gerade erst ausgiebig beschäftigt haben.

Dieses von mir gemeldete Verhalten ist weder auf Anhieb als gewollt erkennbar, noch ist es logisch im Sinne der Bedienung. (Beweis: Ich habe das nicht als "by Design" erkannt, und Clemens ganz offensichtlich auch nicht.) Das De-Aktivieren der einzelnen Kontextmenü-Elemente ist ganz offensichtlich eine für alle gemeinsam geltende Funktion. Wenn es jetzt für einzelne Gruppen dann doch unterschiedliche Ergebnisse gibt, gehört das in die Kategorie "überraschend", und "überraschend" kann potentiell auf "falsch" hinweisen.

Solche Einstellungs-Schlenker gehören folglich in die Dokumentation.

Zitat von Kay:
Für OE eine extra-Lösung zu stricken halte ich für wenig sinnvoll. Da muss was besseres her, nur was?
Was spricht gegen meine Idee? Einfach zu realisieren, ebenso einfach reversibel (obwohl es dafür keinen Bedarf gibt).

Der SuRunner, der in diese Situation kommt, hat nicht einmal die Chance irgendwo (auch das steht aber gar nicht in der Dokumentation) nachzugucken, daß er Strg-Alt-Entf drücken soll. Er wird vor dem Monitor sitzen und denken: "Früher ging das immer sofort - also ist hier ein Fehler." Und wenn dann der SuRun-Desktop erscheint, wem wird er den Fehler zuordnen? Das sieht nicht nach etwas aus, was lange in einer "Nachdenken-Liste" bleiben darf.
Thomas
Dieser Beitrag wurde am 13.08.2008, 17:10 von Cosmo verändert.
cmb #7
Mitglied seit 11/2007 · 63 Beiträge
Gruppenmitgliedschaften: Mitglieder
Profil anzeigen · Link auf diesen Beitrag
Antwort auf Beitrag #5
Zitat von Kay:
Zitat von cmb:
aha... erklärt das vielleicht auch meine Probleme aus #186?

Nein, leider ist das was Anderes.
SuRuns Kontextmenü für "*.LNK"-Dateien steht fest in der Registry.
Wenn "Starte als Administrator" nicht angezeigt wird, liegt dass am Link.
Bei mir z.B. ist "Starte als Administrator" bei Word unsichtbar. (Siehe Anhang)

wo steht das in der Registry? Wenn es nur Word wäre, wo bei mir die Rechtsklick-"Starte als"-Menüeinträge fehlen wäre es mir ja egal, aber die fehlen hier bei ALLEN Verknüpfungen (übrigens auch die "Ausführen als..."- Einträge, die das Original "Ausführen als" ersetzen") und das läuft der Idee von SuRun doch irgendwie zuwieder...

muss sich ja irgendwie reparieren lassen... Löschen der Haken im SuRUn-Setup und erneutes Setzen der Haken für "Neustart als" bzw. "Start als" ändert leider nichts...

- Clemens
Dieser Beitrag wurde am 13.08.2008, 17:11 von cmb verändert.
Kay (Administrator) #8
Benutzertitel: Weltverbesserer
Mitglied seit 11/2007 · 1464 Beiträge · Wohnort: Magdeburg
Gruppenmitgliedschaften: Administratoren, Mitglieder
Profil anzeigen · Link auf diesen Beitrag
Zitat von cmb:
wo steht das in der Registry?

Hier:
HKEY_CLASSES_ROOT\batfile\shell\SuRun
HKEY_CLASSES_ROOT\cmdfile\shell\SuRun
HKEY_CLASSES_ROOT\cplfile\shell\SuRun
HKEY_CLASSES_ROOT\exefile\shell\SuRun
HKEY_CLASSES_ROOT\MSCFile\Shell\SuRun
HKEY_CLASSES_ROOT\regfile\shell\SuRun
HKEY_CLASSES_ROOT\Msi.Patch\shell\SuRun open
HKEY_CLASSES_ROOT\Msi.Package\shell\SuRun open
HKEY_CLASSES_ROOT\Msi.Package\shell\SuRun repair
HKEY_CLASSES_ROOT\Msi.Package\shell\SuRun Uninstall

Zitat von cmb:
Wenn es nur Word wäre, wo bei mir die Rechtsklick-"Starte als"-Menüeinträge fehlen wäre es mir ja egal, aber die fehlen hier bei ALLEN Verknüpfungen (übrigens auch die "Ausführen als..."- Einträge, die das Original "Ausführen als" ersetzen") und das läuft der Idee von SuRun doch irgendwie zuwieder...

Da ist bestimmt was anderes faul!
Wenn HKEY_CLASSES_ROOT\exefile\shell\SuRun da ist, und Du in Explorer auf einer EXE recht-klickst, sollte "Starte als Administrator" da sein. Dann funktioniert alles.

Wenn nur der Desktop-Explorer das nicht zeigt...Hmmm
...vielleicht kann man das im Active-Desktop deaktivieren?

Zitat von cmb:
muss sich ja irgendwie reparieren lassen... Löschen der Haken im SuRUn-Setup und erneutes Setzen der Haken für "Neustart als" bzw. "Start als" ändert leider nichts...

Ein Update ohne "verknüpfungen behalten" sollte normaler Weise alles reparieren.
cmb #9
Mitglied seit 11/2007 · 63 Beiträge
Gruppenmitgliedschaften: Mitglieder
Profil anzeigen · Link auf diesen Beitrag
Zitat von Kay:
Zitat von cmb:
wo steht das in der Registry?

Hier:
HKEY_CLASSES_ROOT\batfile\shell\SuRun
HKEY_CLASSES_ROOT\cmdfile\shell\SuRun
HKEY_CLASSES_ROOT\cplfile\shell\SuRun
HKEY_CLASSES_ROOT\exefile\shell\SuRun
HKEY_CLASSES_ROOT\MSCFile\Shell\SuRun
HKEY_CLASSES_ROOT\regfile\shell\SuRun
HKEY_CLASSES_ROOT\Msi.Patch\shell\SuRun open
HKEY_CLASSES_ROOT\Msi.Package\shell\SuRun open
HKEY_CLASSES_ROOT\Msi.Package\shell\SuRun repair
HKEY_CLASSES_ROOT\Msi.Package\shell\SuRun Uninstall

Zitat von cmb:
Wenn es nur Word wäre, wo bei mir die Rechtsklick-"Starte als"-Menüeinträge fehlen wäre es mir ja egal, aber die fehlen hier bei ALLEN Verknüpfungen (übrigens auch die "Ausführen als..."- Einträge, die das Original "Ausführen als" ersetzen") und das läuft der Idee von SuRun doch irgendwie zuwieder...

Da ist bestimmt was anderes faul!
Wenn HKEY_CLASSES_ROOT\exefile\shell\SuRun da ist, und Du in Explorer auf einer EXE recht-klickst, sollte "Starte als Administrator" da sein. Dann funktioniert alles.

Wenn nur der Desktop-Explorer das nicht zeigt...Hmmm
...vielleicht kann man das im Active-Desktop deaktivieren?

Zitat von cmb:
muss sich ja irgendwie reparieren lassen... Löschen der Haken im SuRUn-Setup und erneutes Setzen der Haken für "Neustart als" bzw. "Start als" ändert leider nichts...

Ein Update ohne "verknüpfungen behalten" sollte normaler Weise alles reparieren.

alle von Dir erwähnten registry-Einträge sind da (habe extra Update ohne "Verknüpfungen behalten" gemacht) und wenn ich ein entsprechendes file im Explorer rechtsklicke sind die SuRun-Einträge "Starte als..." auch da,

aber egal, welche Verknüpfung ich rechtsklicke, ob im Startmenü oder sonstwo (z.:B. Desktop oder Quickstartleiste) habe ich keinen "Starte als"-Eintrag im Rechtsklick... lediglich der Rechtsklick auf den Desktop-Hintergrund zeigt den "Systemsteuerung als Admin"-Eintrag...

also ich kann mir da keinen Reim drauf machen... zumal das auf 2 Maschinen so ist...

kann das ein Rechteproblem sein? Zugriff auf gewisse Teile der Registry oder so?

- Clemens
Cosmo #10
Mitglied seit 03/2008 · 451 Beiträge
Gruppenmitgliedschaften: Mitglieder
Profil anzeigen · Link auf diesen Beitrag
Antwort auf Beitrag #8
Ich hab heute nachmittag über die eingeführte Trennung der Kontextmenübefehle in Abhängigkeit von den Kontentypen noch ein wenig nachgedacht, denn so wie es jetzt ist, ist es nicht wirklich konsequent.

Wenn man das so macht - und da bin ich durchaus im gleichen Boot - so müßten eigentlich alle Kontextmenübefehle entfallen für:
Admins
Nicht-SuRunner LUA.

Denn wo ist die Logik, bei einem Teil der Befehle zu sagen: Das dürfen die und die sowieso nicht, bei einem anderen Teil das aber nicht zu sagen, obwohl dasselbe zu 100% zutrifft?

Nehmen wir die Admins:
Wenn der Admin den Kontextmenü im Desktop nicht braucht (klar), so braucht er ihn in Wirklichkeit nirgendwo. Kontextmenübefehle haben für den Admin die einzige Funktion, das eigene Konto zum SuRunner zu degradieren; aber für diesen einen Zweck finde ich keine logische Begründung, warum an der einen Stelle da und an der anderen Stelle weg. Diese Begründung für die Kontextbefehle war im übrigen vor einigen Monaten effektiv, heute (seit Einführung des Traysymbols) nicht mehr, denn Neu-Anwender von SuRun werden sich - wie bei jedem neuen Programm - erst einmal an dem festhalten und hangeln, was sie ohne eigenes Zutun vor der Nase haben, und das ist dieses Symbol. Also, wenn jemand sein Admin-Konto downgraden will - und das kommt genau ein einziges Mal vor - so findet er den Zugriff dafür vor der Nase und wird höchst unwahrscheinlich im Kontextmenüs danach suchen.

Im übrigen: Allerspätestens - aber wie gesagt nicht erst dann - sind alle Kontextbefehle für Admins überflüssig - eigentlich sogar widersprüchlich - wenn die Option, Admins niemals zu fragen, aktiviert ist.

Nebenbemerkung: Das Ausblenden des SuRun-Befehl für dei Systemsteuerung im Desktop-Kontext wirkt insbesondere dann nicht logisch (und ließ mich zwangsläufig an einen Bug denken, als ich das berichtet hatte), weil im Kontextmenü für die Systemsteuerung im Startmenü derselbe (inhaltlich) Kontextbefehl weiterhin vorhanden ist.

Für Nicht-SuRunner ist es nicht viel anders. Solange sie keine SuRunner sind, haben nicht nur die jetzt für sie unsichtbar gemachten Kontextbefehle keinen Sinn, sondern keiner von ihnen. Tatsächlich gibt es unter den Nicht-SuRunnern 2 Typen: Einmal den, der als körperliche Person mit dem Admin identisch ist und sich ein eingeschränktes Konto eingerichtet hat; der wird wohl nicht lange Nicht-SuRunner bleiben (aber solange er es ist, trifft vorgesagtes auch hier zu). Der andere Nicht-SuRunner sind körperlich andere Menschen und nur in einem Teil der Fälle werden sie von den teilweise noch vorhandenen Kontextbefehlen überhaupt etwas haben, nämlich wenn sie das Admin-Kennwort kennen. Ohne über die Quote zu spekulieren, sie wird hier erheblich sein. Und diese Nicht-SuRunner können eben nicht nur mit den jetzt bereits für sie ausgeblendeten Befehlen nichts anfangen, sondern mit keinem überhaupt.

Die Kenntnis des Admin-Kennwortes vorausgesetzt haben Kontextbefehle für Nicht-SuRunner den einzigen Zweck, sich zu SuRunnern zu machen; danach sind sie ja keine Nicht-SuRunner mehr. Dafür braucht man aber erstens nicht zwischen verschiedenen Kontextbefehlen zu unterscheiden und man braucht sie eigentlich gar nicht (und zwar alle betreffend) zu zeigen. Um sich selbst zum SuRunner zu machen läßt sich prächtig die Systemsteuerung verwenden: Bei Admins wie bei uneingeschränkten SuRunnern öffnet sich der SuRun-Dialog ganz einfach, bei eingeschränkten und blinden SuRunnern dagegen nicht (by Design) und Nicht-SuRunner bekommen hier den Dialog, mit dem sie sich nach Kennwort-Eingabe zum SuRunner machen können. Der Weg über die Systemsteuerung ist im übrigen mehr als konsequent, denn jeder Windows-Benutzer ist daran gewöhnt, das wichtige (und weniger wichtige) Änderungen im System über die Systemsteuerung erfolgen; und das es sich hier um etwas wichtiges handelt, ist nun wirklich jedem SuRun-Anwender klar, denn sonst würde er sein Windows munter weiter als Admin betreiben.

Natürlich gilt auch hier: Ist die Option, niemanden zu fragen, aktiviert, machen Kontextbefehle nun für Nicht-SuRunner (wie für Admins) nun wirklich nicht den geringsten Sinn mehr, sondern sind zu dieser Option widersprüchlich.

Bleibt noch die Frage, ob es sinnvoll ist, das Erscheinen der verschiedenen Kontextbefehle für die 3 SuRunner-Subtypen zu unterscheiden. Das sehe ich auch bei längerem Nachdenken nicht. Ich hatte in meiner Beobachtung schon geschrieben, zu welcher Unlogik das führen kann (auch wenn man das ganze auflöst, indem man den Zeitdialog automagisch starten läßt - noch nicht getestet). Eingeschränkte und blinde SuRunner werden logischerweise mehr Kontextbefehle im normalen Kontextmenü finden, die sie gar nicht verwenden können, als man durch dieses Ausblenden entfernen kann. Das es diese unwirksamen Befehle gibt, ist für diese Subtypen so gewollt, da braucht man keine "Filterung", die sich nicht immer so verhält, wie man es erwartet und Potential für neue Probleme schafft.

Zusammenfassung: Filterung der Kontextbefehle ja, aber konsequent. In der jetzigen Form provozieren sie irrtümliche Bugmeldungen, weil das Verhalten nicht logisch erscheint.
Thomas
cmb #11
Mitglied seit 11/2007 · 63 Beiträge
Gruppenmitgliedschaften: Mitglieder
Profil anzeigen · Link auf diesen Beitrag
Antwort auf Beitrag #9
Zitat von Kay:
Hier:
HKEY_CLASSES_ROOT\batfile\shell\SuRun
HKEY_CLASSES_ROOT\cmdfile\shell\SuRun
HKEY_CLASSES_ROOT\cplfile\shell\SuRun
HKEY_CLASSES_ROOT\exefile\shell\SuRun
HKEY_CLASSES_ROOT\MSCFile\Shell\SuRun
HKEY_CLASSES_ROOT\regfile\shell\SuRun
HKEY_CLASSES_ROOT\Msi.Patch\shell\SuRun open
HKEY_CLASSES_ROOT\Msi.Package\shell\SuRun open
HKEY_CLASSES_ROOT\Msi.Package\shell\SuRun repair
HKEY_CLASSES_ROOT\Msi.Package\shell\SuRun Uninstall


sollte nicht auch unter

HKEY_CLASSES_ROOT\lnkfile\shell

etwas für SuRUn eingetragen sein, damit Verknüpfungen Rechtsklick-Einträge für SuRun aufweisen?

für lnkfile hat es bei mir nämlich nichts mit SuRun in der Registry

- Clemens
Dieser Beitrag wurde am 13.08.2008, 22:23 von cmb verändert.
Cosmo #12
Mitglied seit 03/2008 · 451 Beiträge
Gruppenmitgliedschaften: Mitglieder
Profil anzeigen · Link auf diesen Beitrag
Clemens, dein Problem betreffend:

Guck doch mal in ein anderes Konto, zum Beispiel das des Admins, eventuell erstell testweise ein neues eingeschränktes Konto; vielleicht ist an dem Konto was kaputt (obwohl ich zugebe, daß beim Auftreten auf 2 Rechnern das eher nicht so aussieht).
Thomas
Kay (Administrator) #13
Benutzertitel: Weltverbesserer
Mitglied seit 11/2007 · 1464 Beiträge · Wohnort: Magdeburg
Gruppenmitgliedschaften: Administratoren, Mitglieder
Profil anzeigen · Link auf diesen Beitrag
Antwort auf Beitrag #9
Zitat von cmb:
alle von Dir erwähnten registry-Einträge sind da (habe extra Update ohne "Verknüpfungen behalten" gemacht) und wenn ich ein entsprechendes file im Explorer rechtsklicke sind die SuRun-Einträge "Starte als..." auch da,

aber egal, welche Verknüpfung ich rechtsklicke, ob im Startmenü oder sonstwo (z.:B. Desktop oder Quickstartleiste) habe ich keinen "Starte als"-Eintrag im Rechtsklick... lediglich der Rechtsklick auf den Desktop-Hintergrund zeigt den "Systemsteuerung als Admin"-Eintrag...

also ich kann mir da keinen Reim drauf machen... zumal das auf 2 Maschinen so ist...

kann das ein Rechteproblem sein? Zugriff auf gewisse Teile der Registry oder so?

Ein Rechteproblem ist das sicherlich nicht.
Vielleicht kann man per Kontext-Menü-Erweiterung die Standard-Einträge ausblenden/verhindern.(?)
...muss ich mal mit Ruhe untersuchen...
Kay (Administrator) #14
Benutzertitel: Weltverbesserer
Mitglied seit 11/2007 · 1464 Beiträge · Wohnort: Magdeburg
Gruppenmitgliedschaften: Administratoren, Mitglieder
Profil anzeigen · Link auf diesen Beitrag
Antwort auf Beitrag #11
Zitat von cmb:
sollte nicht auch unter
HKEY_CLASSES_ROOT\lnkfile\shell
etwas für SuRUn eingetragen sein, damit Verknüpfungen Rechtsklick-Einträge für SuRun aufweisen?

Nein: der LNK zeigt auf eine EXE und da ist SuRun drin. Zeigt LNK z.B. auf ein JPG, wird SuRun nicht gezeigt.
Kay (Administrator) #15
Benutzertitel: Weltverbesserer
Mitglied seit 11/2007 · 1464 Beiträge · Wohnort: Magdeburg
Gruppenmitgliedschaften: Administratoren, Mitglieder
Profil anzeigen · Link auf diesen Beitrag
Antwort auf Beitrag #6
Zitat von Cosmo:
Wenn es jetzt für einzelne Gruppen dann doch unterschiedliche Ergebnisse gibt, gehört das in die Kategorie "überraschend", und "überraschend" kann potentiell auf "falsch" hinweisen.
Solche Einstellungs-Schlenker gehören folglich in die Dokumentation.

Jepp, irgendwie schon.

Zitat von Cosmo:
Denn wo ist die Logik, bei einem Teil der Befehle zu sagen: Das dürfen die und die sowieso nicht, bei einem anderen Teil das aber nicht zu sagen, obwohl dasselbe zu 100% zutrifft?

Die Inkonsistenzen sind blöd, aber leider nicht leicht zu vermeiden.

Die Kontext-Menüs für Ordner erzeugt SuRun dynamisch über eine Shell-Erweiterung.
Diese Erweiterung schaut, ob der Benutzer das Menü sehen soll und zeigt es dann evtl. an.

Die Kontext-Menüs für exefile, cmdfile, cplfile, mscfile, batfile, Msi.Patch, Msi.Package, regfile, CLSID\\{21EC2020-3AEA-1069-A2DD-08002B30309D} (Systemsteuerung) stehen in "HKCR" und werden immer und bei allen Benutzern angezeigt.
Dass das so statisch ist, hat nur einen Grund: Ich starte manche Verknüpfungen mit Kommandozeilenparametern.
Diese Parameter verschluckt Windows, wenn es Shell-Erweiterungen für Ziele von LNK Dateien aufruft.

Ich könnte SuRun so umschreiben, dass Registry-Einträge bei Aufnahme eines Benutzers in die SuRunners in HKCU\Software\Classes (also nur für genau den Benutzer) erzeugt werden. Das würde aber Power-User, die eben diese Registry Geschichten ändern, nicht freuen.

Bisher ist es halt nicht konsistent. Vielleicht fällt mir noch ein, wie es einfach besser zu machen geht.

Zitat von Cosmo:
[OutLook Express]
Was spricht gegen meine Idee? Einfach zu realisieren, ebenso einfach reversibel (obwohl es dafür keinen Bedarf gibt).
Der SuRunner, der in diese Situation kommt, hat nicht einmal die Chance irgendwo (auch das steht aber gar nicht in der Dokumentation) nachzugucken, daß er Strg-Alt-Entf drücken soll. Er wird vor dem Monitor sitzen und denken: "Früher ging das immer sofort - also ist hier ein Fehler." Und wenn dann der SuRun-Desktop erscheint, wem wird er den Fehler zuordnen? Das sieht nicht nach etwas aus, was lange in einer "Nachdenken-Liste" bleiben darf.

Das ist nicht OE spezifisch. Mik.c.OS hatte schon mal diesen Fehler nachdem er Daemon-Tools installiert hat.
Wenn ein Installer per RunOnce Registry Key gestartet wird, schaltet WinLogon scheinbar den Desktop nicht um.

Ich muss raus bekommen, wie das doch geht und keine Ausnahme vorgeben.
Steht schon auf der ToDo-Liste ;-)
Schließen Kleiner – Größer + Auf diesen Beitrag antworten:
Prüfcode: VeriCode Gib bitte das Wort aus dem Bild ins folgende Textfeld ein. (Nur die Buchstaben eingeben, Kleinschreibung ist in Ordnung.)
Smileys: :-) ;-) :-D :-p :blush: :cool: :rolleyes: :huh: :-/ <_< :-( :'( :#: :scared: 8-( :nuts: :-O
Weitere Zeichen:
Seite:  1  2  3  4  5  6  nächste 
Gehe zu Forum
Nicht angemeldet. · Kennwort vergessen · Registrieren
This board is powered by the Unclassified NewsBoard software, 20150713-dev, © 2003-2015 by Yves Goergen
Seite erstellt in 280,4 ms (210,7 ms) · 134 Datenbankabfragen in 48,4 ms
Aktuelle Zeit: 23.05.2017, 20:35:39 (UTC +02:00)