[honx]

hab mir heute zur sicherheit eine kopie der thunderbird.exe gemacht, damit mir das gute alte thunderbird icon erhalten bleibt, nachdem ich gelesen hab, dass auch mozilla vorhat, das logo und das icon von thunderbird zu ändern.

als ich besagte kopie der thunderbird.exe erstellt hab, sind in der ereignisanzeige folgende zwei fehler aufgetaucht. was genau wollte thunderbird da versuchen? was wollen mir diese beiden fehler sagen?

ist ja nicht so, dass ich jene kopie der thunderbird.exe ausführen wollen würde. ich hab besagte kopie wie gesagt einzig und allein nur deswegen angelegt, da ich das altbekannte thunderbird icon behalten will, nachdem ja nun auch mozilla mal wieder unbedingt einen auf "veränderung" machen muss...
"change for the sake of change" - ich hasse das!!!

hier beide fehler:

Protokollname: ApplicationQuelle: SideBySide
Datum: 10.07.2023 07:52:10
Ereignis-ID: 33
Aufgabenkategorie:Keine
Ebene: Fehler
Schlüsselwörter:Klassisch
Benutzer: Nicht zutreffend
Computer: GameWorkstation
Beschreibung:
Fehler beim Generieren des Aktivierungskontextes für "E:\z_dl\misc\#bak\thunderbird.exe". Die abhängige Assemblierung "mozglue,language="*",type="win32",version="1.0.0.0"" konnte nicht gefunden werden. Verwenden Sie für eine detaillierte Diagnose das Programm "sxstrace.exe".
Ereignis-XML:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Provider Name="SideBySide" />
<EventID Qualifiers="49409">33</EventID>
<Level>2</Level>
<Task>0</Task>
<Keywords>0x80000000000000</Keywords>
<TimeCreated SystemTime="2023-07-10T05:52:10.000000000Z" />
<EventRecordID>150804</EventRecordID>
<Channel>Application</Channel>
<Computer>GameWorkstation</Computer>
<Security />
</System>
<EventData>
<Data>mozglue,language="&amp;#x2a;",type="win32",version="1.0.0.0"</Data>
<Data>
</Data>
<Data>
</Data>
<Data>
</Data>
<Data>
</Data>
<Data>
</Data>
<Data>
</Data>
<Data>
</Data>
<Data>
</Data>
<Data>
</Data>
<Data>E:\z_dl\misc\#bak\thunderbird.exe</Data>
<Data>
</Data>
<Data>
</Data>
<Data>
</Data>
<Data>
</Data>
<Data>
</Data>
<Data>
</Data>
<Data>
</Data>
<Data>
</Data>
<Data>
</Data>
</EventData>
</Event>

Protokollname: ApplicationQuelle: SideBySide
Datum: 10.07.2023 07:52:10
Ereignis-ID: 33
Aufgabenkategorie:Keine
Ebene: Fehler
Schlüsselwörter:Klassisch
Benutzer: Nicht zutreffend
Computer: GameWorkstation
Beschreibung:
Fehler beim Generieren des Aktivierungskontextes für "E:\z_dl\misc\#bak\thunderbird.exe". Die abhängige Assemblierung "mozglue,language="*",type="win32",version="1.0.0.0"" konnte nicht gefunden werden. Verwenden Sie für eine detaillierte Diagnose das Programm "sxstrace.exe".
Ereignis-XML:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Provider Name="SideBySide" />
<EventID Qualifiers="49409">33</EventID>
<Level>2</Level>
<Task>0</Task>
<Keywords>0x80000000000000</Keywords>
<TimeCreated SystemTime="2023-07-10T05:52:10.000000000Z" />
<EventRecordID>150803</EventRecordID>
<Channel>Application</Channel>
<Computer>GameWorkstation</Computer>
<Security />
</System>
<EventData>
<Data>mozglue,language="&amp;#x2a;",type="win32",version="1.0.0.0"</Data>
<Data>
</Data>
<Data>
</Data>
<Data>
</Data>
<Data>
</Data>
<Data>
</Data>
<Data>
</Data>
<Data>
</Data>
<Data>
</Data>
<Data>
</Data>
<Data>E:\z_dl\misc\#bak\thunderbird.exe</Data>
<Data>
</Data>
<Data>
</Data>
<Data>
</Data>
<Data>
</Data>
<Data>
</Data>
<Data>
</Data>
<Data>
</Data>
<Data>
</Data>
<Data>
</Data>
</EventData>
</Event>

