Fenstergröße Systemdialoge festlegen

cumulonimbus8

Fleet Admiral
Registriert
Apr. 2012
Beiträge
19.483
Hallo!

Zu XP hatte ich mir dieses notiert:
XP Systemdialoge Fenstergröße selbst festlegen
Start, Ausführen, MMC. In der Liste im Datei-Menü können die letzten benutzen Tools aufgerufen werden. Wenn man die dann passend einrichtet muss man beim Schließen nur noch die Rückfrage bejahen.


Theoretisch kann ich der Anweisung folgen, aber es wird nichts gespeichert - bzw. wird sich nichts gemerkt. Rufe ich DiskMgmt.Msc über die MMC auf unterbleibt die Schließfrage, im Menü der so aufgerufenen Datenträgerverwaltung dibst zwar ein Speichern, aber das gelingt nicht: es wäre eine alte MMC-Version, und dann «kann die Konsole nicht gespeichert werden».

Wie kann ich unter 8 die Fenstergröße dieser Dialoge festnageln? Oder leide ich darunter, dass ich nur die Heimwerkerversion habe?

CN8
 
Ich hab das nur mal kurz nachgeschaut aber ich denke der grund warum dus nicht speichern kannst, ist dass die files im system32 dem TrustedInstaller gehören und du darfst das nicht überschreiben. Die Meldung wegen der alten version sagt doch eigentl dass du eine neuere Version hast als die mit der diskmgmt erstellt worden ist. Auf deinen Desktop kannst dus bestimmt speichern oder?

In dem Fall kannst dus entweder wo anders hin speichern (Wenn du die originale nicht verändern willst, kannst dus sogar in den PATH aufnehmen vor System32 und dann kannst dus normal aufrufen wie bisher über die konsole oder alternativ mit verknüpfung)
Oder du musst die Rechte auf der DiskMgmt.msc Datei ändern. Vielleicht reicht schon Schreibzugriff für einen der Administratoren oder du musst noch den Besitz übernehmen, dann solltest du sie ersetzen können, denk ich
 
Tja…

Offen gesagt steige ich bei der Logik des Speichern nicht durch: wozu ein Tool wenns faktisch nicht verwendbar ist?

Lassen wir mal grundsätzlich die Rechte im Moment außen vor, irgendwo(her) muss die Info potenziell stammen wie groß ein Fenster (z.B. die Datenträgerverwaltung) angezeigt wird. Wenn die aus den blockierten Originalen (und zwar an MMC vorbei!) stammt muss ich wohl doch an den Rechten schrauben eine Änderung genau dort zu erzwingen.
Liege ich schon mal mit der Denke richtig?

Warum wiederum diese neue native Installation mich mit «alter Version» konfrontiert mag wohl nur MS wissen…

CN8
 
So wie ich das sehe läuft das so. Aus Sicht von ms solltest du vermutlich prinzipiell die MMC direkt verwenden und dann kannst du mit der die ansichten für deine snap-ins speichern an orten wo du willst. Wenn du sie aufmachst, dann ist auch direkt immer "Konsole1" als name gewählt und bie jdem beenden fragt er dich ob du speichern willst. Es gibt aber für einige (alle?) snap-ins auch standard msc files für genau dieses mit den default einstellungen. Die liegen unter C:\Windows\System32 oder syswow64 vielleicht bei 64bit kann ich nicht sagen hab hier nur ein gerät mit win8. Die soll man wohl eigentlich nicht überschrieben vom use case her, das ist aber gar nicht der grund warum das speichern nicht geht.
Die windows system files kann man seit Win 7 schon offiziell nicht mehr überschreiben. Gibt einen eigenen User der die besitzt der selbst die admins ausperrt. Das ist allerdings ein grober allgemeiner schutz. Das hießt nicht dass das für jede datei immer sinnvoll ist, nur halt eben für die meisten, also kannst du den prinzipiell übergehen wenn du das willst, oder du speicherst deine ansicht wo anders hin.

