Source code schützen und trotzdem modular

http://atmel-studio-doc.s3-website-us-east-1.amazonaws.com/webhelp/GUID-ECD8A826-B1DA-44FC-BE0B-5A53418A47BD-en-US-5/index.html?GUID-C32ADD88-CB66-4995-A6F7-ABB19006CBAF

libs in diesem Umfeld haben allerdings häufig die Eigenschaft, daß das 
Comipilat prozessorspezifisch ist. Wenn das nur für einen Kunden sein 
soll, der nur einen Prozessortyp verwendet, dann ist das kein Problem. 
Ansonsten wirds aufwendig.

Oliver

Elektrolurch schrieb:
> Also nochmal, wie geht das mit einer Bibliothek?

Frage falsch gestellt, Antwort wäre: Es geht mit einer Bibliothek.

Pack deinen geheim-Code in eine vorkompilierte Bibliothek, und liefer 
dazu den main()-Teil und unkritischen Source mit passendem Makefile.

Elektrolurch schrieb:
> Außerdem sind da viele zeitkritische Routinen drin, die Laufzeit darf
> sich praktisch nicht ändern.

Dann ist die Hauptfrage, wie sauber Ihr das alles dokumentiert habt, 
insbesonsere alle Seiteneffekte, damit der Kunde seine Software hinzu 
basteln kann.

Du kannst in der Lib alle internen Symbole entfernen lassen. Nur die 
Aufrufadressen (API) und belegten RAM-Bereiche werden vom Linker 
benötigt.

Das klingt inzwischen nach einfacher Trollerei.

https://www.mikrocontroller.net/topic/545354

Oliver

Dein Geheimcode hat mit Sicherheit Referenzen auf die libc drin. Nun 
hast du zwei Möglichkeiten: Du kannst diese Referenzen schon lösen und 
den relevanten Teil der libc einbinden. Damit blähst du aber das 
Programm auf, denn die Kundenerweiterung und die main() müssen ihre 
Bezüge zur libc erneut auflösen. Oder du linkst die libc erst ganz zum 
Schluss dazu. Damit erleichterst du einem bösen Dieb deines geistigen 
Eigentums die Arbeit. Dein Code ist dann wesentlich leichter zu 
entwirren.

Ein weiterer Punkt: Die Routinen deiner lib haben mit ziemlicher 
Sicherheit vernünftige, lesbare Namen. Auch diese Info hilft dem 
Software Dieb erheblich bei seiner Arbeit. Natürlich kannst du dir die 
Extra Arbeit machen und alle Bezüge mit kryptischen Namen versehen.

Generell solltest du überlegen, ob dein Kunde der richtige für dich ist. 
Gegenseitiges Vertrauen ist bei einer Geschäftsbeziehung wichtig. Ich 
habe in über 50 Jahren Entwicklertätigkeit nur einmal erlebt, dass der 
Kunde mich über den Tisch ziehen wollte. Aber ich habe mehr als ein 
Dutzend mal Aufträge bekommen, ein "Pensionsprogramm" wartbar zu machen, 
weil der ursprüngliche Programmierer keine Lust mehr hatte oder die 
Unterlagen verschollen waren.

Wirkliche Geheimnisse kannst Du Deinem Kuden nur in Hardware überlassen,
etwa in nem Co-Prozessor, der dann die Geheimen Prozeduren ausführt
und deinem Kd. dann die Ergebnisse zurückliefert.
Denn wer Deine Library erhält, erhält auch die *.H-Dateien
Deiner API. Und natürlich die Bibliothek, die er dann mit nem
Disassembler angreifen kann.
Da hilft dann auch kein Parser / Interpreter, denn diesen mußt
Du ja deinem Kd. in der Bibliothek ja auch mitliefern.

mfg

Manche Hersteller, wie z.B. Renesas und TI geben Flash-Routinen nur als 
Binärbibliothek weiter, die Register sind auch nirgends dokumentiert. 
Also sollte das ohne Problem möglich sein, die erforderlichen 
Randbedingungen müssen halt dokumentiert werden.

Jörg

Achja,
wenn Du Deinen Kd. nur von Unfug mit Deiner Library
abhalten willst, schreib dein Programm in C++.
Dann kannst Du mit privaten Routinen den Kd zwingen,
wirklich nur die API zu benutzen, sowie alles richtig zu initialisieren.
Nen Hacker hält diese Verfahrensweise natürich nicht beim
Mißbrauch deiner Arbeit ab.