[Nobbi Habogs]

Du kannst auch nur das Icon extrahieren, hatte mal nen Tool dafür. Es können ja auch mehrere Icons in der Exe gespeichert sein.

[jabu]

ist ja nicht so, dass ich jene kopie der thunderbird.exe ausführen wollen würde.

Die hier von dir angebrachte Fehlermeldung besagt, dass du sie doch ausgeführt hast (sei es aus Neugier oder versehentlich, Gründe sind egal (ist nicht als Kritik gemeint!)), und zwar von deinem mutmaßlichen Backup-Pfad aus, also wohl isoliert von der Umgebung, die thunderbird.exe zum Ausführen benötigt.

Im eingebetteten Manifest der thunderbird.exe ist eingetragen, dass thunderbird.exe von der (speziell hier nicht auffindbaren und sonst beiliegenden) mozglue.dll abhängig ist:

<dependency>
        <dependentAssembly>
                <assemblyIdentity
                        type="win32"
                        name="mozglue"
                        version="1.0.0.0"
                        language="*"
                />
        </dependentAssembly>
</dependency>

Da diese Verfahrensweise für die Side-by-side-assemblys (ein Teil der Maßnahmen zum Beseitigen der DLL-Hölle) eingeführt wurde, erhältst du die dazu passende Fehlermeldung. Entfernt man diesen Abschnitt aus dem Manifest, so verschwindet diese spezielle Fehlermeldung (wonach die nächsten kommen, denn die zum Ausführen erforderliche Umgebung fehlt nach wie vor).

Die Fehlermeldung ist also normal.

Ich möchte davon abraten, ausführbare Dateien außerhalb der für sie vorgesehenen Umgebung auszuführen, da dieses teils zu nicht überschaubaren Konsequenzen führen kann. Hier hast du Glück, indem das Manifest frühzeitig die Ausführung unterbindet. Aber bereits mit der mozglue.dll dabei wäre dieses Unterbinden (zumindest so frühzeitig) nicht mehr gegeben.

Von einem Mischen von Programmbestandteilen kann ich nur abraten (von wenigen Ausnahmen abgesehen, z.B. wenn man selber der Entwickler ist). Ein Austauschen einer Icon-Ressource kann dagegen aus rein technischer Perspektive (rechtlich ist das manchmal anders) als in den meisten Fällen unproblematisch angesehen werden. Es ist jedoch nicht garantiert, dass ein Tool zum Austauschen von Ressourcen immer alles richtig macht (es muss mit dem Windows-PE-Format fehlerfrei umgehen*). Zudem kann es nicht wissen, wie das Programm mit einer Ressource umgeht (ggf. über das Prozedere von Windows hinaus). Ich würde also vorsichtshalber Ressourcen nur gegen gleich große vom selben Inhaltstyp tauschen (es sei denn, man weiß es besser).

*weswegen es nicht schaden sollte, sich nach Tools umzusehen, deren Ersteller sich das Verstehen und Beherrschen des Windows-PE-Formates zum Ziel gesetzt und dieses auch erreicht haben. Dabei kann es sich zum Beispiel um von vertrauenswürdigen(!) Reverse-Engineering-Experten erstellte Tools ab dem nötigen Reifegrad handeln. Von Tools, bei denen man das nicht so genau beurteilen kann, würde ich grundsätzlich nur gleich große Ressourcen einsetzen lassen, und zwar in einer Weise, bei der sich an den Daten nichts verschiebt (1:1-Patch, der die Dateigröße nicht ändert, wie beim einfachen Hantieren mit einem Hex-Editor). Ressourcen, die von Windows ausgelesen werden können, sind zwar relativ leicht zu beherrschen, aber das schließt Fehler nicht aus.