Die meldung mit der alten version würd ich so interpretieren. Lobenswerter weise hat MS eine neue MMC version gemacht (weil eh schon genug gleich ist zwischen win7 und 8 da tut ein bisschen Fortschritt gut). Aber weil sich beim Diskmanagement vermutlich so gut wie nichts getan hat zwischen den version ist diese msc wohl einfach 100% gleich wie bei win 7 oder vielleicht sogar xp. Wenn dus jetzt neu speicherst kriegst du halt die warnung dass du das davor so auch auf einem windows xp pc aufmachen hättest können und die neue datei geht halt nur mehr mit win 8 und neuer auf. Ist natürlich ein bisschen eine seltsame warnung weil msc files zwischen pcs hin und her zu verwenden ist wohl kaum üblich, aber nichts was dir sorgen machen muss.

So würd ich das zumindest sehen ohne jetzt genauere insider informationen zu haben
 
Die alte Version bezieht sich offensichtlich auf die Konsole die ich speichern will - wenn ich das beim Schließen der Datenträgerverwaltung so weit korrekt verstehe, dass eine ›globale‹ Konsole gesichert werden soll und keine eigene für die Datenträgerverwaltung allein.

Wenn ich (was im Resultat auch nicht klappte…) eine Konsole anderswo speichere und öffne - was in dem Sinne ja sinnfrei ist da es ja nur um deren Einstellungen geht, hier Datenträgerverwaltung, die auszuwerten ich wünsche - dann bekomme ich die Datenträgerverwaltung dennoch nicht neu skaliert.

Das heißt aber auch, dass so ein Extraspeichern nichts bringt wenn sich immer am geschützten Original orientiert wird. Wie würde ich denn WIN überreden sich meiner geänderten Konsole zu bedienen wenn ich etwa die Datenträgerverwaltung direkt starte?

CN8
 
Vielleicht kriegst du ja eine andere meldung als ich, aber die die ich gekriegt habe ist inhaltlich genau die selbe die du kriegst wenn du ein xls file mit Excel 2007 oder höher als xlsx speicherst. Sie bedeutet: "Achtung, du hast eine Datei geöffnet die ein altes Format hat. Dein Programm unterstützt ein neueres Format und wird diese Datei in das neue Format umwandeln. Wenn du diese Datei noch mit dem alten Programm aufmachen willst mit dem sie erstellt wurde, mach das besser nicht."

Also wenn du die Einstellungen für die Datenträgerverwaltung in ein anderes File speicherst auf den Desktop, und dann dieses File am Desktop wieder aufmachst, dann hast du nicht die geänderten Fenstergrößen? Versteh ich dich da richtig?
 
Dieser Murks á la MS lässt mich nicht los.

Also - ich müsste eine C:\Windows\System32\diskmgmt.msc verändern, das rät mir der Speichern-Unter-Dialog unter MMC. Selbiges scheint mangels Rechten offensichtlich nicht zu gehen.
Ich öffne mal mutig C:\Windows\System32\ und kopiere die diskmgmt.msc zur diskmgmt1.msc. Das geht, guck an. Ich kann die Datei auch aufrufen - nur nicht geändert speichern. Da Kopieren = Erzeugen geht müsste ich doch wohl dazu Rechte genug haben??

So werfe ich mal die diskmgmt1.msc in NotePad++. Will ich speichern werde ich höflich gefragt zu prüfen ob die Datei nicht von einem anderen Programm geöffnet wäre. Aha. Fragt sich zwar wie und von welchem; jedenfalls kann ich meine soeben erzeugte (= geschriebene!) Kopie, deren Besitzer mit allen Rechten ich bin, nicht (über)schreibend speichern.

Wo ist da die Logik?
Und wenn es eine Rechtefrage ist wie behebe ich diese?

CN8
 
cumulonimbus8 schrieb:
Und wenn es eine Rechtefrage ist wie behebe ich diese?
Du musst Notepad++ auch mit Adminrechten starten, sonst ist es nur logisch, dass du auf die Datei keinen Zugriff hast. Ein Kopieren der Datei überschreibt nun mal den Inhalt und nicht dessen ursprüngliche Rechte mit den neuen. Wenn müsstest du dafür andere Tools verwenden, die auch die ACLs mit kopieren.
 