mfg

Elektrolurch schrieb:
> Außerdem sind da viele zeitkritische Routinen drin, die Laufzeit darf
> sich praktisch nicht ändern.
Was, wenn der Kunde ein for(;;); in seinen Code schreibt?
Läuft eure Software dann unbeeindruckt weiter?

Wenn nicht, dann solltest du schriftlich festhalten, dass ihr nur eure 
Funktion testet und der Kunde für seine Erweiterungen und die damit 
verbundenen Probleme selber verantwortlich ist.

Oliver S. schrieb:
> Das klingt inzwischen nach einfacher Trollerei.
> https://www.mikrocontroller.net/topic/545354
Ich habe die beiden Threads zum selben Thema mal zusammengefasst...

Olaf meinte:

> Bei den Herstellern laeuft es wohl so die noch dafuer sorgen das die
> Einsprungadressen im Binaerfile bekannt sind und bei Ueberarbeitungen an
> der Libarie so auch fest sind. Da brauchst du dann dem Kunden nur ein
> Funktionheader liefern welche diese Adressen aufrufen. Das hat wohl den
> Vorteil das Kunde nicht mit den Libarietools in den Libs rumfummeln
> koennen.

hey.
wie machen die das?
Geben sie im Headerfile die Zeiger auf die öffentlichen
Funktionen an?
Dann braucht ne haeckse ja im Binärfile nur nach den
"privaten" Funktionen zu suchen, die dann von höchstem
Interesse sind... ;-P


mfg

Elektrolurch schrieb:
> Wie man ein GCC-Projekt neu erstellt weis ich natürlich.

Du weißt aber schon dass glibc GPL lizenziert ist und Du deinen 
Sourcecode veröffentlichen musst?

Elektrolurch meinte:

> Was ist eigentlich mit den Atmel-Start Einstellungen / dem Startup-Code
> / ASF4-Code?
> Kommt das in die Bibliothek?

Um den Startup kümmert sich der Compiler / Linker von allein,
denn er wird als Erstes, noch vor "Main" ausgeführt.

> Wie bindet der Kunde die Bibliothek dann in "sein" Projekt ein?

Die Bibliothek kommt wei Windows ins Projektverzeichnis, bei Linux
ins Standardverzeichnis, der Header wird in den Modulen,
die die Bib. benötigen includiert.
Außerdem wird die Lib ins Makefile bzw. in das Buildsystem
bei Windows eingetragen, damit der Linker sie findet.

mfg

Alexander schrieb:
> Elektrolurch schrieb:
>> Wie man ein GCC-Projekt neu erstellt weis ich natürlich.
>
> Du weißt aber schon dass glibc GPL lizenziert ist und Du deinen
> Sourcecode veröffentlichen musst?

Aber doch nur, wenn er diese auch nutzt.

Hab grad versucht herauszufinden welche Heder-Dateien darunter fallen,
hat da einer evtl. ein Link mit einer Übersicht?

Georg G. schrieb:
> Generell solltest du überlegen, ob dein Kunde der richtige für dich ist.
> Gegenseitiges Vertrauen ist bei einer Geschäftsbeziehung wichtig.

Als Kunde würde ich mir vor allem überlegen, ob das der richtige 
Lieferant für mich wäre. Ich kenne mehrere Projekte, bei denen sich der 
Kunde auf die Lieferung vorkompilierter Bibliotheken einließ und sich 
anschließend ziemlich übel abzocken ließ. Abgesehen davon wird natürlich 
auch das Debugging erheblich erschwert, wenn man solch einen Klotz an 
Fremdfirmware unbekannter Qualität in seinem Projekt hat.

In dem einen Fall wurden sämtliche Fehlerberichte abgewiesen, so dass 
das ganze in einem jahrelangen Streit zwischen den Rechtsabteilungen des 
Kunden und des Lieferanten endete. Letztendlich gab es mehrere 
Gerichtsurteile gegen den Lieferanten, die ihn dazu zwangen, Scheibchen 
für Scheibchen des Quellcodes herauszurücken.

