Kosten/Nutzen-Faktor und so.Quote:
Sicheren, sauberen Code zu schreiben ist unnötige Arbeit? Uff, unsere Ansichten sind doch sehr verschieden!
Aber nach C++ Standard.Quote:
Das hatten wir erst vor kurzem und es ist zumindest mit dem Windows Compiler nicht falsch. ;)
Man sollte sich aber allgemein einen guten Stil angewöhnen. In einem Gebiet wie diesem, an dem Anfänger ohnehin nichts verloren haben, finde ich, sollte es einem selbst überlassen werden, ob man diesen beibehält. Inline ASM ist auch kein schöner Stil, genau so wenig wie globale Variablen. Ist da aber auch mal zwingend notwendig.Quote:
Ersetze system() mit DllMain. system hat "lediglich" Performanceschwächen, DllMain kann dir dein Programm killen. Keine Ahnung wie du gewichtest, aber wenn ich die Wahl hätte buße ich lieber etwas performance ein, als mit der Möglichkeit eines Deadlocks weiterarbeiten zu müssen.
Jedenfalls sollte man in seriösen Anwendungen natürlich auf Wartbarkeit und guten Stil achten.
Desweiteren sehe ich DllMain nicht zwingend als schlechten Stil an, nur weil es Probleme geben kann.
system() hat nicht nur Performance-Schwächen.
Und hör bitte auf, immer den Teufel an die Wand zu malen.
Es gibt keine Deadlock-Gefahr, wenn man es richtig macht.
Mir ist doch egal, was irgendwelche Anfänger falsch machen. Ich bin keiner und ich weiß, wie man ordentlich programmiert.Quote:
Aber genau das tuen sie nicht. Viele haben deine Einstellung und sagen "schmutziges Geschäft, schmutziger Programmcode" (so kommt zumindest deine Aussage rüber) und arbeiten dementsprechend. Da muss man einfach hart bleiben und die Leute zum Einlenken bewegen.
Natürlich erlaubt ein schmutziges Geschäft schmutzigen Code, denn manchmal ist dieser unausweichlich.
Du hast die Aussage an dieser Stelle nicht verstanden.Quote:
Das stimmt nicht. Ich kann beides sehr gewissenhaft, robust und performant gestalten. Der Kosten/Nutzen Faktor rechnet sich, nach meinen Erfahrungen, _immer_ in der Programmierung!
Es ging nicht um Performance, sondern darum, dass Dll-Injection selbst schon eine böse Technik ist, wenn da nun noch irgendein lowlevel Kram und viel Pointer Arithmetik dazu kommt, ist das geringste Problem wohl die DllMain.
Siehe oben. Was irgendwelche Warrock Wannabes machen, interessiert mich nicht.Quote:
Siehe oben. Aus "schmutziges Geschäft, schmutziger Programmcode" wächst Code wie dieser: [Only registered and activated users can see links. Click Here To Register...]
Das bezieht sich nicht unbedingt auf dich, aber de facto sind viele Anfänger davon betroffen.
Mit
Code:
void Thread();
Wozu es aber keinen Grund gibt. Rede ich gegen ne Wand?Quote:
Doch, tut es. Wartet er auf Beendigung des Threads ist feierabend.
So wie du hier schreibst, ist dein Ziel aber, ihn/uns von deinem Start() Export zu überzeugen.Quote:
Aber ich bezog mich auch gar nicht auf das Erstellen eines Threads in DllMain. Das ist zwar auch nicht ganz so schön, aber so lange man wirklich nur den Thread erstellt okay.
Schaue dir seinen ursprünglichen Code an, da erstellt er noch keinen Thread und daher auch die ganzen Links mit Infomaterial.
Er hat es auch sofort abgeändert, sprich er hat verstanden worum es geht! Ziel erreicht, mehr wollte ich nicht. ;)
Wenn er nur das macht, ist doch alles schön und gut.
Du philosophierst hier mit mir über die allgemeine Legitimität der DllMain, das hat recht wenig mit seinem Code zu tun.Quote:
Darum geht es mir nicht, da auch das nicht im ursprünglichen Quellcode drinnen war.
Libs != HacksQuote:
Wie bereits gesagt, unsere Ansichten scheinen recht verschieden zu sein. Ich versuche so sauber wie möglich zu arbeiten und da meine Lib open source ist, sitzt der angestrebte Level nocheinmal etwas höher.
Und am Ende war es lediglich mehr Aufwand für mich, der User merkt davon kaum etwas. Das läuft dann so ab:
Natürlich arbeitet man in Libs, gerade in open-source Libs sauber und in einem guten Stil.
Das hat recht wenig mit der Initialisierung eines Hacks zu tun.
Du kannst dem Nutzer deiner Lib aber nicht aufzwingen, eine Start() zu exportieren.
Überhaupt: Wie realisierst du diesen Zwang? oO GetProcAddress() geht ja nur, wenn das Modul bereits geladen ist und hat es eine DllMain, ist es dann bereits zu spät.
Und sonst komme ich gerade auf keine Möglichkeit, zu prüfen, ob es einen Export Start() gibt, außer, du liest die Datei ein und gehst manuell durch die Header.
Sehe ich keinen Nutzen drin.Quote:
Das ist nicht nur sicherer, sondern auch viel flexibler als Code in DllMain zu packen! So kann ich bestimmen wann das Ganze starten soll!
Wenn meine Dll startet, soll auch ihr Thread starten.
Wenn man noch auf was warten will, kann man das ja in diesem tun oder ihn suspended starten.
Aber das ist wohl Ansichtssache.
Mir bietet es weder mehr Sicherheit noch brauche ich die angebliche Flexibilität und den meisten Usern ist eh nur wichtig, dass sie mit ihrem 1hit angeben können.Quote:
Und wenn Sicherheit und Flexibilität für mich ein paar Zeilen Code mehr bedeuten (ich glaube es waren ca. 5 Stück), dann gehe ich den Deal ohne nachzudenken ein!
Die Arbeit sieht der User gar nicht.
@2n0w:
Ein Thread hat den Prototypen
Code:
DWORD WINAPI Thread(LPVOID lpParam); //und nicht BOOL Thread();