Es ist mit Sicherheit extrem interessant wieso wenn es mit der datei geht solang sie diskmgmt1.msc heißt, aber sobald du sie umbenennst in diskmgmt.msc die selbe datei nichtmehr funktioniert. Da scheint mir eine komplett absurde mechanik dahinter zu stecken, aber leider steig ich nicht dahinter wie das sein kann und hab vermutlich auch nicht die zeit das auszutüfteln.

Ich würde dir vorschlagen das Problem zu umgehen indem du einen neuen ordner machst, C:\msc oder so und darin alle mscs die du gerne anders gespeichert hättest mit dem Orginalnamen ablegst. Dann fügst du diesen Ordner zu deiner Pfadvariable VOR C:\Windows\System32 hinzu. Danach (möglicherweise Neustart erforderlich aber nicht sicher) solltest du eigentlich alles wie gehabt bedienen können auch von der commandline, bzw dem "run" Dialog.

@Yuuri: Das sind Files die dem TrustedInstaller gehören, wenn er da rechte will muss er erst die Ownership übernehmen imo, mit Admin allein geht das nicht. Aber es scheint bei diesen speziellen files nichts zu nützen ich habs ausprobiert... sobald man diskmgmt1 in diskmgmt umbenennt gibt es wieder die selbe merkwürdige problematik.
 
@Yuuri:
Wo soll die perverse Logik sein meine Datei die ich kopiert = angelegt habe mit einem Editor mit Adminrechten bearbeiten zu müssen?

Was ich öffne muss mit meinen Rechten (id est: die am Objekt existenten) geöffnet sein, gleichgültig was das Tool selbst kann/darf - denn sonst hätte es (konsequente Logik) das File gar nicht erst damit öffnen dürfen: wenn schon - denn schon!