In dem anderen Fall musste eine Umstellung des internen Uhrzeitformats 
auf 64 Bit erfolgen, da dies durch äußere Umstände gefordert war. Der 
Lieferant der vorkompilierten Bibliotheken rief dann einen 
siebenstelligen(!) Betrag für die erforderlichen Anpassungen auf.

Alexander schrieb:
> Elektrolurch schrieb:
>> Wie man ein GCC-Projekt neu erstellt weis ich natürlich.
>
> Du weißt aber schon dass glibc GPL lizenziert ist und Du deinen
> Sourcecode veröffentlichen musst?

Also so wie ich das sehe ist es nicht GPL sondern LGPL.
Somit ist eine Offenlegung des Codes nicht nötig.

Adam P. schrieb:
> Also so wie ich das sehe ist es nicht GPL sondern LGPL.
> Somit ist eine Offenlegung des Codes nicht nötig.

Oh das war mir entgangen, war pauschal davon ausgegangen wo GNU drauf 
steht ist auch GPL drin. Der Wikipedia Artikel führt auf wie verlinkt 
werden muss.

https://de.wikipedia.org/wiki/GNU_Lesser_General_Public_License#Bedingungen/technische_Einhaltung

Elektrolurch schrieb:
> Wie müsste die Definition für func_api aussehen?

Na genauso...
Sag mal, wenn schon so elementare Grundfertigkeiten fehlen, wieso meinst 
du dass dein Code irgendwie besonders schützenswert ist?

Kann es nicht eher sein, dass du den Quelltext verstecken willst, damit 
der Kunde nicht sieht was er da für einen Pfusch geliefert bekommt?

Alexander schrieb:
> Du weißt aber schon dass glibc GPL lizenziert ist

Deshalb benutzt in diesem Umfeld (Cortex-M) auch kein Mensch die glibc, 
sondern stattdessen die newlib. Diese wiederum ist aus BSD und 
vergleichbar lizensierten Quellen zusammengestellt.

Wir hatten bei einem früheren Brötchengeber so einen Library-Ansatz mal 
in Erwägung gezogen, waren am Ende aber froh, dass der Kunde sich doch 
lieber dazu bereit erklärt hat, eine Sourcecodelizenz zu kaufen. ;-) Wie 
andere schon erwähnt haben, braucht so ein Lib-Ansatz vieeel Fürsorge in 
der Dokumentation (API, genutzte Hardware-Ressourcen, nötige 
Randbedingungen) sowie in der internen Programmierdisziplin (alle nicht 
als API dokumentierten globalen Funktionen und Objekte müssen "static" 
sein, oder aber die Dokumentation reserviert explizit einen bestimmten 
Namensraum für solche Dinge, und alle halten sich intern dran).

Εrnst B. schrieb:
> Elektrolurch schrieb:
>> Wie müsste die Definition für func_api aussehen?
>
> Na genauso...
> Sag mal, wenn schon so elementare Grundfertigkeiten fehlen, wieso meinst
> du dass dein Code irgendwie besonders schützenswert ist?
>
> Kann es nicht eher sein, dass du den Quelltext verstecken willst, damit
> der Kunde nicht sieht was er da für einen Pfusch geliefert bekommt?

Wenn die Konkurrenz unseren Quellcode in die Hände bekommt, wirft sie 
das um Jahre zurück ;-)

Warum will der Kunde selbst programmieren ?
Lasst ihr euch jeden Furz königlich bezahlen ?.
Dann wird er auch nicht die Kosten für eine Lib und deren Pflege 
übernehmen wollen. Die Entwicklung einer "robusten" Lib mit 
Dokumentation ist nicht so trivial und die Folgekosten, für euch, sind 
schwer kalkulierbar. Behalte dabei immer die Regel: Mache eine 
Schnittstelle so, das sie möglichst "einfach richtig" zu benutzen und 
möglichst "schwer falsch" zu benutzen ist. Ihr könnt natürlich auch 
alles möglich kompliziert machen und dem Kunden Schulungen ohne Ende 
verkaufen ....

Alexander schrieb:
> Du weißt aber schon dass glibc GPL lizenziert ist und Du deinen
> Sourcecode veröffentlichen musst?

Die GNU C Library untersteht der LGPL. Solange er sie nur dynamisch 
linkt, muß er seinen Sourcecode natürlich nicht veröffentlichen.

Ein T. schrieb:
> Solange er sie nur dynamisch linkt