Ich würde vorsichtshalber mit einem Hex-Editor, der Dateien vergleichen kann (z.B. HxD von Maël Hörz soll das können), hinterherkontrollieren, und zwar um sicherzustellen, dass keine Änderungen außerhalb eines ununterbrochenen Abschnittes erfolgt sind und dass beide Abschnitte gleich groß sind. Falls dieses zutrifft (und nachher das Icon vom Programm korrekt dargestellt wird), ist das zum Tauschen der Ressource verwendete Werkzeug nicht mehr so kritisch. Mit einer solchen Kontrolle kann man zur Not ein Tool von einem wenig erfahrenen Programmierer nehmen, z.B. weil es bequem ist.

[honx]

Die hier von dir angebrachte Fehlermeldung besagt, dass du sie doch ausgeführt hast (sei es aus Neugier oder versehentlich, Gründe sind egal (ist nicht als Kritik gemeint!)), und zwar von deinem mutmaßlichen Backup-Pfad aus, also wohl isoliert von der Umgebung, die thunderbird.exe zum Ausführen benötigt.

da muss wohl wieder der verdammte doppelklick-bug meiner mouse zugeschlagen haben; das war also nicht ich (schon gar nicht absichtlich), das war meine scheiss mouse... mir ist nämlich sehr wohl klar, dass eine einzelne .exe aus einem programmpfad herauskopiert gar nicht ausführbar sein wird, da gibts auch keine "neugier" zu befriedigen... ich hab zwar nicht viel ahnung von windows und dergleichen, aber ich hab zumindest ausreichend gesunden hausverstand, um zumindest sowas zu wissen...

Da diese Verfahrensweise für die Side-by-side-assemblys (ein Teil der Maßnahmen zum Beseitigen der DLL-Hölle) eingeführt wurde, erhältst du die dazu passende Fehlermeldung. Entfernt man diesen Abschnitt aus dem Manifest, so verschwindet diese spezielle Fehlermeldung (wonach die nächsten kommen, denn die zum Ausführen erforderliche Umgebung fehlt nach wie vor).

Die Fehlermeldung ist also normal.

Ich möchte davon abraten, ausführbare Dateien außerhalb der für sie vorgesehenen Umgebung auszuführen, da dieses teils zu nicht überschaubaren Konsequenzen führen kann. Hier hast du Glück, indem das Manifest frühzeitig die Ausführung unterbindet. Aber bereits mit der mozglue.dll dabei wäre dieses Unterbinden (zumindest so frühzeitig) nicht mehr gegeben.

kann ich irgendwie auf nummer sichergehen, ob auch wirklich nichts passiert ist? jedenfalls kann ich thunderbird starten, auch emails werden abgerufen.
da thunderbird aktuell ist, kann ich folglich gegenwärtig nicht testen, ob thunderbird updates immer noch funktionieren...
was genau hätte dabei kaputtgehen können? thunderbird installation selbst unter programme (x86) oder auch das profil?

Von einem Mischen von Programmbestandteilen kann ich nur abraten (von wenigen Ausnahmen abgesehen, z.B. wenn man selber der Entwickler ist). Ein Austauschen einer Icon-Ressource kann dagegen aus rein technischer Perspektive (rechtlich ist das manchmal anders) als in den meisten Fällen unproblematisch angesehen werden. Es ist jedoch nicht garantiert, dass ein Tool zum Austauschen von Ressourcen immer alles richtig macht (es muss mit dem Windows-PE-Format fehlerfrei umgehen*).

ich hatte auch NIEMALS vor, das icon in der thunderbird.exe-datei auszutauschen! das wurde missverstanden!
im fall des bevorstehenden icon-wechsels bei thunderbird hab ich lediglich vor, der VERKNÜPFUNG zu thunderbird ein anderes icon (nämlich das alte) zuzuweisen, indem ich als icon-pfad zum backup der thunderbird.exe mit dem alten icon verweise. und das dürfte wohl kaum ein problem sein, wenn ich lediglich einer VERKNÜPFUNG eine andere .exe-datei als icon anbinde... andernfalls dürfte es diese möglichkeit nämlich gar nicht geben, einer verknüpfung ein anderes symbol zuzuweisen, wenn man auf dem wege tatsächlich etwas kaputt machen können würde...