Aber sch. egal: Ich wollte die gpedit.msc (deren Schreibrechte ich besitze, hier auf einem anderen System, von außen zurückkopieren: «Zugriff auf den Zielordner […\System32] wurde verweigert»!!! Microschrott im Quadrat! Mach’ ich dasselbe unter Novell oder Unix komme ich an diese spezielle Datei ran, völlig wumpe welche Rechte auf dem Ordner liegen! Wären die wirklich von Bedeutung dürfte ich eigentlich da drin mir auch keine Rechte auf die Datei geben können!
Inkonsequenter Bockmist - auch, weils simple Anpassungen kalt verhindert.

Noch wage ich nicht den TrustedInstaller als Besitzer von System32 rauszuwerfen… Noch… Denn offensichtlich kann ich den Kameraden nicht weder zurück in Amt und Würden bringen. Wirklich haarsträubender Unsinn an Inkonsequenz.

CN8
 
Das sind NTFS rechte, die werden von Linux ignoriert das war schon immer so. Wenn du möchtest dass niemand dir da reinpfuscht mit Linux --> Bitlocker. Und das ganze UAC TrustedInstaller zeug ist halt hauptsächlich ein Schutz vor unachtsamen Usern...

Anyway wenn du die Rechte wieder herstellen willst, dann mach eine Backup copy mit allen ACL rechten, aber wie ich dir bereits gesagt habe wird das aus mir bisher noch unklaren Gründen nichts bringen, sobald du die datei ersetzt "spinnts wieder rum", was hast du gegen die Methode mit der PATH variabel? Die sollte einwandfrei funktionieren, ersetzt keine System files und hat diesen ultra oldschool touch...
 
PATH?! Was hab ich da übersehen?
Sagen wir so - ich würde halt gerne beim Systemdialog im WIN-Kontextmenü (hüstel…) bleiben. Dass mir ein Befehl (als Verknüpfung) C:\Windows\System32\mmc.exe D:\irgendwo\diskmgmt1.msc mit einer getunten diskmgmt1.msc auf die Blüte hilft ist klar. Ich wäre aber auch bei PATH handwerklich nicht besser dran, nicht wahr?
Dieser Würgaround tut, ist aber eben nicht würglich die Erfüllung.

Vielleicht war ich gestern nicht richtig wach… Oder eine Dateisystemschutz hat zugeschlagen. Wenigstens meine ich per Knoppix diese diskmgmgt1.msc als diskmgmt.msc in \System32 geparkt zu haben - aber es ist das Original das da ist…

Wenn du möchtest dass niemand dir da reinpfuscht mit Linux --> Bitlocker.
Habe ich 2. nicht und 1. würde ich selbst mit reinpfuschen wenn WIN mich ließe.

CN8
 
cumulonimbus8 schrieb:
Ich wäre aber auch bei PATH handwerklich nicht besser dran, nicht wahr?
Dieser Würgaround tut, ist aber eben nicht würglich die Erfüllung.
Mit der anpassung von %PATH% bist du immer besser dran, denn so werden nie irgendwo System- bzw. Standarddateien überschrieben und du kannst somit alles wieder durch ein paar Klicks auf den Ursprungszustand zurücksetzen, ohne große Backups einzuspielen.

Mein %PATH% ist z.B. komplett angepasst:
Code:
C:\Program Files (x86)\curl\curl-7.36.0-win32\bin
C:\Program Files (x86)\.scripts
C:\Program Files\Python\2.7.6
C:\Program Files (x86)\.path
C:\x64\Ruby200-x64\bin
%appdata%\npm
C:\Program Files\ImageMagick
%SystemRoot%\system32
%SystemRoot%
%SystemRoot%\System32\Wbem
%SYSTEMROOT%\System32\WindowsPowerShell\v1.0\
C:\Program Files (x86)\ATI Technologies\ATI.ACE\Core-Static
C:\Program Files\TortoiseGit\bin
C:\Program Files\Microsoft\Web Platform Installer\
C:\Program Files (x86)\Microsoft ASP.NET\ASP.NET Web Pages\v1.0\
C:\Program Files (x86)\Windows Kits\8.0\Windows Performance Toolkit\
C:\Program Files\Microsoft SQL Server\110\Tools\Binn\
C:\Program Files\TortoiseSVN\bin
C:\Program Files (x86)\Tesseract-OCR
C:\x64\nodejs\
C:\Program Files (x86)\Cygwin\bin
D:\Entwicklung\.path
C:\Program Files (x86)\php\5.5.10-nts
C:\ProgramData\ComposerSetup\bin
C:\Program Files (x86)\Windows Kits\8.1\Windows Performance Toolkit
C:\Program Files (x86)\.sysinternals
C:\Program Files\TortoiseHg\
C:\Program Files (x86)\Git\cmd
C:\Program Files (x86)\Windows Kits\8.1\Windows Performance Toolkit\
C:\Python27
C:\Python27\Scripts
C:\OpenSSL-Win32\bin
So kann ich von überall im System immer auf die hinterlegten Dateien in entsprechender Reihenfolge zugreifen, ohne Systemdateien verändern zu müssen. Deine diskmgmt.msc müsste ich ergo nur in bspw. C:\Program Files (x86)\.path kopieren und anpassen und schon wäre es angepasst, ohne an Rechten rumzuspielen, ohne Systemdateien zu verändern, ohne Backups anlegen zu müssen, ...
 
Zu Deutsch: eine Ordner für die Kopie der Datei usf. anlegen/wählen und den im Pfad vorne platzieren, vor den System-Ordnern.
Dann sag mir mal wie ich die Datenträgerverwaltung im Windows-Kachelbutton-Kontextmenü überrede das zu tun was ich will? Mit Path geht das nicht… Wenn ich so faktisch das Betriebssystem umschreiben soll indem ich eigene Befehlsketten baue taugt das doch wohl auch nicht. Wobei zu klären wäre welche EXE welche andere Datei (bzw.) wie aufrufen muss um zum Ziel zu kommen.

CN8
 
cumulonimbus8 schrieb:
Zu Deutsch: eine Ordner für die Kopie der Datei usf. anlegen/wählen und den im Pfad vorne platzieren, vor den System-Ordnern.
Zehn mal besser, als an Rechten herumzuspielen, Systemdateien zu ersetzen usw. usf. Wie du siehst, ist dein Thread seit dem 08.05. offen und du hast bisher immer noch keine Lösung.
cumulonimbus8 schrieb:
Dann sag mir mal wie ich die Datenträgerverwaltung im Windows-Kachelbutton-Kontextmenü überrede das zu tun was ich will?
Indem du die Einträge des Menüs änderst, denn diese werden standardmäßig in %systemroot% bzw. %windir% laufen.

Übrigens kannst du die Einträge komplett selbst anpassen. Wenn du dort Einträge anpassen willst (u.a. die Datenträgerverwaltung), gehst du einfach in den Pfad %localappdata%\Microsoft\Windows\WinX und passt dir da deine Sachen an. Die Datenträgerverwaltung liegt bei mir in Gruppe 3 an Platz 4 und die Verküpfung zeigt auf %windir%\system32\diskmgmt.msc. Da kannst du dann wunderbar auf deine eigene diskmgmt.msc verweisen und du bekommst die selbe MMC über das Win X Menü, sowie systemweit über bspw. den Ausführen-Dialog, außer irgendwas zeigt auf die originale Datei. Da aber, bleibt dir spätestens nur das Ersetzen bzw. der bessere Umweg über einen Symlink/Hardlink.
 
Ehrlich - warum schaffst du es nicht von dir aus simple, aber schlagkräftige, Infos wie den benannten Pfad
%localappdata%\Microsoft\Windows\WinX
rauszugeben und vorzuschlagen dort explizite Änderungen an den Pfadangaben auszulösen?

Meine Hilfslösung findet sich übrigens in #12. Die dort direkt aufgerufene MSC habe ich nun der Pseudo-Verknüpfung in Group3 verinnerlicht.

Als alter DOS-Fritze habe ich eine Abneigung was anderes als Systemordner vorne im Pfad zu parken. Ein Unfall oder eine gezielte, eigennützige ›Blockade‹ einer für andere wichtige Systemdatei und man hat die Krätze.

CN8
 
cumulonimbus8 schrieb:
Ehrlich - warum schaffst du es nicht von dir aus simple, aber schlagkräftige, Infos wie den benannten Pfad
%localappdata%\Microsoft\Windows\WinX
rauszugeben und vorzuschlagen dort explizite Änderungen an den Pfadangaben auszulösen?
Weil ich aus all deinen Posts nicht wirklich schlau werde. Wenn du das Problem ordentlich umschreiben würdest, mit vorangegangener (eigener) Recherche, könnte man dir auch besser helfen. Aber es kommen immer wieder stückweise Infos heraus, die dann irgendwann mal ein Ganzes und Sinn ergeben, ab welchem Punkt man dann mit Alternativen oder Lösungen ansetzen kann.

Im letzten Post gingst du erst drauf ein, dass es dich stört, dass es über das Win X Menü nicht so funktioniert...
cumulonimbus8 schrieb:
Als alter DOS-Fritze habe ich eine Abneigung was anderes als Systemordner vorne im Pfad zu parken. Ein Unfall oder eine gezielte, eigennützige ›Blockade‹ einer für andere wichtige Systemdatei und man hat die Krätze.
Das ist spätestens seit Vista passé, denn dazu gibts den WinSxS Ordner. Weiterhin werden beim anfordern einer DLL (wenn der Programmierer nicht zu dämlich ist) alle Ordner in %path% durchgegangen, bis die angeforderte DLL gefunden wurde. Wenn eine Anwendung spezifische Libs braucht, liefert diese evtl. sie selbstständig mit, denn das aktuelle Verzeichnis (bzw. Arbeitsverzeichnis) gilt immer als erster Suchort für Dateien.
 
cumulonimbus8 schrieb:
Als alter DOS-Fritze habe ich eine Abneigung was anderes als Systemordner vorne im Pfad zu parken. Ein Unfall oder eine gezielte, eigennützige ›Blockade‹ einer für andere wichtige Systemdatei und man hat die Krätze.
CN8

Wenn du deinen eigenen persönlichen Ordner für diese 2 .msc files die du ändern willst machst und dann plötzlich anfängst zufällig dll files da reinzudroppen dann ja. Wenn du das lässt... eher nicht...


Im übrigen kommt mir vor du willst eine extrem spezielle Sache machen. Zugegeben es gibt ein relativ irrationales Problem mit der alten Methode die du verwendet hast, aber daran kann man nichts ändern. Dafür können wir aber hier nichts.

Wir versuchen hier dir Möglichkeiten aufzuzeigen wie du deinen gewünschten Effekt dennoch erzielen kannst und meiner Meinung nach ist es mit den von Yuuri und mir vorgeschlagenen Workarounds möglich, dass du dein System so einrichtest dass du es zu 100% gleich bedienen kannst wie dus gewohnt bist, obwohl du ständig in irgendwelche rants gegen microsoft abdriftest.
Wenn du dann immer noch etwas an den Lösungen auszusetzen hast kommt mir langsam der Gedanke du möchtest vielleicht einfach nur mit Gewalt sagen können "Windows 8 ist scheiße weil das nicht geht". Um auf diesen Schluss zu kommen hättest du aber auch ein einfacheres Beispiel suchen können....
 
@Yuuri:
Ich kann nichts dafür wenn du nicht einfach die eingehende Frage…
Wie kann ich unter 8 die Fenstergröße dieser Dialoge festnageln?
…liest und darauf die Antwort gibst die dann später kam. Sollte diese Einfache Frage bereits zu wenige Infos sein tut mir das Leid.
Vielleicht hätte ich fragen müssen wie ich das allein unter Verwendung der üblichen Systemfunktionen (besagtes Windows-Kachelbutton-Kontextmenü) schaffe. Aber da ich auch nicht sagte ich wollte MMC direkt aufrufen wäre das Kontextmenü wohl der Ansatzpunkt.

@Syberdoor:
8 ist Murks. Selbst DOS war Murks. Milliarden User geben Rückmeldungen was an MS'schen Erfindungen nicht taugt, was an echter Praxis vorbeierfunden ist, was nicht stringent oder schlicht unlogisch ist.
Das werde ich erwähnen wenn es wie hier (Rechterverweigerung auf Konfig-Files aus dem offiziellen Bordwerkzeug selbst heraus) so ist. Denn was nicht erwähnt wird wird auch nicht geändert oder bedacht.
Schau dir doch die Horden an Fremdtools an, wie sie immer wieder in ganz spezielle Kerben hauen, seit gefühlt 20 Jahren. Von nichts kommt nichts.


@beide
Und genau dieses Wenn bietet genug Fallstricke bestimmte Lösungen auszulassen.
Ich bin nicht der DAU - aber ich kenne meine Schlaglochsuchgeräte. Ich weiß wie PATH arbeitet, aber es mag eben Gewohnheit sein diesen Weg nicht von selbst zu wählen. Oder Instinkt.

CN8
 
Mag alles sein (Deine SpeziellenProbleme und Merkwürdigkeiten kommen alle aus Win7 im übrigen ...) aber das ist hier nicht das Microsoft Feedback Forum. Wir (zumindest ich aber ich kanns mir kaum anders vorstellen bei Yuuri) würden viel lieber einfach nur helfen Probleme zu lösen als Abhandlungen über Microsofts Fähigkeiten oder nicht zu lesen. Wir können ja einen Begleitthread aufmachen für die Diskussion über Windows 8, wenn dir das so wichtig ist....


Zum Thema Fallstricke und bestimmte Lösungen auslassen...
Schau dir an wann ich auf den Thread das erste mal geantwortet hab. Ich hab fast eine Woche gewartet obwohl ich ihn gleich gesehen hab. Das hab ich deswegen gemacht weil ich mich nicht qualifiziert gefühlt habe, die Sache "100% richtig" zu lösen, und ich den Thread nicht aus den "unbeantworteten" auf der Startseite nehmen wollte ohne wirklich helfen zu können. Daher wollte ich potentiell besser bewanderten den Vorzug lassen. Nachdem sich aber niemand gefunden hat dachte ich "Besser für dich wenn ich dir Ansätze und Workarounds liefere als wenn gar niemand schreibt...".

Kann gut sein dass es eine bessere (und potentiell enorm kompliziertere) Lösung gibt aber es scheint so als wüsste sie hier niemand. Du kannst mit uns gemeinsam versuchen das so hinzubasteln dass es bei jedem klick tut was du dir wünscht obwohls verschiedene Workarounds verwendet oder du musst vielleicht ein anderes Forum (vielleicht technet?) versuchen fürcht ich....
 
Zurück
Oben