info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Anderes Programm im eigenen Installer installieren (Error 1618: Es wird bereits anderweitig eine Installation ausgeführt)
12 views
Skip to first unread message
Matthias Hanft
Jun 30, 2017, 4:43:34 AM6/30/17
to
Hallo,
ich liefere meine eigene Software per InstallShield-Setup-Paket an den
Anwender aus. Da sind ein paar Fremd-DLLs dabei, die diese "VC-Runtime"
im System benötigen. Bisher habe ich die beiden dazu nötigen Dateien
(MSVC...DLL) einfach mitinstalliert (=mit in den Programmordner kopiert),
aber inzwischen sind die Fremd-DLLs mit VC++2017 compiliert, und der
Hersteller dieser DLLs meint, man solle die jetzt nötige "vcredist 2017"
unbedingt mit dem Microsoft-eigenen Installer installieren, weil da
irgendwelche komplexen Abhängigkeiten drin sind und das simple Kopieren
von zwei Dateien möglicherweise nicht mehr genügt.
Gesagt, getan - also rufe ich während meiner eigenen Programminstallation
eben das originale "vc_redist.x86.exe" auf (mit "/install /passive" oder
"/install /quiet", damit der Benutzer nicht "Ok" klicken braucht oder so).
Hat nur leider den Haken, dass das aufgerufene vc_redist.x86.exe dann sagt:
"Error 1618 (Es wird bereits anderweitig eine Installation ausgeführt.
Beenden Sie den anderen Installationsvorgang, bevor Sie diese Installation
fortsetzen)".
Wenn man so darüber nachdenkt, ist das eigentlich auch logisch - denn es
läuft ja gerade _meine_eigene_ Installation!
Das ist natürlich ein systematisches Problem - wie löst man das denn am
besten?
Bei manchen Fremdprogrammen habe ich während der Installation auch gelegent-
lich schon mal das VCRuntime-Fenster kurz aufploppen sehen - da ging's ja
auch. Wie haben die das gemacht?
Beim Googeln habe ich bisher nur irgendwelche "Hilfskrücken" mit Verändern
von Registry-Einträgen gefunden, à la http://www.installsite.org/pages/de/msifaq/error/1618.htm
aber bevor ich solche "Hintertüren" aufmache, wollte ich erst mal fragen,
ob es dafür nicht auch einen "offiziellen" Weg gibt...
Danke & Gruß Matthias.
ich liefere meine eigene Software per InstallShield-Setup-Paket an den
Anwender aus. Da sind ein paar Fremd-DLLs dabei, die diese "VC-Runtime"
im System benötigen. Bisher habe ich die beiden dazu nötigen Dateien
(MSVC...DLL) einfach mitinstalliert (=mit in den Programmordner kopiert),
aber inzwischen sind die Fremd-DLLs mit VC++2017 compiliert, und der
Hersteller dieser DLLs meint, man solle die jetzt nötige "vcredist 2017"
unbedingt mit dem Microsoft-eigenen Installer installieren, weil da
irgendwelche komplexen Abhängigkeiten drin sind und das simple Kopieren
von zwei Dateien möglicherweise nicht mehr genügt.
Gesagt, getan - also rufe ich während meiner eigenen Programminstallation
eben das originale "vc_redist.x86.exe" auf (mit "/install /passive" oder
"/install /quiet", damit der Benutzer nicht "Ok" klicken braucht oder so).
Hat nur leider den Haken, dass das aufgerufene vc_redist.x86.exe dann sagt:
"Error 1618 (Es wird bereits anderweitig eine Installation ausgeführt.
Beenden Sie den anderen Installationsvorgang, bevor Sie diese Installation
fortsetzen)".
Wenn man so darüber nachdenkt, ist das eigentlich auch logisch - denn es
läuft ja gerade _meine_eigene_ Installation!
Das ist natürlich ein systematisches Problem - wie löst man das denn am
besten?
Bei manchen Fremdprogrammen habe ich während der Installation auch gelegent-
lich schon mal das VCRuntime-Fenster kurz aufploppen sehen - da ging's ja
auch. Wie haben die das gemacht?
Beim Googeln habe ich bisher nur irgendwelche "Hilfskrücken" mit Verändern
von Registry-Einträgen gefunden, à la http://www.installsite.org/pages/de/msifaq/error/1618.htm
aber bevor ich solche "Hintertüren" aufmache, wollte ich erst mal fragen,
ob es dafür nicht auch einen "offiziellen" Weg gibt...
Danke & Gruß Matthias.
Edzard Egberts
Jun 30, 2017, 5:38:15 AM6/30/17
to
> ich liefere meine eigene Software per InstallShield-Setup-Paket an
> den Anwender aus. Da sind ein paar Fremd-DLLs dabei, die diese
> "VC-Runtime" im System benötigen. Bisher habe ich die beiden dazu
> nötigen Dateien (MSVC...DLL) einfach mitinstalliert (=mit in den
> Programmordner kopiert), aber inzwischen sind die Fremd-DLLs mit
> VC++2017 compiliert, und der Hersteller dieser DLLs meint, man solle
> die jetzt nötige "vcredist 2017" unbedingt mit dem Microsoft-eigenen
> Installer installieren, weil da irgendwelche komplexen Abhängigkeiten
> drin sind und das simple Kopieren von zwei Dateien möglicherweise
> nicht mehr genügt.
Die DLLs in das Verzeichnis des Programms zu kopieren, das diese DLLs
> den Anwender aus. Da sind ein paar Fremd-DLLs dabei, die diese
> "VC-Runtime" im System benötigen. Bisher habe ich die beiden dazu
> nötigen Dateien (MSVC...DLL) einfach mitinstalliert (=mit in den
> Programmordner kopiert), aber inzwischen sind die Fremd-DLLs mit
> VC++2017 compiliert, und der Hersteller dieser DLLs meint, man solle
> die jetzt nötige "vcredist 2017" unbedingt mit dem Microsoft-eigenen
> Installer installieren, weil da irgendwelche komplexen Abhängigkeiten
> drin sind und das simple Kopieren von zwei Dateien möglicherweise
> nicht mehr genügt.
benötigt, ist eigentlich die sauberste Lösung - die Verwendung der
System-DLLs führt leicht in die "DLL-Hell". Noch besser wäre es, die
Libs gleich statisch zu linken, dann muss man gar nichts mehr
installieren. Das Problem sind nicht irgendwelche komplexen
Abhängigkeiten, sondern die Lizenzbestimmungen - AFAIK darf man den
MSVC-Kram nämlich nicht einfach kopieren oder gar statisch linken.
Von daher benutze ich LGPL-Open-Source plus MinGW und linke alles
statisch in die Programme, so dass die Win-32bit-Programme auch unter
Win-64bit laufen. Den MS-Schrott kann man ja nicht verwenden, ohne sich
irgendwelche undurchsichtigen Lizenzbedingungen einzufangen, vor allem
kann man dieser Firma nicht vertrauen.
> Das ist natürlich ein systematisches Problem - wie löst man das denn
> am besten?
Installation aufruft? Ist das zu trivial?
Matthias Hanft
Jun 30, 2017, 6:29:55 AM6/30/17
to
Edzard Egberts schrieb:
stimmt. Aber durch die Fremd-DLLs sind mir da die Hände gebunden.
> Ein Wrapper, der erst den MSVC-Kram installiert und dann Deine
> Installation aufruft? Ist das zu trivial?
Stimmt, wäre eine Lösung - muss der Benutzer halt zweimal die UAC
abnicken, aber warum auch nicht. Wobei die erneute MSVC-Installation
bei späteren Programmupdates natürlich eigentlich überflüssig wäre,
aber die (programmgesteuerte) Beantwortung der Frage "ist die MSVC-
Runtime bereits installiert?" (damit man die Installation im Wrapper
ggf. überspringen könnte) scheint nicht trivial zu sein und lief in
einem Forum auf die Lösung hinaus "einfach immer installieren; wenn
schon installiert, tut der Installer einfach nix".
Eine andere Lösung (bei der ich keinen Wrapper bauen müsste) ist mir
auch noch eingefallen: das VCRedist-Zeug in meinem Installer *nicht*
installieren und beim ersten Programmstart nachholen. Da kann man
dem Anwender dann auch vorher eine Dialogbox einblenden, damit er
nicht überrascht wird, was da abläuft. Auch hier wäre es natürlich
von Vorteil, wenn man beim erwähnten Programmstart irgendwie prüfen
könnte, ob man den VCRedist-Installer aufrufen muss oder nicht.
Notfalls könnte man "LoadLibrary(FremdDLL)" probieren, und wenn da
als Fehler kommt "das angegebene Modul wurde nicht gefunden", wäre
das ein Hinweis auf die fehlende VCRuntime. Denn sonst kommt bei
einer "immer installieren"-Funktion erst die Dialogbox "Obacht,
jetzt wird gleich VCRuntime installiert", und dann passiert nix -
auch verwirrend für den Anwender...
In der Registry nachgucken, ob es unter HKLM\SOFTWARE\Microsoft\
Visual Studio\14.0\VC\Runtimes\x86" einen Schlüssel "Installed"
mit dem Wert 1 gibt, ist vermutlich auch nicht "offiziell", würde
aber anscheinend funktionieren...?! Wobei sie auf
https://stackoverflow.com/questions/12206314/detect-if-visual-c-redistributable-for-visual-studio-2012-is-installed
stattdessen (für 2017/x86)
[HKEY_CLASSES_ROOT\Installer\Dependencies\,,x86,14.0,bundle\Dependents\{c239cea1-d49e-4e16-8e87-8c055765f7ec}]
vorschlagen, aber das ist anscheinend versionsabhängig (25008;
inzwischen kann man 25017 runterladen, der scheint stattdessen
{f325f05b-f963-4640-a43b-c8a494cdda0f} zu haben - das kann man
also nehmen, wenn man eine ganz bestimmte Version haben will,
aber ansonsten fände ich (wenn überhaupt die Registry testet,
weil man keine bessere Möglichkeit findet) die erste Methode
sinnvoller...?!
Gruß Matthias.
>
> Die DLLs in das Verzeichnis des Programms zu kopieren, das diese DLLs
> benötigt, ist eigentlich die sauberste Lösung - die Verwendung der
> System-DLLs führt leicht in die "DLL-Hell". Noch besser wäre es, die
> Libs gleich statisch zu linken, dann muss man gar nichts mehr
> installieren. Das Problem sind nicht irgendwelche komplexen
> Abhängigkeiten, sondern die Lizenzbestimmungen - AFAIK darf man den
> MSVC-Kram nämlich nicht einfach kopieren oder gar statisch linken.
Ja, andere technische Lösungen wären natürlich vorzuziehen, das
> Die DLLs in das Verzeichnis des Programms zu kopieren, das diese DLLs
> benötigt, ist eigentlich die sauberste Lösung - die Verwendung der
> System-DLLs führt leicht in die "DLL-Hell". Noch besser wäre es, die
> Libs gleich statisch zu linken, dann muss man gar nichts mehr
> installieren. Das Problem sind nicht irgendwelche komplexen
> Abhängigkeiten, sondern die Lizenzbestimmungen - AFAIK darf man den
> MSVC-Kram nämlich nicht einfach kopieren oder gar statisch linken.
stimmt. Aber durch die Fremd-DLLs sind mir da die Hände gebunden.
> Ein Wrapper, der erst den MSVC-Kram installiert und dann Deine
> Installation aufruft? Ist das zu trivial?
abnicken, aber warum auch nicht. Wobei die erneute MSVC-Installation
bei späteren Programmupdates natürlich eigentlich überflüssig wäre,
aber die (programmgesteuerte) Beantwortung der Frage "ist die MSVC-
Runtime bereits installiert?" (damit man die Installation im Wrapper
ggf. überspringen könnte) scheint nicht trivial zu sein und lief in
einem Forum auf die Lösung hinaus "einfach immer installieren; wenn
schon installiert, tut der Installer einfach nix".
Eine andere Lösung (bei der ich keinen Wrapper bauen müsste) ist mir
auch noch eingefallen: das VCRedist-Zeug in meinem Installer *nicht*
installieren und beim ersten Programmstart nachholen. Da kann man
dem Anwender dann auch vorher eine Dialogbox einblenden, damit er
nicht überrascht wird, was da abläuft. Auch hier wäre es natürlich
von Vorteil, wenn man beim erwähnten Programmstart irgendwie prüfen
könnte, ob man den VCRedist-Installer aufrufen muss oder nicht.
Notfalls könnte man "LoadLibrary(FremdDLL)" probieren, und wenn da
als Fehler kommt "das angegebene Modul wurde nicht gefunden", wäre
das ein Hinweis auf die fehlende VCRuntime. Denn sonst kommt bei
einer "immer installieren"-Funktion erst die Dialogbox "Obacht,
jetzt wird gleich VCRuntime installiert", und dann passiert nix -
auch verwirrend für den Anwender...
In der Registry nachgucken, ob es unter HKLM\SOFTWARE\Microsoft\
Visual Studio\14.0\VC\Runtimes\x86" einen Schlüssel "Installed"
mit dem Wert 1 gibt, ist vermutlich auch nicht "offiziell", würde
aber anscheinend funktionieren...?! Wobei sie auf
https://stackoverflow.com/questions/12206314/detect-if-visual-c-redistributable-for-visual-studio-2012-is-installed
stattdessen (für 2017/x86)
[HKEY_CLASSES_ROOT\Installer\Dependencies\,,x86,14.0,bundle\Dependents\{c239cea1-d49e-4e16-8e87-8c055765f7ec}]
vorschlagen, aber das ist anscheinend versionsabhängig (25008;
inzwischen kann man 25017 runterladen, der scheint stattdessen
{f325f05b-f963-4640-a43b-c8a494cdda0f} zu haben - das kann man
also nehmen, wenn man eine ganz bestimmte Version haben will,
aber ansonsten fände ich (wenn überhaupt die Registry testet,
weil man keine bessere Möglichkeit findet) die erste Methode
sinnvoller...?!
Gruß Matthias.
Edzard Egberts
Jun 30, 2017, 7:17:39 AM6/30/17
to
Matthias Hanft wrote:
> Eine andere Lösung (bei der ich keinen Wrapper bauen müsste) ist mir
> auch noch eingefallen: das VCRedist-Zeug in meinem Installer *nicht*
> installieren und beim ersten Programmstart nachholen.
Dann muss das Programm aber ggf. mit Admin-Rechten gestartet werden,
> Eine andere Lösung (bei der ich keinen Wrapper bauen müsste) ist mir
> auch noch eingefallen: das VCRedist-Zeug in meinem Installer *nicht*
> installieren und beim ersten Programmstart nachholen.
davon kann man IMHO nicht ausgehen - schon bei der Installation ist es
Zufall, wenn der Windows-Benutzer dran denkt.
> Notfalls könnte man "LoadLibrary(FremdDLL)" probieren, und wenn da
> als Fehler kommt "das angegebene Modul wurde nicht gefunden", wäre
> das ein Hinweis auf die fehlende VCRuntime.
und Fehlercode auswerten" gedacht, LoadLibrary() wäre aber eleganter.
> Wobei sie auf
> https://stackoverflow.com/questions/12206314/detect-if-visual-c-redistributable-for-visual-studio-2012-is-installed
> stattdessen (für 2017/x86)
> [HKEY_CLASSES_ROOT\Installer\Dependencies\,,x86,14.0,bundle\Dependents\{c239cea1-d49e-4e16-8e87-8c055765f7ec}]
> vorschlagen, aber das ist anscheinend versionsabhängig (25008;
> inzwischen kann man 25017 runterladen, der scheint stattdessen
> {f325f05b-f963-4640-a43b-c8a494cdda0f} zu haben - das kann man
> also nehmen, wenn man eine ganz bestimmte Version haben will,
Registry verlassen), denn Du willst natürlich die Version installiert
haben, die zu Deinem Programm passt. Bei einer älteren Version könnte es
sonst passieren, dass das Programm zwar losläuft, dann aber bei einem
nicht implementierten Einsprung abstürzt.
Stefan Kanthak
Jun 30, 2017, 8:28:54 AM6/30/17
to
"Matthias Hanft" <m...@hanft.de> schrieb:
> Hallo,
>
> ich liefere meine eigene Software per InstallShield-Setup-Paket an den
> Anwender aus.
AUTSCH!
AUSFUEHRBARE Installationspakete sind defekt per Design und ALLE kaputt:
siehe <https://skanthak.homepage.t-online.de/~execute.html>
> Da sind ein paar Fremd-DLLs dabei, die diese "VC-Runtime"
> im System benötigen. Bisher habe ich die beiden dazu nötigen Dateien
> (MSVC...DLL) einfach mitinstalliert (=mit in den Programmordner kopiert),
AUTSCH!
Dort werden sie von Windows Update nicht entdeckt und nicht aktualisiert;
siehe <https://support.microsoft.com/kb/835322>
> aber inzwischen sind die Fremd-DLLs mit VC++2017 compiliert, und der
> Hersteller dieser DLLs meint, man solle die jetzt nötige "vcredist 2017"
> unbedingt mit dem Microsoft-eigenen Installer installieren, weil da
> irgendwelche komplexen Abhängigkeiten drin sind und das simple Kopieren
> von zwei Dateien möglicherweise nicht mehr genügt.
Siehe <https://support.microsoft.com/kb/326922> und neuere MSKB-Artikel.
> Das ist natürlich ein systematisches Problem - wie löst man das denn am
> besten?
Durch Bauen eines *.MSI
Stefan
[
--
Die unaufgeforderte Zusendung werbender E-Mails verstoesst gegen §823
Abs. 1 sowie §1004 Abs. 1 BGB und begruendet Anspruch auf Unterlassung.
Beschluss des OLG Bamberg vom 12.05.2005 (AZ: 1 U 143/04)
> Hallo,
>
> ich liefere meine eigene Software per InstallShield-Setup-Paket an den
> Anwender aus.
AUSFUEHRBARE Installationspakete sind defekt per Design und ALLE kaputt:
siehe <https://skanthak.homepage.t-online.de/~execute.html>
> Da sind ein paar Fremd-DLLs dabei, die diese "VC-Runtime"
> im System benötigen. Bisher habe ich die beiden dazu nötigen Dateien
> (MSVC...DLL) einfach mitinstalliert (=mit in den Programmordner kopiert),
Dort werden sie von Windows Update nicht entdeckt und nicht aktualisiert;
siehe <https://support.microsoft.com/kb/835322>
> aber inzwischen sind die Fremd-DLLs mit VC++2017 compiliert, und der
> Hersteller dieser DLLs meint, man solle die jetzt nötige "vcredist 2017"
> unbedingt mit dem Microsoft-eigenen Installer installieren, weil da
> irgendwelche komplexen Abhängigkeiten drin sind und das simple Kopieren
> von zwei Dateien möglicherweise nicht mehr genügt.
> Das ist natürlich ein systematisches Problem - wie löst man das denn am
> besten?
Stefan
[
--
Die unaufgeforderte Zusendung werbender E-Mails verstoesst gegen §823
Abs. 1 sowie §1004 Abs. 1 BGB und begruendet Anspruch auf Unterlassung.
Beschluss des OLG Bamberg vom 12.05.2005 (AZ: 1 U 143/04)
Matthias Hanft
Jun 30, 2017, 8:56:17 AM6/30/17
to
Edzard Egberts schrieb:
vcredist-Installiers (via CreateProcess) erscheint? Dann läuft halt
*der* mit Admin-Rechten - und *mein* Programm muss das ja nicht. Bin
leider noch nicht so weit beim Programmieren - werde ich heute nach-
mittag mal ausprobieren...
>> [HKEY_CLASSES_ROOT\Installer\Dependencies\,,x86,14.0,bundle\Dependents\{c239cea1-d49e-4e16-8e87-8c055765f7ec}]
mal davon aus, dass es dann egal ist, ob Build 25008 oder 25017 beim
Anwender installiert ist.
Gruß Matthias.
>> Eine andere Lösung (bei der ich keinen Wrapper bauen müsste) ist mir
>> auch noch eingefallen: das VCRedist-Zeug in meinem Installer *nicht*
>> installieren und beim ersten Programmstart nachholen.
> Dann muss das Programm aber ggf. mit Admin-Rechten gestartet werden,
> davon kann man IMHO nicht ausgehen - schon bei der Installation ist es
> Zufall, wenn der Windows-Benutzer dran denkt.
Ich hatte eigentlich angenommen, dass die UAC-Abfrage beim Start des
>> auch noch eingefallen: das VCRedist-Zeug in meinem Installer *nicht*
>> installieren und beim ersten Programmstart nachholen.
> Dann muss das Programm aber ggf. mit Admin-Rechten gestartet werden,
> davon kann man IMHO nicht ausgehen - schon bei der Installation ist es
> Zufall, wenn der Windows-Benutzer dran denkt.
vcredist-Installiers (via CreateProcess) erscheint? Dann läuft halt
*der* mit Admin-Rechten - und *mein* Programm muss das ja nicht. Bin
leider noch nicht so weit beim Programmieren - werde ich heute nach-
mittag mal ausprobieren...
>> [HKEY_CLASSES_ROOT\Installer\Dependencies\,,x86,14.0,bundle\Dependents\{c239cea1-d49e-4e16-8e87-8c055765f7ec}]
> Das ist die korrekte Lösung (vorausgesetzt man kann sich auf die
> Registry verlassen), denn Du willst natürlich die Version installiert
> haben, die zu Deinem Programm passt. Bei einer älteren Version könnte es
> sonst passieren, dass das Programm zwar losläuft, dann aber bei einem
> nicht implementierten Einsprung abstürzt.
Der Hersteller der Fremd-DLLs sagt nur "Visual Studio 2017". Ich gehe
> Registry verlassen), denn Du willst natürlich die Version installiert
> haben, die zu Deinem Programm passt. Bei einer älteren Version könnte es
> sonst passieren, dass das Programm zwar losläuft, dann aber bei einem
> nicht implementierten Einsprung abstürzt.
mal davon aus, dass es dann egal ist, ob Build 25008 oder 25017 beim
Anwender installiert ist.
Gruß Matthias.
Matthias Hanft
Jun 30, 2017, 9:04:05 AM6/30/17
to
Stefan Kanthak schrieb:
>> im System benötigen. Bisher habe ich die beiden dazu nötigen Dateien
>> (MSVC...DLL) einfach mitinstalliert (=mit in den Programmordner kopiert),
ja die speziellen MSVC-DLLs für _genau_diese_ Software.
Dieser Artikel geht nur bis VC++2005.
Für VC++2017 schreibt der Hersteller der Fremd-DLLs:
--- schnipp ---
der "Nachfolger" zur MSVCR120.DLL heißt VCRUNTIME140.DLL, aber es genügt nicht, nur die beiden Bibliotheken MSVCP140.DLL und VCRUNTIME140.DLL in das Anwendungsverzeichnis zu legen!
Microsoft hat die neue Visual C++ 2017-Runtime in zahlreiche Einzelbibliotheken aufgespalten, die wiederum haben eine Abhängigkeit zur Windows Universal CRT haben, die unter Windows-Versionen vor
Windows 10 nicht garantiert vorhanden ist.
Wir empfehlen daher, die Microsoft Redistributables als ganzes zu installieren, da die Abhängigkeiten der zahlreichen Runtime-Bibliotheken nicht dokumentiert sind und sich bei Updates ändern könnten.
Ein weiterer Grund: Microsofts Redistributable Installer installieren die Windows Universal CRT bei Bedarf automatisch mit.
--- schnapp ---
Also führt wohl nichts am Aufruf von vc_redist.x86.exe vorbei...
>> Das ist natürlich ein systematisches Problem - wie löst man das denn am
>> besten?
> Durch Bauen eines *.MSI
Ich kann InstallShield (durch Weglassen des Häkchens bei "Installer
inkludieren") schon dazu bringen, ein MSI statt ein EXE zu produzieren.
Aber das löst ja nicht das grundsätzliche Problem während der Installation.
Gruß Matthias.
>
> AUSFUEHRBARE Installationspakete sind defekt per Design und ALLE kaputt:
> siehe <https://skanthak.homepage.t-online.de/~execute.html>
The requested URL /~execute.html was not found on this server.
> AUSFUEHRBARE Installationspakete sind defekt per Design und ALLE kaputt:
> siehe <https://skanthak.homepage.t-online.de/~execute.html>
>> im System benötigen. Bisher habe ich die beiden dazu nötigen Dateien
>> (MSVC...DLL) einfach mitinstalliert (=mit in den Programmordner kopiert),
> Dort werden sie von Windows Update nicht entdeckt und nicht aktualisiert;
Aber die müssen/sollen ja auch nicht geupdatet werden - das sind
ja die speziellen MSVC-DLLs für _genau_diese_ Software.
Dieser Artikel geht nur bis VC++2005.
Für VC++2017 schreibt der Hersteller der Fremd-DLLs:
--- schnipp ---
der "Nachfolger" zur MSVCR120.DLL heißt VCRUNTIME140.DLL, aber es genügt nicht, nur die beiden Bibliotheken MSVCP140.DLL und VCRUNTIME140.DLL in das Anwendungsverzeichnis zu legen!
Microsoft hat die neue Visual C++ 2017-Runtime in zahlreiche Einzelbibliotheken aufgespalten, die wiederum haben eine Abhängigkeit zur Windows Universal CRT haben, die unter Windows-Versionen vor
Windows 10 nicht garantiert vorhanden ist.
Wir empfehlen daher, die Microsoft Redistributables als ganzes zu installieren, da die Abhängigkeiten der zahlreichen Runtime-Bibliotheken nicht dokumentiert sind und sich bei Updates ändern könnten.
Ein weiterer Grund: Microsofts Redistributable Installer installieren die Windows Universal CRT bei Bedarf automatisch mit.
--- schnapp ---
Also führt wohl nichts am Aufruf von vc_redist.x86.exe vorbei...
>> Das ist natürlich ein systematisches Problem - wie löst man das denn am
>> besten?
> Durch Bauen eines *.MSI
inkludieren") schon dazu bringen, ein MSI statt ein EXE zu produzieren.
Aber das löst ja nicht das grundsätzliche Problem während der Installation.
Gruß Matthias.
Edzard Egberts
Jun 30, 2017, 9:11:40 AM6/30/17
to
Stefan Kanthak wrote:
> "Matthias Hanft" <m...@hanft.de> schrieb:
>
>> Hallo,
>>
>> ich liefere meine eigene Software per InstallShield-Setup-Paket an
>> den Anwender aus.
>
> AUTSCH! AUSFUEHRBARE Installationspakete sind defekt per Design und
> ALLE kaputt: siehe
> <https://skanthak.homepage.t-online.de/~execute.html>
Geht nicht, aber das:
> "Matthias Hanft" <m...@hanft.de> schrieb:
>
>> Hallo,
>>
>> ich liefere meine eigene Software per InstallShield-Setup-Paket an
>> den Anwender aus.
>
> AUTSCH! AUSFUEHRBARE Installationspakete sind defekt per Design und
> ALLE kaputt: siehe
> <https://skanthak.homepage.t-online.de/~execute.html>
http://skanthak.homepage.t-online.de/!execute.html
Echt jetzt, das muss man alles beachten, um irgend ein Programm auf
Windows zu installieren? Ist ja wohl eine Zumutung!
> AUTSCH! Dort werden sie von Windows Update nicht entdeckt und nicht
> aktualisiert; siehe <https://support.microsoft.com/kb/835322>
nicht kaputt macht?
>> aber inzwischen sind die Fremd-DLLs mit VC++2017 compiliert, und
>> der Hersteller dieser DLLs meint, man solle die jetzt nötige
>> "vcredist 2017" unbedingt mit dem Microsoft-eigenen Installer
>> installieren, weil da irgendwelche komplexen Abhängigkeiten drin
>> sind und das simple Kopieren von zwei Dateien möglicherweise nicht
>> mehr genügt.
>
> Siehe <https://support.microsoft.com/kb/326922> und neuere
> MSKB-Artikel.
>
>> Das ist natürlich ein systematisches Problem - wie löst man das
>> denn am besten?
>
> Durch Bauen eines *.MSI
"Executable installer" heraus? Du willst uns doch veräppeln! ;o)
Claus Reibenstein
Jun 30, 2017, 10:29:41 AM6/30/17
to
Edzard Egberts schrieb am 30.06.2017 um 15:10:
> Stefan Kanthak wrote:
>
>> "Matthias Hanft" <m...@hanft.de> schrieb:
>>
> Stefan Kanthak wrote:
>
>> "Matthias Hanft" <m...@hanft.de> schrieb:
>>
>>> ich liefere meine eigene Software per InstallShield-Setup-Paket an
>>> den Anwender aus.
>>
>> AUTSCH! AUSFUEHRBARE Installationspakete sind defekt per Design und
>> ALLE kaputt: siehe
>> <https://skanthak.homepage.t-online.de/~execute.html>
>
> Geht nicht, aber das:
>
> http://skanthak.homepage.t-online.de/!execute.html
Nun ja, ein kleiner Typo. Kann ja mal passieren. Die beiden Zeichen
>>> den Anwender aus.
>>
>> AUTSCH! AUSFUEHRBARE Installationspakete sind defekt per Design und
>> ALLE kaputt: siehe
>> <https://skanthak.homepage.t-online.de/~execute.html>
>
> Geht nicht, aber das:
>
> http://skanthak.homepage.t-online.de/!execute.html
liegen ja auch so dicht beieinander ... ;-)
> Echt jetzt, das muss man alles beachten, um irgend ein Programm auf
> Windows zu installieren? Ist ja wohl eine Zumutung!
>> AUTSCH! Dort werden sie von Windows Update nicht entdeckt und nicht
>> aktualisiert; siehe <https://support.microsoft.com/kb/835322>
>
> Garantiert mir Microsoft, dass so eine Aktualisierung mein Programm
> nicht kaputt macht?
keine Sicherheitslücken enthalten und deshalb nicht gepflegt werden
müssen? Garantierst Du das Deinen Kunden? Übernimmst Du die volle
Verantwortung dafür?
>>> Das ist natürlich ein systematisches Problem - wie löst man das
>>> denn am besten?
>>
>> Durch Bauen eines *.MSI
>
> Warum macht MS selber das nicht, sondern gibt den vcredist-Krempel als
> "Executable installer" heraus?
> Du willst uns doch veräppeln! ;o)
Gruß
Claus
Matthias Hanft
Jun 30, 2017, 11:44:40 AM6/30/17
to
Ich schrieb:
anhand des fehlenden Registry-Eintrags fest, dass die vcredist fehlt,
startet das vcredist.exe via CreateProcess, dann kommt automatisch
die UAC-Abfrage, und das Zeug wird installiert. Falls der User bei
der UAC-Abfrage "Nein" drückt, kriegt mein Programm das sogar über
den Exit-Code 1602 ("Die Installation wurde vom Benutzer abgebro-
chen") mit (ansonsten kommt S_OK, also 0).
Das sieht doch schon mal gut aus. Ich werde das jetzt mit den pas-
senden Dialogfeldern für normalsterbliche Anwender garnieren, und,
wenn keine Katastrophen mehr passieren, so lassen.
Gruß Matthias.
>
> Ich hatte eigentlich angenommen, dass die UAC-Abfrage beim Start des
> vcredist-Installiers (via CreateProcess) erscheint? Dann läuft halt
> *der* mit Admin-Rechten - und *mein* Programm muss das ja nicht. Bin
> leider noch nicht so weit beim Programmieren - werde ich heute nach-
> mittag mal ausprobieren...
Ja, das geht. Also mein Programm startet als normaler User, stellt
> Ich hatte eigentlich angenommen, dass die UAC-Abfrage beim Start des
> vcredist-Installiers (via CreateProcess) erscheint? Dann läuft halt
> *der* mit Admin-Rechten - und *mein* Programm muss das ja nicht. Bin
> leider noch nicht so weit beim Programmieren - werde ich heute nach-
> mittag mal ausprobieren...
anhand des fehlenden Registry-Eintrags fest, dass die vcredist fehlt,
startet das vcredist.exe via CreateProcess, dann kommt automatisch
die UAC-Abfrage, und das Zeug wird installiert. Falls der User bei
der UAC-Abfrage "Nein" drückt, kriegt mein Programm das sogar über
den Exit-Code 1602 ("Die Installation wurde vom Benutzer abgebro-
chen") mit (ansonsten kommt S_OK, also 0).
Das sieht doch schon mal gut aus. Ich werde das jetzt mit den pas-
senden Dialogfeldern für normalsterbliche Anwender garnieren, und,
wenn keine Katastrophen mehr passieren, so lassen.
Gruß Matthias.
Stefan Kanthak
Jun 30, 2017, 6:07:18 PM6/30/17
to
"Edzard Egberts" <ne...@edzeg.net> schrieb:
> Stefan Kanthak wrote:
>> "Matthias Hanft" <m...@hanft.de> schrieb:
>>
>>> Hallo,
>>>
>>> ich liefere meine eigene Software per InstallShield-Setup-Paket an
>>> den Anwender aus.
>>
>> AUTSCH! AUSFUEHRBARE Installationspakete sind defekt per Design und
>> ALLE kaputt: siehe
>> <https://skanthak.homepage.t-online.de/~execute.html>
>
> Geht nicht, aber das:
>
> http://skanthak.homepage.t-online.de/!execute.html
>
> Echt jetzt, das muss man alles beachten, um irgend ein Programm auf
> Windows zu installieren?
Nein. Das musst Du nur beachten, wenn Du Installationspakete OHNE
triviale Anfaengerfehler bauen willst.
> Ist ja wohl eine Zumutung!
Falsch: MINIMAL ART!
Weniger ist UNSICHER!
JFTR: niemand zwingt Dich, kaputte Software fuer Windows zu verbrechen!
>> AUTSCH! Dort werden sie von Windows Update nicht entdeckt und nicht
>> aktualisiert; siehe <https://support.microsoft.com/kb/835322>
>
> Garantiert mir Microsoft, dass so eine Aktualisierung mein Programm
> nicht kaputt macht?
Laut Microsoft sind MSVCRT abwaertskompatibel; falls nicht haben sie
einen Fehler gemacht, den sie wiederum laut eigener Aussage kostenlos
korrigieren.
[...]
>> Durch Bauen eines *.MSI
>
> Warum macht MS selber das nicht, sondern gibt den vcredist-Krempel als
> "Executable installer" heraus?
Weil die linke Hand des Teufels nicht weiss was die rechte macht!
> Du willst uns doch veräppeln! ;o)
Nur Ru^Hosse taeuschen!
> Stefan Kanthak wrote:
>> "Matthias Hanft" <m...@hanft.de> schrieb:
>>
>>> Hallo,
>>>
>>> ich liefere meine eigene Software per InstallShield-Setup-Paket an
>>> den Anwender aus.
>>
>> AUTSCH! AUSFUEHRBARE Installationspakete sind defekt per Design und
>> ALLE kaputt: siehe
>> <https://skanthak.homepage.t-online.de/~execute.html>
>
> Geht nicht, aber das:
>
> http://skanthak.homepage.t-online.de/!execute.html
>
> Echt jetzt, das muss man alles beachten, um irgend ein Programm auf
> Windows zu installieren?
triviale Anfaengerfehler bauen willst.
> Ist ja wohl eine Zumutung!
Weniger ist UNSICHER!
JFTR: niemand zwingt Dich, kaputte Software fuer Windows zu verbrechen!
>> AUTSCH! Dort werden sie von Windows Update nicht entdeckt und nicht
>> aktualisiert; siehe <https://support.microsoft.com/kb/835322>
>
> Garantiert mir Microsoft, dass so eine Aktualisierung mein Programm
> nicht kaputt macht?
einen Fehler gemacht, den sie wiederum laut eigener Aussage kostenlos
korrigieren.
[...]
>> Durch Bauen eines *.MSI
>
> Warum macht MS selber das nicht, sondern gibt den vcredist-Krempel als
> "Executable installer" heraus?
> Du willst uns doch veräppeln! ;o)
Stefan Kanthak
Jun 30, 2017, 6:07:18 PM6/30/17
to
"Matthias Hanft" <m...@hanft.de> schrieb:
> Stefan Kanthak schrieb:
>>
>> AUSFUEHRBARE Installationspakete sind defekt per Design und ALLE kaputt:
>> siehe <https://skanthak.homepage.t-online.de/~execute.html>
>
> The requested URL /~execute.html was not found on this server.
AUTSCH, mein Fehler: korrekt ist ...!execute.html
>>> im System benötigen. Bisher habe ich die beiden dazu nötigen Dateien
>>> (MSVC...DLL) einfach mitinstalliert (=mit in den Programmordner kopiert),
>> Dort werden sie von Windows Update nicht entdeckt und nicht aktualisiert;
>
> Aber die müssen/sollen ja auch nicht geupdatet werden - das sind
> ja die speziellen MSVC-DLLs für _genau_diese_ Software.
>
>> Siehe <https://support.microsoft.com/kb/326922> und neuere MSKB-Artikel.
>
> Dieser Artikel geht nur bis VC++2005.
und gilt sinngemaess auch fuer neuere Versionen!
> Für VC++2017 schreibt der Hersteller der Fremd-DLLs:
[...]
> Also führt wohl nichts am Aufruf von vc_redist.x86.exe vorbei...
Nur wenn Microsoft keine *.MSM fuer die benoetigte Version der MSVCRT
bereitstellt.
ABER: *.MSM aelterer Versionen werden von Windows Update nicht erkannt,
sodass die notwendigen (Sicherheits-)Updates nicht installiert werden!
>>> Das ist natürlich ein systematisches Problem - wie löst man das denn am
>>> besten?
>> Durch Bauen eines *.MSI
>
> Ich kann InstallShield (durch Weglassen des Häkchens bei "Installer
> inkludieren") schon dazu bringen, ein MSI statt ein EXE zu produzieren.
Kannst Du InstallShield auch beibringen, *.MSI nicht mit ihren proprietaeren
Skripts zu versauen?
> Aber das löst ja nicht das grundsätzliche Problem während der Installation.
Doch: saubere *.MSI rufen keine externen Programme auf!
> Stefan Kanthak schrieb:
>>
>> AUSFUEHRBARE Installationspakete sind defekt per Design und ALLE kaputt:
>> siehe <https://skanthak.homepage.t-online.de/~execute.html>
>
> The requested URL /~execute.html was not found on this server.
>>> im System benötigen. Bisher habe ich die beiden dazu nötigen Dateien
>>> (MSVC...DLL) einfach mitinstalliert (=mit in den Programmordner kopiert),
>> Dort werden sie von Windows Update nicht entdeckt und nicht aktualisiert;
>
> Aber die müssen/sollen ja auch nicht geupdatet werden - das sind
> ja die speziellen MSVC-DLLs für _genau_diese_ Software.
>
>> Siehe <https://support.microsoft.com/kb/326922> und neuere MSKB-Artikel.
>
> Dieser Artikel geht nur bis VC++2005.
> Für VC++2017 schreibt der Hersteller der Fremd-DLLs:
> Also führt wohl nichts am Aufruf von vc_redist.x86.exe vorbei...
bereitstellt.
ABER: *.MSM aelterer Versionen werden von Windows Update nicht erkannt,
sodass die notwendigen (Sicherheits-)Updates nicht installiert werden!
>>> Das ist natürlich ein systematisches Problem - wie löst man das denn am
>>> besten?
>> Durch Bauen eines *.MSI
>
> Ich kann InstallShield (durch Weglassen des Häkchens bei "Installer
> inkludieren") schon dazu bringen, ein MSI statt ein EXE zu produzieren.
Skripts zu versauen?
> Aber das löst ja nicht das grundsätzliche Problem während der Installation.
Edzard Egberts
Jul 3, 2017, 2:22:48 AM7/3/17
to
Claus Reibenstein wrote:
> Edzard Egberts schrieb am 30.06.2017 um 15:10:
>> Garantiert mir Microsoft, dass so eine Aktualisierung mein Programm
>> nicht kaputt macht?
>
> Gute Frage. Nächste Frage: Garaniert Dir irgendjemand, dass diese DLLs
> keine Sicherheitslücken enthalten und deshalb nicht gepflegt werden
> müssen? Garantierst Du das Deinen Kunden? Übernimmst Du die volle
> Verantwortung dafür?
Dafür, dass ich nicht alle Sicherheitslücken beheben muss, benutze ich
> Edzard Egberts schrieb am 30.06.2017 um 15:10:
>> Garantiert mir Microsoft, dass so eine Aktualisierung mein Programm
>> nicht kaputt macht?
>
> Gute Frage. Nächste Frage: Garaniert Dir irgendjemand, dass diese DLLs
> keine Sicherheitslücken enthalten und deshalb nicht gepflegt werden
> müssen? Garantierst Du das Deinen Kunden? Übernimmst Du die volle
> Verantwortung dafür?
ein OS, statt barebone zu Programmieren.
Ein Beispiel: Zur Zeit arbeite ich an Wolkenerkennung mit der OpenCV -
das Programm bekommt Fotos als Input und wirft Tabellen und Grafiken
aus. Ich erwarte von einem Betriebssystem, dass so ein Programm in einer
sicheren Umgebung läuft und ich mich *nicht* um irgendwelche
Sicherheitslücken kümmern muss, gerade bei Programmen, die an sich
nichts sicherheitskritisches unternehmen. Ansonsten könnte ich doch
besser gleich alles selber machen.
Und warum soll ich Verantwortung für Sicherheitslücken in Windows
übernehmen? Nehmen wir den umgekehrten Fall und Microsoft macht eine DLL
kaputt: Dann hat erst der Kunde Ärger, danach der Händler, dann mein
Chef, dann ich. Je nach Problem geht der Ärger dann richtig los und
weitet sich ggf. noch auf Gerichte und Familienangehörige aus. Und jetzt
überlege mal, wer dann die ganze Zeit nicht den geringsten Ärger und
auch gar kein Interesse an einer Fehlerbehebung hat (Tipp: "Fragen Sie
Ihren PC-Händler oder Systemadministrator (aber bloß nicht uns!)")?
Ich übernehme *immer* die volle Verantwortung, da bleibt mir gar nichts
anderes übrig!
Edzard Egberts
Jul 3, 2017, 2:29:29 AM7/3/17
to
Stefan Kanthak wrote:
> "Edzard Egberts" <ne...@edzeg.net> schrieb:
>
>> Stefan Kanthak wrote:
>>> "Matthias Hanft" <m...@hanft.de> schrieb:
> "Edzard Egberts" <ne...@edzeg.net> schrieb:
>
>> Stefan Kanthak wrote:
>>> "Matthias Hanft" <m...@hanft.de> schrieb:
>>>> ich liefere meine eigene Software per InstallShield-Setup-Paket
>>>> an den Anwender aus.
>>>
>>> AUTSCH! AUSFUEHRBARE Installationspakete sind defekt per Design
>>> und ALLE kaputt: siehe
>>> <https://skanthak.homepage.t-online.de/~execute.html>
>>
>> Geht nicht, aber das:
>>
>> http://skanthak.homepage.t-online.de/!execute.html
>>
>> Echt jetzt, das muss man alles beachten, um irgend ein Programm
>> auf Windows zu installieren?
>
> Nein. Das musst Du nur beachten, wenn Du Installationspakete OHNE
> triviale Anfaengerfehler bauen willst.
Gibt es da denn kein schrittweises HowTo oder gar einen Assistenten? Für
>>>> an den Anwender aus.
>>>
>>> AUTSCH! AUSFUEHRBARE Installationspakete sind defekt per Design
>>> und ALLE kaputt: siehe
>>> <https://skanthak.homepage.t-online.de/~execute.html>
>>
>> Geht nicht, aber das:
>>
>> http://skanthak.homepage.t-online.de/!execute.html
>>
>> Echt jetzt, das muss man alles beachten, um irgend ein Programm
>> auf Windows zu installieren?
>
> Nein. Das musst Du nur beachten, wenn Du Installationspakete OHNE
> triviale Anfaengerfehler bauen willst.
jeden popeligen Scheiß, wo man zwei oder drei Häkchen setzen müsste,
gibt es doch einen - warum ist so eine wichtige Sache so unsinnig
kompliziert?
>> Garantiert mir Microsoft, dass so eine Aktualisierung mein
>> Programm nicht kaputt macht?
>
> Laut Microsoft sind MSVCRT abwaertskompatibel; falls nicht haben sie
> einen Fehler gemacht, den sie wiederum laut eigener Aussage
> kostenlos korrigieren.
nach, steht man dann einfach im Regen und muss sehen, wo man bleibt.
Oder man hat sich gerade ein schönes neues Vista gekauft und muss direkt
ein Downgrade machen... ;o)
Stefan Kanthak
Jul 3, 2017, 7:41:59 AM7/3/17
to
"Edzard Egberts" <ne...@edzeg.net> schrieb:
> Claus Reibenstein wrote:
>> Edzard Egberts schrieb am 30.06.2017 um 15:10:
>>> Garantiert mir Microsoft, dass so eine Aktualisierung mein Programm
>>> nicht kaputt macht?
>>
>> Gute Frage. Nächste Frage: Garaniert Dir irgendjemand, dass diese DLLs
>> keine Sicherheitslücken enthalten und deshalb nicht gepflegt werden
>> müssen? Garantierst Du das Deinen Kunden? Übernimmst Du die volle
>> Verantwortung dafür?
>
> Dafür, dass ich nicht alle Sicherheitslücken beheben muss, benutze ich
> ein OS, statt barebone zu Programmieren.
Dann informiere Dich ENDLICH ueber die Funktionsweise und die daraus
resultierenden Schwachstellen des von Dir missbrauchten OS: eine GANZE
Reihe von Sicherheitsluecken baust Du durch Ignoranz in Deine Programme
ein.
> Claus Reibenstein wrote:
>> Edzard Egberts schrieb am 30.06.2017 um 15:10:
>>> Garantiert mir Microsoft, dass so eine Aktualisierung mein Programm
>>> nicht kaputt macht?
>>
>> Gute Frage. Nächste Frage: Garaniert Dir irgendjemand, dass diese DLLs
>> keine Sicherheitslücken enthalten und deshalb nicht gepflegt werden
>> müssen? Garantierst Du das Deinen Kunden? Übernimmst Du die volle
>> Verantwortung dafür?
>
> Dafür, dass ich nicht alle Sicherheitslücken beheben muss, benutze ich
> ein OS, statt barebone zu Programmieren.
resultierenden Schwachstellen des von Dir missbrauchten OS: eine GANZE
Reihe von Sicherheitsluecken baust Du durch Ignoranz in Deine Programme
ein.
Stefan Kanthak
Jul 3, 2017, 8:08:54 AM7/3/17
to
"Edzard Egberts" <ne...@edzeg.net> schrieb:
> Stefan Kanthak wrote:
>> "Edzard Egberts" <ne...@edzeg.net> schrieb:
>>
>>> Stefan Kanthak wrote:
>>>> "Matthias Hanft" <m...@hanft.de> schrieb:
>>>>> ich liefere meine eigene Software per InstallShield-Setup-Paket
>>>>> an den Anwender aus.
>>>>
>>>> AUTSCH! AUSFUEHRBARE Installationspakete sind defekt per Design
>>>> und ALLE kaputt: siehe
>>>> <https://skanthak.homepage.t-online.de/~execute.html>
>>>
>>> Geht nicht, aber das:
>>>
>>> http://skanthak.homepage.t-online.de/!execute.html
>>>
>>> Echt jetzt, das muss man alles beachten, um irgend ein Programm
>>> auf Windows zu installieren?
>>
>> Nein. Das musst Du nur beachten, wenn Du Installationspakete OHNE
>> triviale Anfaengerfehler bauen willst.
>
> Gibt es da denn kein schrittweises HowTo oder gar einen Assistenten?
Wozu?
> Stefan Kanthak wrote:
>> "Edzard Egberts" <ne...@edzeg.net> schrieb:
>>
>>> Stefan Kanthak wrote:
>>>> "Matthias Hanft" <m...@hanft.de> schrieb:
>>>>> ich liefere meine eigene Software per InstallShield-Setup-Paket
>>>>> an den Anwender aus.
>>>>
>>>> AUTSCH! AUSFUEHRBARE Installationspakete sind defekt per Design
>>>> und ALLE kaputt: siehe
>>>> <https://skanthak.homepage.t-online.de/~execute.html>
>>>
>>> Geht nicht, aber das:
>>>
>>> http://skanthak.homepage.t-online.de/!execute.html
>>>
>>> Echt jetzt, das muss man alles beachten, um irgend ein Programm
>>> auf Windows zu installieren?
>>
>> Nein. Das musst Du nur beachten, wenn Du Installationspakete OHNE
>> triviale Anfaengerfehler bauen willst.
>
> Gibt es da denn kein schrittweises HowTo oder gar einen Assistenten?
InstallationsPROGRAMME sind Mist, da sie von unbedarften Benutzern in
UNSICHERER Umgebung ausgefuehrt werden.
JFTR: Installationsprogramme sind keine Benutzerprogramme, sondern
SYSTEM-Programme.
JEDES Betruebssystem kennt mindestens ein NATIVES Format fuer
NICHT-ausfuehrbare Installationspakete und bringt alles Notwendige mit,
um diese Pakete SICHER zu installieren.
Bei Windows ist das seit ueber 20 Jahren das SetupAPI, das (in *.CAB
eingepackte und komprimierte) Dateien per *.INF installiert; seit dem
letzten Jahrtausend gibt's ausserdem den Windows Installer, der *.MSI
in EINER Transaktion installiert.
> Für jeden popeligen Scheiß, wo man zwei oder drei Häkchen setzen müsste,
> gibt es doch einen - warum ist so eine wichtige Sache so unsinnig
> kompliziert?
Bau ein Installationspaket in dem vom OS unterstuetzten Paketformat.
>>> Garantiert mir Microsoft, dass so eine Aktualisierung mein
>>> Programm nicht kaputt macht?
>>
>> Laut Microsoft sind MSVCRT abwaertskompatibel; falls nicht haben sie
>> einen Fehler gemacht, den sie wiederum laut eigener Aussage
>> kostenlos korrigieren.
>
> Würde ich auch sagen, wo finde ich diese Garantie?
Raymond Chen, ...
> Meiner Erfahrung nach, steht man dann einfach im Regen und muss sehen,
> wo man bleibt.
> Oder man hat sich gerade ein schönes neues Vista gekauft und muss direkt
> ein Downgrade machen... ;o)
SAUBER gefrickelte Windows-Programme, die die MINIMAL-Forderungen der
ueber 22 Jahre alten "Designed for Windows"-Richtlinien erfuellen,
laufen auch heute noch.
Edzard Egberts
Jul 3, 2017, 8:17:16 AM7/3/17
to
Stefan Kanthak wrote:
> "Edzard Egberts" <ne...@edzeg.net> schrieb:
>
>> Claus Reibenstein wrote:
>>> Edzard Egberts schrieb am 30.06.2017 um 15:10:
>>>> Garantiert mir Microsoft, dass so eine Aktualisierung mein
>>>> Programm nicht kaputt macht?
>>>
>>> Gute Frage. Nächste Frage: Garaniert Dir irgendjemand, dass diese
>>> DLLs keine Sicherheitslücken enthalten und deshalb nicht gepflegt
>>> werden müssen? Garantierst Du das Deinen Kunden? Übernimmst Du
>>> die volle Verantwortung dafür?
>>
>> Dafür, dass ich nicht alle Sicherheitslücken beheben muss, benutze
>> ich ein OS, statt barebone zu Programmieren.
>
> Dann informiere Dich ENDLICH ueber die Funktionsweise und die daraus
> resultierenden Schwachstellen des von Dir missbrauchten OS: eine
> GANZE Reihe von Sicherheitsluecken baust Du durch Ignoranz in Deine
> Programme ein.
Ich weiß, es ist viel verlangt, aber bitte nenne mir doch mindestens ein
> "Edzard Egberts" <ne...@edzeg.net> schrieb:
>
>> Claus Reibenstein wrote:
>>> Edzard Egberts schrieb am 30.06.2017 um 15:10:
>>>> Garantiert mir Microsoft, dass so eine Aktualisierung mein
>>>> Programm nicht kaputt macht?
>>>
>>> Gute Frage. Nächste Frage: Garaniert Dir irgendjemand, dass diese
>>> DLLs keine Sicherheitslücken enthalten und deshalb nicht gepflegt
>>> werden müssen? Garantierst Du das Deinen Kunden? Übernimmst Du
>>> die volle Verantwortung dafür?
>>
>> Dafür, dass ich nicht alle Sicherheitslücken beheben muss, benutze
>> ich ein OS, statt barebone zu Programmieren.
>
> Dann informiere Dich ENDLICH ueber die Funktionsweise und die daraus
> resultierenden Schwachstellen des von Dir missbrauchten OS: eine
> GANZE Reihe von Sicherheitsluecken baust Du durch Ignoranz in Deine
> Programme ein.
Beispiel dafür, das ich verstehe (oder von dem Du erwartest, dass das
irgend ein anderer verstehen könnte ;o) und am Besten auch sofort
anwenden kann. Mir bleibt nämlich völlig unverständlich, wie ein
triviales Programm (z.B. eine Textverarbeitung oder ein Paint), das nur
die Windows-API verwendet, Sicherheitslücken öffnen könnte, die nicht
sowieso schon in Windows vorhanden sind.
Warum soll es das Problem des Programmierers sein, wenn ein Programm
ohne sicherheitsrelevante Funktionen, das ganz normal mit Userrechten
läuft, irgendwelche Sicherheitslücken erzeugen kann? Das ist doch
einfach nur ein Komplettversagen des Betriebssystems und nur deshalb ein
Problem, weil MS so etwas eben auf die Anwender abwälzt. An "WannaCry"
ist inzwischen ja auch die NSA schuld (weil die die Lücke nicht
veröffentlich haben) und nicht MS (obwohl die die Lücke programmiert
haben)... :o/
Stefan Kanthak
Jul 3, 2017, 10:23:34 AM7/3/17
to
"Edzard Egberts" <ne...@edzeg.net> schrieb:
> Stefan Kanthak wrote:
>> "Edzard Egberts" <ne...@edzeg.net> schrieb:
>>
>>> Claus Reibenstein wrote:
>>>> Edzard Egberts schrieb am 30.06.2017 um 15:10:
>>>>> Garantiert mir Microsoft, dass so eine Aktualisierung mein
>>>>> Programm nicht kaputt macht?
>>>>
>>>> Gute Frage. Nächste Frage: Garaniert Dir irgendjemand, dass diese
>>>> DLLs keine Sicherheitslücken enthalten und deshalb nicht gepflegt
>>>> werden müssen? Garantierst Du das Deinen Kunden? Übernimmst Du
>>>> die volle Verantwortung dafür?
>>>
>>> Dafür, dass ich nicht alle Sicherheitslücken beheben muss, benutze
>>> ich ein OS, statt barebone zu Programmieren.
>>
>> Dann informiere Dich ENDLICH ueber die Funktionsweise und die daraus
>> resultierenden Schwachstellen des von Dir missbrauchten OS: eine
>> GANZE Reihe von Sicherheitsluecken baust Du durch Ignoranz in Deine
>> Programme ein.
>
> Ich weiß, es ist viel verlangt, aber bitte nenne mir doch mindestens ein
> Beispiel dafür, das ich verstehe (oder von dem Du erwartest, dass das
> irgend ein anderer verstehen könnte ;o) und am Besten auch sofort
> anwenden kann. Mir bleibt nämlich völlig unverständlich, wie ein
> triviales Programm (z.B. eine Textverarbeitung oder ein Paint), das nur
> die Windows-API verwendet, Sicherheitslücken öffnen könnte, die nicht
> sowieso schon in Windows vorhanden sind.
Hierzufred geht's NICHT um triviale (und in SICHEREN Verzeichnissen
installierte) Programme, sondern um Installations-Programme, die
typischerweise mit Administratorrechten laufen und in UNSICHEREN
Verzeichnissen gestartet werden.
> Warum soll es das Problem des Programmierers sein, wenn ein Programm
> ohne sicherheitsrelevante Funktionen, das ganz normal mit Userrechten
> läuft, irgendwelche Sicherheitslücken erzeugen kann?
Seit Anbeginn der Zeiten von MS-DOS und dessen Nachfolger Windows ist
. alias CWD im Suchpfad.
Die daraus resultierenden Schwachstellen sind seit ueber 20 Jahren
wohlbekannt und wohldokumentiert, u.a. im Auftrag der NSA: siehe
<http://www.blacksheepnetworks.com/security/info/nt/ntintrotosec.htm>.
Spaetestens nach <http://www.guninski.com/officedll.html> alias
<https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2000-0854> alias
<https://cwe.mitre.org/data/definitions/426.html> alias
<https://cwe.mitre.org/data/definitions/427.html> sowie
<https://capec.mitre.org/data/definitions/471.html>,
<https://blogs.msdn.microsoft.com/david_leblanc/2008/02/20/dll-preloading-attacks/>
<https://insights.sei.cmu.edu/cert/2008/09/carpet-bombing-and-directory-poisoning.html>
<https://blogs.technet.microsoft.com/srd/2009/04/14/ms09-014-addressing-the-safari-carpet-bomb-vulnerability/>,
<https://blogs.technet.microsoft.com/srd/2010/08/23/more-information-about-the-dll-preloading-remote-attack-vector/>,
<https://blogs.technet.microsoft.com/srd/2010/08/31/an-update-on-the-dll-preloading-remote-attack-vector/>,
<https://support.microsoft.com/en-us/kb/2264107> und
<http://www.binaryplanting.com/> sollte sie JEDER Windows-Programmierer
kennen.
Ebenso wohlbekannt und wohldokumentiert ist, dass das Anwendungsverzeichnis
an erster Stelle im Suchpfad steht.
Siehe <https://msdn.microsoft.com/en-us/library/ff919712.aspx>,
<https://msdn.microsoft.com/en-us/library/ms682586.aspx>,
<https://technet.microsoft.com/en-us/library/2269637.aspx>,
<https://support.microsoft.com/en-us/kb/2389418>,
<https://support.microsoft.com/en-us/kb/2533623> und
<https://blogs.technet.microsoft.com/srd/2014/05/13/load-library-safely/>
plus
<https://insights.sei.cmu.edu/cert/2016/06/bypassing-application-whitelisting.html>
Bei INSTALLIERTEN Programmen ist das Anwendungsverzeichnis sicher, bei
Installations-Programmen dagegen (typischerweise) NICHT!
Fuer letzteres siehe <http://seclists.org/bugtraq/2016/Jul/110> alias
<http://seclists.org/fulldisclosure/2016/Jul/63> sowie
<http://seclists.org/fulldisclosure/2017/Jun/34> und dessen FUENFZIG
Vorgaenger.
Findest Du CVE-2010-3190, CVE-2014-0315, CVE-2015-8264, CVE-2016-0014,
CVE-2016-0602, CVE-2016-0603, CVE-2016-1014, CVE-2016-1281, CVE-2016-1742,
CVE-2016-4247, CVE-2016-6804, CVE-2016-7085, CVE-2016-1000331,
CVE-2016-1000332, CVE-2016-7804, CVE-2017-2107 und CVE-2017-5688 selbst?
Oder <https://cwe.mitre.org/data/definitions/377.html> und
<https://cwe.mitre.org/data/definitions/379.html>?
> Das ist doch einfach nur ein Komplettversagen des Betriebssystems und
> nur deshalb ein Problem, weil MS so etwas eben auf die Anwender abwälzt.
Es ist DOKUMENTIERTES Verhalten, das Programmierer beachten MUESSEN und
beeinflussen KOENNEN: <https://skanthak.homepage.t-online.de/!execute.html>
beschreibt letzteres, auch fuer Dich!
Unter <https://skanthak.homepage.t-online.de/sentinel.html> und
<https://skanthak.homepage.t-online.de/verifier.html> findest Du mehr.
> An "WannaCry" ist inzwischen ja auch die NSA schuld (weil die die Lücke
> nicht veröffentlich haben) und nicht MS (obwohl die die Lücke programmiert
> haben)... :o/
Falsch.
Microsoft hat diesen Fehler NICHT mit Absicht eingebaut; die NSA dagegen
hat den Fehler mit ABSICHT ausgenutzt und mit ABSICHT nicht an Microsoft
gemeldet. Anschliessend war die NSA unfaehig, ihre "Waffen" zu sichern.
Von WannaCry betroffen sind nur Leute, die ihre Systeme nicht ordentlich
warten: nach Veroeffentlichung der Luecke durch die "Shadow Brokers" war
voellig klar, dass diese ausgenutzt werden wuerde.
Microsoft hat die Korrektur VOR dieser Veroeffentlichung herausgegeben,
zwei Monate bevor WannaCry in Umlauf gebracht wurde.
Microsoft empfiehlt schon ETWAS laenger, SMB/CIFS nicht ueber's Internet
freizugeben, sowie SMB1 abzuschalten.
> Stefan Kanthak wrote:
>> "Edzard Egberts" <ne...@edzeg.net> schrieb:
>>
>>> Claus Reibenstein wrote:
>>>> Edzard Egberts schrieb am 30.06.2017 um 15:10:
>>>>> Garantiert mir Microsoft, dass so eine Aktualisierung mein
>>>>> Programm nicht kaputt macht?
>>>>
>>>> Gute Frage. Nächste Frage: Garaniert Dir irgendjemand, dass diese
>>>> DLLs keine Sicherheitslücken enthalten und deshalb nicht gepflegt
>>>> werden müssen? Garantierst Du das Deinen Kunden? Übernimmst Du
>>>> die volle Verantwortung dafür?
>>>
>>> Dafür, dass ich nicht alle Sicherheitslücken beheben muss, benutze
>>> ich ein OS, statt barebone zu Programmieren.
>>
>> Dann informiere Dich ENDLICH ueber die Funktionsweise und die daraus
>> resultierenden Schwachstellen des von Dir missbrauchten OS: eine
>> GANZE Reihe von Sicherheitsluecken baust Du durch Ignoranz in Deine
>> Programme ein.
>
> Ich weiß, es ist viel verlangt, aber bitte nenne mir doch mindestens ein
> Beispiel dafür, das ich verstehe (oder von dem Du erwartest, dass das
> irgend ein anderer verstehen könnte ;o) und am Besten auch sofort
> anwenden kann. Mir bleibt nämlich völlig unverständlich, wie ein
> triviales Programm (z.B. eine Textverarbeitung oder ein Paint), das nur
> die Windows-API verwendet, Sicherheitslücken öffnen könnte, die nicht
> sowieso schon in Windows vorhanden sind.
installierte) Programme, sondern um Installations-Programme, die
typischerweise mit Administratorrechten laufen und in UNSICHEREN
Verzeichnissen gestartet werden.
> Warum soll es das Problem des Programmierers sein, wenn ein Programm
> ohne sicherheitsrelevante Funktionen, das ganz normal mit Userrechten
> läuft, irgendwelche Sicherheitslücken erzeugen kann?
. alias CWD im Suchpfad.
Die daraus resultierenden Schwachstellen sind seit ueber 20 Jahren
wohlbekannt und wohldokumentiert, u.a. im Auftrag der NSA: siehe
<http://www.blacksheepnetworks.com/security/info/nt/ntintrotosec.htm>.
Spaetestens nach <http://www.guninski.com/officedll.html> alias
<https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2000-0854> alias
<https://cwe.mitre.org/data/definitions/426.html> alias
<https://cwe.mitre.org/data/definitions/427.html> sowie
<https://capec.mitre.org/data/definitions/471.html>,
<https://blogs.msdn.microsoft.com/david_leblanc/2008/02/20/dll-preloading-attacks/>
<https://insights.sei.cmu.edu/cert/2008/09/carpet-bombing-and-directory-poisoning.html>
<https://blogs.technet.microsoft.com/srd/2009/04/14/ms09-014-addressing-the-safari-carpet-bomb-vulnerability/>,
<https://blogs.technet.microsoft.com/srd/2010/08/23/more-information-about-the-dll-preloading-remote-attack-vector/>,
<https://blogs.technet.microsoft.com/srd/2010/08/31/an-update-on-the-dll-preloading-remote-attack-vector/>,
<https://support.microsoft.com/en-us/kb/2264107> und
<http://www.binaryplanting.com/> sollte sie JEDER Windows-Programmierer
kennen.
Ebenso wohlbekannt und wohldokumentiert ist, dass das Anwendungsverzeichnis
an erster Stelle im Suchpfad steht.
Siehe <https://msdn.microsoft.com/en-us/library/ff919712.aspx>,
<https://msdn.microsoft.com/en-us/library/ms682586.aspx>,
<https://technet.microsoft.com/en-us/library/2269637.aspx>,
<https://support.microsoft.com/en-us/kb/2389418>,
<https://support.microsoft.com/en-us/kb/2533623> und
<https://blogs.technet.microsoft.com/srd/2014/05/13/load-library-safely/>
plus
<https://insights.sei.cmu.edu/cert/2016/06/bypassing-application-whitelisting.html>
Bei INSTALLIERTEN Programmen ist das Anwendungsverzeichnis sicher, bei
Installations-Programmen dagegen (typischerweise) NICHT!
Fuer letzteres siehe <http://seclists.org/bugtraq/2016/Jul/110> alias
<http://seclists.org/fulldisclosure/2016/Jul/63> sowie
<http://seclists.org/fulldisclosure/2017/Jun/34> und dessen FUENFZIG
Vorgaenger.
Findest Du CVE-2010-3190, CVE-2014-0315, CVE-2015-8264, CVE-2016-0014,
CVE-2016-0602, CVE-2016-0603, CVE-2016-1014, CVE-2016-1281, CVE-2016-1742,
CVE-2016-4247, CVE-2016-6804, CVE-2016-7085, CVE-2016-1000331,
CVE-2016-1000332, CVE-2016-7804, CVE-2017-2107 und CVE-2017-5688 selbst?
Oder <https://cwe.mitre.org/data/definitions/377.html> und
<https://cwe.mitre.org/data/definitions/379.html>?
> Das ist doch einfach nur ein Komplettversagen des Betriebssystems und
> nur deshalb ein Problem, weil MS so etwas eben auf die Anwender abwälzt.
beeinflussen KOENNEN: <https://skanthak.homepage.t-online.de/!execute.html>
beschreibt letzteres, auch fuer Dich!
Unter <https://skanthak.homepage.t-online.de/sentinel.html> und
<https://skanthak.homepage.t-online.de/verifier.html> findest Du mehr.
> An "WannaCry" ist inzwischen ja auch die NSA schuld (weil die die Lücke
> nicht veröffentlich haben) und nicht MS (obwohl die die Lücke programmiert
> haben)... :o/
Microsoft hat diesen Fehler NICHT mit Absicht eingebaut; die NSA dagegen
hat den Fehler mit ABSICHT ausgenutzt und mit ABSICHT nicht an Microsoft
gemeldet. Anschliessend war die NSA unfaehig, ihre "Waffen" zu sichern.
Von WannaCry betroffen sind nur Leute, die ihre Systeme nicht ordentlich
warten: nach Veroeffentlichung der Luecke durch die "Shadow Brokers" war
voellig klar, dass diese ausgenutzt werden wuerde.
Microsoft hat die Korrektur VOR dieser Veroeffentlichung herausgegeben,
zwei Monate bevor WannaCry in Umlauf gebracht wurde.
Microsoft empfiehlt schon ETWAS laenger, SMB/CIFS nicht ueber's Internet
freizugeben, sowie SMB1 abzuschalten.
Edzard Egberts
Jul 4, 2017, 2:25:52 AM7/4/17
to
>> Stefan Kanthak wrote:
>>> Dann informiere Dich ENDLICH ueber die Funktionsweise und die
>>> daraus resultierenden Schwachstellen des von Dir missbrauchten
>>> OS: eine GANZE Reihe von Sicherheitsluecken baust Du durch
>>> Ignoranz in Deine Programme ein.
>>
>> Ich weiß, es ist viel verlangt, aber bitte nenne mir doch
>> mindestens ein Beispiel dafür, das ich verstehe (oder von dem Du
>> erwartest, dass das irgend ein anderer verstehen könnte ;o) und am
>> Besten auch sofort anwenden kann. Mir bleibt nämlich völlig
>> unverständlich, wie ein triviales Programm (z.B. eine
>> Textverarbeitung oder ein Paint), das nur die Windows-API
>> verwendet, Sicherheitslücken öffnen könnte, die nicht sowieso schon
>> in Windows vorhanden sind.
>
> Hierzufred geht's NICHT um triviale (und in SICHEREN Verzeichnissen
> installierte) Programme, sondern um Installations-Programme, die
> typischerweise mit Administratorrechten laufen und in UNSICHEREN
> Verzeichnissen gestartet werden.
Aha und in dem Zustand könnte das Windows "geentert" werden.
>>> Dann informiere Dich ENDLICH ueber die Funktionsweise und die
>>> daraus resultierenden Schwachstellen des von Dir missbrauchten
>>> OS: eine GANZE Reihe von Sicherheitsluecken baust Du durch
>>> Ignoranz in Deine Programme ein.
>>
>> Ich weiß, es ist viel verlangt, aber bitte nenne mir doch
>> mindestens ein Beispiel dafür, das ich verstehe (oder von dem Du
>> erwartest, dass das irgend ein anderer verstehen könnte ;o) und am
>> Besten auch sofort anwenden kann. Mir bleibt nämlich völlig
>> unverständlich, wie ein triviales Programm (z.B. eine
>> Textverarbeitung oder ein Paint), das nur die Windows-API
>> verwendet, Sicherheitslücken öffnen könnte, die nicht sowieso schon
>> in Windows vorhanden sind.
>
> Hierzufred geht's NICHT um triviale (und in SICHEREN Verzeichnissen
> installierte) Programme, sondern um Installations-Programme, die
> typischerweise mit Administratorrechten laufen und in UNSICHEREN
> Verzeichnissen gestartet werden.
>> Warum soll es das Problem des Programmierers sein, wenn ein
>> Programm ohne sicherheitsrelevante Funktionen, das ganz normal mit
>> Userrechten läuft, irgendwelche Sicherheitslücken erzeugen kann?
>
> Seit Anbeginn der Zeiten von MS-DOS und dessen Nachfolger Windows
> ist . alias CWD im Suchpfad. Die daraus resultierenden Schwachstellen
> sind seit ueber 20 Jahren wohlbekannt und wohldokumentiert, u.a. im
> Auftrag der NSA: siehe
> <http://www.blacksheepnetworks.com/security/info/nt/ntintrotosec.htm>.
Jahren, diese Lücke zu schließen?
Doppelclick auf Anhänge? Der Klassiker, eine der schlimmsten Sachen, die
MS jemals verbockt hat, aber ist ja soooo bequem und den Ärger hat
sowieso nur der User, der es ja sooo bequem haben muss. Jetzt alle eine
Runde Mitleid?
<snip>
Das ist alles so viel, ich arbeite hier nicht für MS, weißt Du. Und
entschuldige bitte, so viel Mühe solltest Du Dir wirklich nicht machen!
Ich will ja gar nicht mehr für diese Plattform entwickeln und das Ende
ist langsam in Sicht. :o)
Ich bin aber trotzdem einigen Links nachgegangen und habe sogar die
MSI-Beschreibung von Microsoft gefunden - ist ja recht detailliert.
Bei der Wikipedia sind mir aber wieder die Gesichtszüge entgleist:
"Es gibt Hersteller, die Editoren für MSI-Dateien bereithalten, wie z.
B. Flexera Software mit dem Produkt InstallShield. Weitere Produkte sind
Advanced Installer von Caphyon, Wise Installer von Symantec,
AKInstallerMSI von AKApplications und InstallAware von InstallAware
Software Corporation. Auch die Entwicklungsumgebungen Visual Studio (ab
Version 2002) von Microsoft erlauben im begrenzten Umfang die Erstellung
von Windows-Installer-Paketen."
Also weißt Du, so wichtig kann das gar nicht sein, wenn Microsoft selber
es nicht nötig hat, für so etwas Systemwerkzeuge bereit zu stellen. Man
soll sich also ein Produkt kaufen, damit die Windows-Installation sicher
ist? War ja klar, geht nicht um Sicherheit, sondern nur um die Kohle.
>> An "WannaCry" ist inzwischen ja auch die NSA schuld (weil die die
>> Lücke nicht veröffentlich haben) und nicht MS (obwohl die die Lücke
>> programmiert haben)... :o/
>
> Falsch. Microsoft hat diesen Fehler NICHT mit Absicht eingebaut;
Fehler haften muss! Finde ich gut, sonst könnte man auch keine
Atomkraftwerke mit Rissen im Containment betreiben, wie das in
Flamanville geplant ist.
> Microsoft hat die Korrektur VOR dieser Veroeffentlichung
> herausgegeben, zwei Monate bevor WannaCry in Umlauf gebracht wurde.
scheinbar nicht richtig geklappt hat, zigtausend Rechner zu bricken,
damit die Leute endlich eine neue Windows-Version kaufen.
Stefan Kanthak
Jul 4, 2017, 12:05:27 PM7/4/17
to
[...]
>> Hierzufred geht's NICHT um triviale (und in SICHEREN Verzeichnissen
>> installierte) Programme, sondern um Installations-Programme, die
>> typischerweise mit Administratorrechten laufen und in UNSICHEREN
>> Verzeichnissen gestartet werden.
>
> Aha und in dem Zustand könnte das Windows "geentert" werden.
Nicht Windows, sondern das DEFEKTE Installationsprogramm!
>>> Warum soll es das Problem des Programmierers sein, wenn ein
>>> Programm ohne sicherheitsrelevante Funktionen, das ganz normal mit
>>> Userrechten läuft, irgendwelche Sicherheitslücken erzeugen kann?
>>
>> Seit Anbeginn der Zeiten von MS-DOS und dessen Nachfolger Windows
>> ist . alias CWD im Suchpfad. Die daraus resultierenden Schwachstellen
>> sind seit ueber 20 Jahren wohlbekannt und wohldokumentiert, u.a. im
>> Auftrag der NSA: siehe
>> <http://www.blacksheepnetworks.com/security/info/nt/ntintrotosec.htm>.
>
> Stimmt, bei Linux geht das nicht
Wie ueblich: AHNUNGSLOSER DUMMSCHWATZ!
Selbstverstaendlich geht das bei Linux und UNIX: dort kann JEDER Benutzer
export PATH=.:$PATH
ausfuehren!
> - Du meinst MS versäumt es seit 20 Jahren, diese Lücke zu schließen?
Nein. LIES ENDLICH DIE VERLINKTE DOKUMENTATION!
Wieder falsch: Doppelklick auf beliebige Dateien.
Genau wie in JEDER grafischen Oberflaeche anderer Betruebssysteme!
JFTR: bevor Du jetzt wieder ahnungslos "mit *x waer das nicht passiert"
herumpupst:
<https://www.google.de/search?num=100&newwindow=1&q=patrick+wardle+dll+hijacking>
[ Dummschwatz entsorgt ]
> Ich bin aber trotzdem einigen Links nachgegangen und habe sogar die
> MSI-Beschreibung von Microsoft gefunden - ist ja recht detailliert.
> Bei der Wikipedia sind mir aber wieder die Gesichtszüge entgleist:
[...]
> Also weißt Du, so wichtig kann das gar nicht sein, wenn Microsoft selber
> es nicht nötig hat, für so etwas Systemwerkzeuge bereit zu stellen.
Wie ueblich: AHNUNGSLOSER DUMMSCHWATZ!
Microsoft stellt seit dem letzten Jahrtausend Systemwerkzeuge zum Bauen
und Umbauen von *.MSI, *.MSP und *.MST bereit: die findest auch Du in
den kostenlosen "Software Development Kits" fuer Windows!
Wie waer's, Du lernst ENDLICH, selbst zu recherchieren, statt Dummschwatz
der Wikipedia zum Schlechtesten zu geben?
> Man soll sich also ein Produkt kaufen, damit die Windows-Installation
> sicher ist? War ja klar, geht nicht um Sicherheit, sondern nur um die
> Kohle.
Wie ueblich: AHNUNGSLOSER DUMMSCHWATZ!
Es existieren mehrere kostenlose und "open source" MSI-Editoren!
>> Hierzufred geht's NICHT um triviale (und in SICHEREN Verzeichnissen
>> installierte) Programme, sondern um Installations-Programme, die
>> typischerweise mit Administratorrechten laufen und in UNSICHEREN
>> Verzeichnissen gestartet werden.
>
> Aha und in dem Zustand könnte das Windows "geentert" werden.
>>> Warum soll es das Problem des Programmierers sein, wenn ein
>>> Programm ohne sicherheitsrelevante Funktionen, das ganz normal mit
>>> Userrechten läuft, irgendwelche Sicherheitslücken erzeugen kann?
>>
>> Seit Anbeginn der Zeiten von MS-DOS und dessen Nachfolger Windows
>> ist . alias CWD im Suchpfad. Die daraus resultierenden Schwachstellen
>> sind seit ueber 20 Jahren wohlbekannt und wohldokumentiert, u.a. im
>> Auftrag der NSA: siehe
>> <http://www.blacksheepnetworks.com/security/info/nt/ntintrotosec.htm>.
>
> Stimmt, bei Linux geht das nicht
Selbstverstaendlich geht das bei Linux und UNIX: dort kann JEDER Benutzer
export PATH=.:$PATH
ausfuehren!
> - Du meinst MS versäumt es seit 20 Jahren, diese Lücke zu schließen?
Wieder falsch: Doppelklick auf beliebige Dateien.
Genau wie in JEDER grafischen Oberflaeche anderer Betruebssysteme!
JFTR: bevor Du jetzt wieder ahnungslos "mit *x waer das nicht passiert"
herumpupst:
<https://www.google.de/search?num=100&newwindow=1&q=patrick+wardle+dll+hijacking>
[ Dummschwatz entsorgt ]
> Ich bin aber trotzdem einigen Links nachgegangen und habe sogar die
> MSI-Beschreibung von Microsoft gefunden - ist ja recht detailliert.
> Bei der Wikipedia sind mir aber wieder die Gesichtszüge entgleist:
> Also weißt Du, so wichtig kann das gar nicht sein, wenn Microsoft selber
> es nicht nötig hat, für so etwas Systemwerkzeuge bereit zu stellen.
Microsoft stellt seit dem letzten Jahrtausend Systemwerkzeuge zum Bauen
und Umbauen von *.MSI, *.MSP und *.MST bereit: die findest auch Du in
den kostenlosen "Software Development Kits" fuer Windows!
Wie waer's, Du lernst ENDLICH, selbst zu recherchieren, statt Dummschwatz
der Wikipedia zum Schlechtesten zu geben?
> Man soll sich also ein Produkt kaufen, damit die Windows-Installation
> sicher ist? War ja klar, geht nicht um Sicherheit, sondern nur um die
> Kohle.
Es existieren mehrere kostenlose und "open source" MSI-Editoren!
0 new messages