expertenaustausch > comp.os.* > comp.os.ms-windows.programmer

Matthias Hanft (30.06.2017, 10:43)
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
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 (30.06.2017, 11:36)
> 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
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?


Ein Wrapper, der erst den MSVC-Kram installiert und dann Deine
Installation aufruft? Ist das zu trivial?
Matthias Hanft (30.06.2017, 12:29)
Edzard Egberts schrieb:
> 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
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

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 (30.06.2017, 13:16)
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,
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.


Ich habe im ersten Moment an "testweise Programm ausführen
und Fehlercode auswerten" gedacht, LoadLibrary() wäre aber eleganter.

> Wobei sie auf
>
> 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,


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.
Stefan Kanthak (30.06.2017, 14:17)
"Matthias Hanft" <mh> 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
[
Matthias Hanft (30.06.2017, 14:56)
Edzard Egberts schrieb:
>> 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
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
mal davon aus, dass es dann egal ist, ob Build 25008 oder 25017 beim
Anwender installiert ist.

Gruß Matthias.
Matthias Hanft (30.06.2017, 15:04)
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:

--- 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.
Edzard Egberts (30.06.2017, 15:10)
Stefan Kanthak wrote:
> "Matthias Hanft" <mh> schrieb:
> AUTSCH! AUSFUEHRBARE Installationspakete sind defekt per Design und
> ALLE kaputt: siehe
> <https://skanthak.homepage.t-online.de/~execute.html>


Geht nicht, aber das:



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?

> Siehe <https://support.microsoft.com/kb/326922> und neuere
> MSKB-Artikel.
> 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)
Claus Reibenstein (30.06.2017, 16:29)
Edzard Egberts schrieb am 30.06.2017 um 15:10:

> Stefan Kanthak wrote:
> Geht nicht, aber das:
>


Nun ja, ein kleiner Typo. Kann ja mal passieren. Die beiden Zeichen
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!


Das ist Windows doch schon lange.

>> 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?


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?

>>> 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? It's Microsoft, you know ...


> Du willst uns doch veräppeln! ;o) Kanthak? Keine Ahnung. Microsoft? Mit Sicherheit!


Gruß
Claus
Matthias Hanft (30.06.2017, 17:44)
Ich schrieb:
> 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
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 (30.06.2017, 23:55)
"Matthias Hanft" <mh> 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

> 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.


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
[
Stefan Kanthak (01.07.2017, 00:01)
"Edzard Egberts" <news> schrieb:

> Stefan Kanthak wrote:
> Geht nicht, aber das:
>
> 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
[
Edzard Egberts (03.07.2017, 08:21)
Claus Reibenstein wrote:
> Edzard Egberts schrieb am 30.06.2017 um 15:10:
> 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.

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 (03.07.2017, 08:28)
Stefan Kanthak wrote:
> "Edzard Egberts" <news> schrieb:
> 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
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.


Würde ich auch sagen, wo finde ich diese Garantie? 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)
Stefan Kanthak (03.07.2017, 13:29)
"Edzard Egberts" <news> schrieb:

> Claus Reibenstein wrote:
> 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.

Stefan
[

Ähnliche Themen