[jabu]

da muss wohl wieder der verdammte doppelklick-bug meiner mouse zugeschlagen haben; das war also nicht ich (schon gar nicht absichtlich), das war meine scheiss mouse... mir ist nämlich sehr wohl klar, dass eine einzelne .exe aus einem programmpfad herauskopiert gar nicht ausführbar sein wird, da gibts auch keine "neugier" zu befriedigen... ich hab zwar nicht viel ahnung von windows und dergleichen, aber ich hab zumindest ausreichend gesunden hausverstand, um zumindest sowas zu wissen...

Diese verdammten Mäuse, müssen sogar die Exes anknabbern.

kann ich irgendwie auf nummer sichergehen, ob auch wirklich nichts passiert ist?

thunderbird.exe wurde durch die Fehlerbehandlung bezüglich der fehlenden Assembly (so heißen die in Manifesten verzeichneten Abhängigkeiten) komplett am Ausführen gehindert. Es wurde kein Prozess gestartet. Ich glaube, dass es sicherer nicht geht.


Das passiert, falls der Eintrag im Manifest weggelassen wird:

Normalerweise würde der Programmlader die mozglue.dll nicht finden und mit Fehlermeldung abbrechen, wobei zwar ein Prozess gestartet werden würde, dieser aber bereits vor jeglicher Codeausführung gestoppt werden würde (was gut wäre). Jedoch nicht hier, da die mozglue.dll, obwohl nicht beiliegend, (bei fehlendem Manifesteintrag) trotzdem gefunden wird, was zu einer teilweisen Ausführung führt. Huch, Geister am Werk? Woher findet der Programmlader von Windows die mozglue.dll, wenn sie sich nicht im selben Verzeichnis befindet?

Dazu muss man wissen, dass DLLs auch im Suchpfad (den die Umgebungsvariable "Path" enthält) gefunden werden. Aber dort ist "C:\Program Files\Mozilla Thunderbird\thunderbird.exe" doch nicht eingetragen. Oder doch?

Schauen wir uns mal an, was ich aus der Registry habe exportieren lassen:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\thunderbird.exe]
@="C:\\Program Files\\Mozilla Thunderbird\\thunderbird.exe"
"Path"="C:\\Program Files\\Mozilla Thunderbird"

Damit wird jeder ausführbaren Datei, die "thunderbird.exe" heißt, egal wo sie liegt und was das ist, in ihrer Ausführungsumgebung der Suchpfad so modifiziert, dass ihm der Pfad "C:\Program Files\Mozilla Thunderbird" vorangestellt wird. Also ist der Pfad doch entsprechend erweitert, jedoch nur aus der Sicht einer ausführbaren Datei, die "thunderbird.exe" heißt.

Da der Programmlader von Windows in Suchpfaden nach DLLs sucht, findet er dadurch die mozglue.dll, was potenziell eine fehlerhafte Ausführung ermöglicht - aber nicht mit dem Eintrag im Manifest! Denn dieser weist den Programmlader an, nur Assemblys aus dem Verzeichnis der abhängigen ausführbaren Datei (hier: "thunderbird.exe") einzubeziehen (eine effektive Isolation von Erweiterungen der Umgebung). Falls sich dort keine mozglue.dll finden lässt, wird kein Prozess gestartet. Ohne dass ein Prozess gestartet wird, wird kein Programmcode ausgeführt.

jedenfalls kann ich thunderbird starten, auch emails werden abgerufen.
da thunderbird aktuell ist, kann ich folglich gegenwärtig nicht testen, ob thunderbird updates immer noch funktionieren...
was genau hätte dabei kaputtgehen können? thunderbird installation selbst unter programme (x86) oder auch das profil?