Auf einem Microcontroller?

Aber wie schon geschrieben: glibc ist hier völlig irrelevant.

Jörg W. schrieb:
> Ein T. schrieb:
>> Solange er sie nur dynamisch linkt
>
> Auf einem Microcontroller?

Unabhängig von der Zielplattform war die Aussage, die GNU C Library 
unterliege der GPL, nun einmal falsch.

> Aber wie schon geschrieben: glibc ist hier völlig irrelevant.

Mag sein, ändert aber nichts daran, daß die erwähnte Aussage nun einmal 
falsch ist. Da sie aber auch von Microsoft-MVPs und anderen FUD-Trollen 
verbreitet wird, muß man ihr widersprechen, wo immer man sie findet.

Oder einfach erstmal den Thread lesen bevor man antwortet.

Wurde bereits
hier
Beitrag "Re: Source code schützen und trotzdem modular"

und hier korrigiert.
Beitrag "Re: Source code schützen und trotzdem modular"

Bitte meine Trollbeiträge ignorieren.

Alexander schrieb:
> Bitte meine Trollbeiträge ignorieren.

Trollbeiträge sind das nicht, denn du hast ja nicht vorsätzlich den 
Thread stören wollen.

GCC ist halt das eine, was man damit macht, ist das andere. Bei GCC 
wurde ausdrücklich darauf verzichtet, dass man in irgendeiner Form dem 
Kompilat eine Lizenz aufdrückt – nur der Code des Compilers selbst ist 
GPL (und wenn du ihn änderst oder ergänzt, fallen diese Änderungen 
natürlich darunter).

Ein T. schrieb:
> muß man ihr widersprechen, wo immer man sie findet.

Du darfst dir trotzdem den Kontext vorher ansehen und erkennen, dass 
irgendwelche Anmerkungen in Richtung dynamisches Linken hier schlicht 
off-topic sind.

@A.S.
>> Oder es ist ein fertiges Programm, dass erweitert werden kann. Das
scheint bei Dir der Fall.
Genau.

>> Und ohne weak etc. musst Du bedenken, dass C-Files der Lib immer
komplett eingebunden werden. Also muss die appl alles oder nichts (eines
Files)ersetzen. (Darum sind Files manchmal nur 3 Zeilen groß)
?? Ist das wirklich so?
Also das mit einer weak-Definition in der Library funktioniert nicht?
Oder meinst du, dass die Applikations-Funktion so oder so eine gleich 
lautende Bibliotheksfunktion ersetzt?
Aufgabe ist z.B. dass eine vom Kunden geschriebene Ausgabefunktion von 
einem Timer-Interrupt (in Library) aufgerufen wird.
Ich schätze mal, dass das mit einem Funktionspointer am effizientesten 
machbar ist.

Wenn ich ein Library-Projekt erstelle, habe ich wohl nicht die 
Möglichkeit, dies mit dem Atmel Start Konfigurator zu kombinieren?
Heißt, dass Atmel Start im Kundenprojekt drin sein muss?
Kann ich ASF4 in der Library benutzen?

>> Hier gibt es 2 Mechanismen: entweder "erwartet" die lib 1 oder mehr
konkrete Funktionen/ Datenfelder, die der Kunde in seinen C sourcen
bereitstellt.
Heißt das dass der Linker, eine in der Lib als extern deklarierte 
Funktion,
die in der Applikation definiert ist, einbindet?

Dass keine Verwirrung entsteht, ich habe mich jetzt eingeloggd.
Elektrolurch = Alex...

Ich hatte hier ehrlich gesagt auch zuerst an einen Trollbeitrag gedacht. 
Bitte nicht bös sein aber in einem Unternehmen für solche Entscheidungen 
verantwortlich zu sein ohne jemals eine Bibliothek erstellt zu haben ist 
schon sehr abenteuerlich...

Wie dem auch sei, ich würde dringendst davon abraten. Man könnte in 
Erwägung ziehen ob sich die Integration einer Skriptsprache lohnt (z.B. 
MicroPython) aber alles andere ist ein NO-GO.

Alex schrieb:
> Wenn ich ein Library-Projekt erstelle, habe ich wohl nicht die
> Möglichkeit, dies mit dem Atmel Start Konfigurator zu kombinieren?
> Heißt, dass Atmel Start im Kundenprojekt drin sein muss?
> Kann ich ASF4 in der Library benutzen?