Wie oben geschildert, konnte nichts kaputtgehen, da kein Prozess gestartet wurde. Ohne die Assembly-Isolation per Manifest wäre Code ausgeführt worden, wobei es zu einer Fehlermeldung gekommen wäre, die besagt, dass XPCOM (das Erweiterungsframework von Mozilla) nicht geladen werden kann. Thunderbird wäre also ein Stück weiter gekommen. Es wäre hierbei bezüglich der Folgen darauf angekommen, ob die Fehlerbehandlung korrekt ist. Bei mir ist nichts passiert. Ich wollte nämlich gucken, wie weit Thunderbird kommt, wenn man den besagten Eintrag aus dem Manifest entfernt, um es dir mitzuteilen. Bei der o.g. Fehlermeldung ist bei fehlendem Manifesteintrag Schluss. Profile würden sinnvollerweise erst später (ohne den Abbruch bei der Fehlermeldung) geladen werden. Aber das ist ja nur in meinem Fall relevant, da ich den Eintrag aus der Manifest-Ressource der thunderbird.exe entfernt und damit eine Ausführung erst ermöglicht habe - wogegen es in deinem Fall nicht zur Ausführung kommen konnte.

ich hatte auch NIEMALS vor, das icon in der thunderbird.exe-datei auszutauschen! das wurde missverstanden!
im fall des bevorstehenden icon-wechsels bei thunderbird hab ich lediglich vor, der VERKNÜPFUNG zu thunderbird ein anderes icon (nämlich das alte) zuzuweisen, indem ich als icon-pfad zum backup der thunderbird.exe mit dem alten icon verweise. und das dürfte wohl kaum ein problem sein, wenn ich lediglich einer VERKNÜPFUNG eine andere .exe-datei als icon anbinde... andernfalls dürfte es diese möglichkeit nämlich gar nicht geben, einer verknüpfung ein anderes symbol zuzuweisen, wenn man auf dem wege tatsächlich etwas kaputt machen können würde...

Ideen dazu:
1. Das Icon extrahieren.
2. Wenn man für 1. zu bequem ist, dann kann man die thunderbird.exe zum Beispiel in thunderbirdicon.dll umbenennen und sich darüber freuen, dass DLLs auch das Windows-PE-Format haben, mit exakt derselben Art von Ressourceneinbindung, weswegen das problemlos funktioniert. Windows selbst stellt die systemeigenen Icons per DLLs bereit. Das Format von Exes und DLLs ist dasselbe. Seine Nutzung unterscheidet sich meistens bereits bei der Programmierung etwas, nicht sein grundsätzlicher Aufbau. So lassen sich zum Beispiel aus Exes ebenso wie aus DLLs Funktionen exportieren. Sogar Microsoft selbst hat das in einigen wenigen Fällen genutzt. Die Möglichkeit ist beabsichtigt. Im Header der Datei ist verzeichnet, um welche Art von ausführbarer Datei es sich handeln soll. Mit dieser Unterscheidbarkeit kann der Programmlader nämlich eine unbeabsichtigte direkte Ausführung oder eine Ausführung im falschen Kontext verhindern und auf Besonderheiten eingehen.

[honx]

umbenennen in eine .dll wäre durchaus eine option, wäre mir nie eingefallen.
extrahieren eines icons aus einer ausführbaren datei - weiss ich noch nicht.
sind solche tools wie das hier im thread verlinkte "icons from file" sicher?

[jabu]

umbenennen in eine .dll wäre durchaus eine option, wäre mir nie eingefallen.

Es ginge bei der Umbenennung nur darum, dass du die Datei nicht so leicht versehentlich ausführen würdest und der Name weniger etwas Falsches vermuten ließe. Mir könnte das helfen, falls ich mich gerade nicht erinnern kann, was das mit der Exe soll. Wenn ich wegen des Namens eine DLL als Behälter für Icons vermuten kann, dann würde mir das helfen, auf den richtigen gedanklichen Pfad zu kommen, auch nach vielen Jahren noch.

extrahieren eines icons aus einer ausführbaren datei - weiss ich noch nicht.

Falls du es nicht extrahierst, so behältst du die verschiedenen Auflösungen des Icons in der Datei bei, was Unschärfen vorbeugt, indem Windows sich das Icon mit der passenden Auflösung heraussuchen kann (je nachdem, wie groß man sich Icons anzeigen lässt).

sind solche tools wie das hier im thread verlinkte "icons from file" sicher?

Man kann dabei nur dem Autor und der Quelle, aus der man die Software bezieht, vertrauen oder nicht, wie bei anderer Software, bei der man keine Quelltextanalyse (vor dem Selberkompilieren) vorgenommen hat.

Oder meinst du eine andere Art von Sicherheit, z.B. Schutz vor Schäden durch Fehlbedienung? Das ist auch höchst unterschiedlich. Manche Tools dienen nur einem Zweck, zum Beispiel Icons zu extrahieren, was sie sicherer gegen Fehlbedeinung macht als mächtigere Werkzeuge. Wenn der Autor schon mal dabei ist, Icons zu extrahieren, dann fällt ihm sicher noch etwas anderes ein, zum Beispiel weitere Ressourcen zu extrahieren, zum Beispiel Zeichenketten. Das ist ähnlich sicher, wie Icons zu extrahieren. Schon etwas anders ist die Situation bei mächtigen Analysewerkzeugen, die nebenher auch einen Ressourceneditor beinhalten, aber von solchen reden wir hier gerade nicht.

Man könnte natürlich versehentlich das Original zerschießen, weswegen man auf einer Kopie arbeitet. Aber damit erzähle ich uns nichts Neues. Mit manchen Tools ist ein Zerschießen ein Kunststück, wogegen manche andere die Freiheiten dazu als beabsichtigtes Feature bieten. Mit einem Hex-Editor ist Maximalzerschießung ein Kinderspiel. Dafür hat man alle Freiheiten (und meistens wenig Hilfen an der Hand, sodass man selber den Header analysieren und Adressen ausrechnen muss, also das, was Windows tut, wenn es nach dem Icon sucht). Es gibt auch Tools, die einen Ressoureneditor, einen Hex-Editor und vieles mehr beeinhalten, z.B. der CFF Explorer aus der Explorer Suite. Dafür ist der bei Ressourcenbearbeitung etwas sparsam ausgestattet, aber das ist nicht sein Primärzweck.

Ein altbewährtes Tool ist Resource Hacker, aber das habe ich schon seit Ewigkeiten nicht mehr benutzt (wohl zuletzt unter Windows XP). Das kann ziemlich viel. Jedoch stimmen die Prüfsummen der Downloads von der Website des Autors und dem von chip.de nicht überein. Außerdem ist der vom Autor angebotene Download unverschlüsselt. Ich habe daher mal den Link hier herausgenommen. Manchmal haben solche Differenzen harmlose Ursachen, zum Beispiel indem der Autor den Installer nochmal angepasst hat. In anderen Fällen sind Daten korrupt, oder es ist Schadcode enthalten. Es ist bei solchen kleinen privaten Homepages manchmal fraglich, unter wessen Kontrolle sie stehen, zumal fehlende Verschlüsselung vermuten lässt, dass der Autor wenig Initiative zeigt oder ein Problem mit seinem Hoster hat. Eine Prüfsumme ist auch nicht gegeben, und der Installer lässt sich nicht mit 7-Zip entpacken (deutet auf ein seltenes Format hin, an sich nicht schlimm, aber nicht glücklich). Es gibt, alternativ dazu, ein Zip-Archiv, auch ohne Prüfsumme. Solche Sorglosigkeit auf fast allen Ebenen nervt mich. Dann frage ich mich, ob die Software tut, was sie soll, bei solcher Sorglosigkeit. Es ist wohl eine alte Seite, aus einer Zeit, als man manches noch nicht so genau nahm, aber trotzdem...

[honx]

dank dir. nachdem du unschärfen beim extrahieren erwähnt hast, ist jener weg nun ohnehin keine option mehr.
ich entscheide mich für umbenennen in .dll, ist am sichersten und ich hab (wie du sagtest) alle auflösungen parat.