Atmel Start ist in erster Linie ein (ziemlich umständlicher) Wrapper um 
die eigentliche Hardware. Mit Bibliothek oder nicht hat das nicht viel 
zu tun, denn das ist ja Sourcecode (insbesondere habe ich es als 
sackweise Headerfiles in Erinnerung). Eine solche kannst du im Prinzip 
immer erstmal draus bauen.

Aber wie oben schon geschrieben: mit deinem Kenntnisstand hat das auch 
meines Erachtens keinen wirklichen Sinn; ihr werdet damit einfach nicht 
froh werden und einen unzufriedenen Kunden verprellen. Ich habe dir oben 
beschrieben, auf was man bei sowas alles achten müsste, wenn man es als 
Bibliothek rausgeben will – und selbst, wenn man weiß, wie eine 
Bibliothek aufgebaut ist und gebaut wird *), glaub' mir, ist das noch 
verdammt viel Arbeit.

*) Das meint, dass du ungefähr eine Idee hast, was wie in eine 
Bibliothek reingehört, wie die Module da drin organsiert sind, und wie 
der Linker mit alldem zusammen spielt. Das impliziert auch, dass du die 
Tools kennst, die man dafür braucht – und die Frage, ob das irgendeine 
IDE direkt unterstützt, erübrigt sich dann eigentlich. Tut sie's nicht, 
schreibst man sich seine eigenen Makefiles oder nimmt PlattformIO oder 
sowas.

Georg G. schrieb:
> Natürlich kannst du dir die
> Extra Arbeit machen und alle Bezüge mit kryptischen Namen versehen.

Dazu gibt es sogar schon Software, die das automatisch macht. Nennt sich 
Obfucscator.

123 schrieb:
> ob GPL oder LGPL, im embedded bereich ist das beides nicht brauchbar.
> Oder wie soll ich bitte schön dynamisch gegen die lib linken ohne
> windows / linux?

Die LGPL setzt nicht voraus, dass man dynamisch linkt, wenn man 
closed-source machen will, sondern dass die LGPL-Teile von demjenigen, 
dem du das Programm gibst, mit vertretbarem Aufwand ausgetauscht werden 
können. Das dynamische Linken ist nicht die einzige Möglichkeit, das zu 
erreichen.

@A.S. und die Anderen, die konstruktive Hilfe geleistet haben: Danke!

Muss die Funktion "foo()" also tatsächlich in eine eigene Datei?

Ich habe mal ein minimalstes Test-Lib-Projekt und zusätzlich ein 
(Kunden-)Testprojekt erstellt. Dann habe ich im Testprojekt bei den
Projekteinstellungen-Linker-Library den Namen meiner Lib eingetragen und 
bei Pfad den Pfad zur library.o eingetragen.
Trotzdem findet der Linker anscheinend meine Bibliotheksfunktionen 
nicht.
Was mache ich falsch? Muss ich die Lib noch mit #include einbinden?
Wenn ich meine Lib compilieren lasse, werden lib.o, lib.d und 
libGccLibrary2.a erstellt. Welche davon muss ich verwenden?
Wie ist sie in den Projekteinstellungen einzutragen?
Danke "für sachdienliche Hinweise"  ;-)

Alex schrieb:
> Muss ich die Lib noch mit #include einbinden?

Bibliotheken werden nicht mittels #include eingebunden, sondern nur die 
zugehörigen Headerdateien, auch wenn sich diese Unsauberkeit im heutigen 
Arduionosprech so etabliert hat. Fehlende Prototypen bzw. (externe) 
Deklarationen fallen aber schon beim Kompilieren und nicht erst beim 
Linken auf.

Ein gefährlicher Fallstrick bei C besteht darin, dass in der Signatur 
einer kompilierten Funktion keine Informationen über die korrekten 
Parameter und Rückgabewerte enthalten sind, sondern sich der Linker 
darauf verlassen muss, dass Aufruf und Funktionsdefinition identisch 
sind. Bei C++ hingegen sind zumindest grobe Informationen über die 
Paramtertypen in der Signatur enthalten, Stichwort "name mangeling".

Damals(tm) hatte ich einen ziemlich merkbefreiten Kollegen. Wenn ihm die 
von einer externen Funktion geforderte Parameterliste nicht gefiel, 
führte er nicht etwa eine entsprechende Konvertierung der Parameter usw. 
durch, sondern schrieb dann mitten in den Quelltext, d.h. vor seine 
gerade in Arbeit befindliche Funktion, eine Deklaration der Art "extern 
int foo(float x)". Damit das dann nicht mit irgendwelche anderen 
Deklarationen kollidierte, verzichtete er auf die entsprechenden 
#include-Anweisungen.

Und nun ratet mal, wer fast nie rechtzeitig mit seiner Arbeit fertig 
wurde, weil er völlig konzeptlos an seinem Code herumdoktert musste, und 
auf wessen Konto etwa 90% aller Fehlerberichte gingen. Um das ganze auch 
noch zu steigern, schickte er manchmal, vorbei an jeglicher 
Qualitätssicherung und reproduzierbaren Builds, seine Binaries als 
offizielle Releases an einen wichtigen Kunden(*). Er verstand auch 
nicht, dass man für einen "clean build" zuerst alles eincheckt, dann 
seine Arbeitskopie wegschmeißt (oder besser beiseitelegt), dann eine 
frische Arbeitskopie auscheckt und kompiliert. Er kompilierte hingegen 
ohne vorheriges Einchecken, schickte die Binaries an den Kunden, löschte 
dann seine Sandbox und checkte frisch aus. Nicht nur er, sondern auch 
die anderen Entwickler stellten anschließend fest, dass der Code nicht 
einmal kompilierte. Und dank des Löschens der alten Arbeitskopie waren 
Teile des Quellcodes unwiderbringlich verloren und mussten von ihm auf 
Grund seiner Erinnerungen noch einmal nachprogrammiert werden. Und damit 
ihm das nicht noch einmal passierte, ging er dann dazu über, am Ende des 
Arbeitstages eine rekursives "cvs add" mit "cvs commit" auf seinem 
Entwicklungsrechner zu machen, so dass dann alle anderen Entwickler beim 
nächsten Update seine ganzen temporären Dateien und sonstigen 
Dateischrott auf ihren Rechnern vorfanden. Und dann verstand er 
überhaupt nicht, warum ihm eines Tages gekündigt wurde.

Zu (*): Die E-Mail-Adresse des technischen Ansprechpartners dieses sehr 
wichtigen Kunden hatte er nur deswegen, weil der zuständige 
Projektleiter dem Kunden empfahl, die Unmengen an Fehlerberichten direkt 
an den Entwickler zu schicken. Niemand ahnte, dass der Entwickler dann 
so blöd sein könnte, seine hingerotzten Binaries direkt an den Kunden zu 
schicken und dem Kunden zu vermitteln, es handele sich dabei um 
offizielle Releases.

@Andreas S.:
Sorry, aber das ist nicht so nett, deine lange Lebensgeschichte mit 
reinzupacken. Diese beantwortet mir meine Fragen nicht.

Alex schrieb:
> @Andreas S.:
> Sorry, aber das ist nicht so nett, deine lange Lebensgeschichte mit
> reinzupacken. Diese beantwortet mir meine Fragen nicht.

Dann heul doch.

Alex schrieb:
> Diese beantwortet mir meine Fragen nicht.

Du wirst leider nicht umhin kommen, dir die Grundlagen zum Linker, 
Objektmodulen und Bibliotheken mal anzulesen. Du kannst nicht erwarten, 
dass dir diese hier in einem Forumsartikel beigebracht werden können.

Früher™ hatte man für sowas bedrucktes Papier. Heutzutage sind Verlage 
wie O'Reilly nett genug, dir das sogar noch online und kostenlos zur 
Verfügung zu stellen – nur lesen musst du es schon noch selbst.

Starthilfe:

https://www.oreilly.com/library/view/programming-embedded-systems/0596009836/ch04.html

Sorry, die Art deiner Fragen zeigt einfach, dass du nicht irgendeine 
spezielle Frage hast (sowas kann man einfach in einem Forum 
beantworten), sondern dass dir die Grundlagen fehlen.

der_eine schrieb:
> stimmt nicht.

Ooooch, nicht nochmal. Wurde zur Genüge durchgekaut und hat mit dem 
Thread nun wirklich gar nichts zu tun.

Wie wäre es, vor der Antwort einfach mal den ganzen Thread zu lesen?