Source + exe Verschlüsseln

Das man mal für mehrer Plattformen programmiert ist ja eher ein Sonderfall als die Norm und wenn du das willst musst das ja auch in Cpp von Anfang an im Kopf haben.
Warum ich C# for sowas mag ? Weil es deutlich weniger anfällig ist für Memoryleaks, Overflows etc.

Quote:

Weil es deutlich weniger anfällig ist für Memoryleaks, Overflows etc.

Aktuelles C++ präventiert dies so gut wie möglich. Wenn schon soll man ganz C# nutzen. Aber einen Mix sollte man schon allein der Übersicht halber vermeiden.

Wo siehste das Problem mit der Übersicht wenn du Perfomancekritische Sachen in Nativen Code auslagerst ? Versteh mich nicht falsch, mag tatsächlich einfach nur verstehen was genau du meinst.

Normal machste ,wenn du inline Asm benutzt, in Cpp ja vom Prinzip her auch nichts anderes.

Quote:

Originally Posted by dready Wo siehste das Problem mit der Übersicht wenn du Perfomancekritische Sachen in Nativen Code auslagerst ? Versteh mich nicht falsch, mag tatsächlich einfach nur verstehen was genau du meinst. Normal machste ,wenn du inline Asm benutzt, in Cpp ja vom Prinzip her auch nichts anderes.

Deswegen benutzt man auch kein Inline ASM.

Quote:

Originally Posted by Delinquenz Aktuelles C++ präventiert dies so gut wie möglich. Wenn schon soll man ganz C# nutzen. Aber einen Mix sollte man schon allein der Übersicht halber vermeiden.

Was ein Unsinn, es ist Bestpractice, für jede Aufgabe die richtige Sprache zu nutzen und gleichzeitig teilt man dabei das Programm in entsprechende Module und erhöht somit die Wartbarkeit. Jede größere Software arbeitet nach dem Prinzip.

C# ist nicht nur GUI-technisch (btw wer mag schon QT, wenn es MFC gibt :x) einen ganzen Schritt weiter im Komfort als C++, auch mit boost etc. einbezogen.

Quote:

Originally Posted by qkuh Ich empfehle nichts in .NET zu programmieren, was verkauft werden und für die breite Masse erhältlich sein soll. Mit C++ fährt man da besser.

So ein Blödsinn.
Solange man es richtig macht - Ein Necrobit Layer über .NET Assemblys und Ruhe ist im Busch.

@headpuster
auch wenn ich der Meinung bin das man durchaus komerzielle Sachen in C# machen kann. Den Bytecode tatsächlich schützen kannst du nicht. Necrobit Layer hab ich nu nochnich gehört gehabt, aber kurzes nachsehn hat ergeben das das Ding im Endeffekt nicht mehr macht als den Bytecode innerhalb der Funktionen zu Encrypten, Decrypten. Also allerhöchsten eine Milde Hürde.

Quote:

Originally Posted by Headpuster So ein Blödsinn. Solange man es richtig macht - Ein Necrobit Layer über .NET Assemblys und Ruhe ist im Busch.

Und auf gar keinen Fall ProPOLY vergessen!

Auf MrSmith hören, der weiß was Sache ist! (Auch wenn ich hoffe dass MFC > QT ein sehr sehr schlechter Witz war)

Padmak

Nein, es war kein Witz. Ich mag kein QT, habs nicht zum Laufen bekommen :<

Quote:

Originally Posted by dready @headpuster auch wenn ich der Meinung bin das man durchaus komerzielle Sachen in C# machen kann. Den Bytecode tatsächlich schützen kannst du nicht. Necrobit Layer hab ich nu nochnich gehört gehabt, aber kurzes nachsehn hat ergeben das das Ding im Endeffekt nicht mehr macht als den Bytecode innerhalb der Funktionen zu Encrypten, Decrypten. Also allerhöchsten eine Milde Hürde.

Nativer Code lässt sich auch nicht schützen. Man kann lediglich den Aufwand des Reverse Engineerings erhöhen, was mit Verlaub leichter als bei Bytecode ist.

@MrSmith hab ich ja auch gerade paar post vorher gesagt ;) Am Ende kommt es immer nur darauf an wieviel Aufwand jemand Betreiben will, ist der Anreiz hoch genug kommt man immer an jeden Code der auf dem Rechner läuft, wenn man ihn nun nicht komplett auf nen Server auslagert oder ähnliches. Aber ohne das Enge Korsett des Bytecodes kann man den Aufwand halt doch ehrheblich erhöhen.
Stimm dir wohl auf ganzer Linie zu würd ich sagen :P

Quote:

Originally Posted by MrSm!th Nein, es war kein Witz. Ich mag kein QT, habs nicht zum Laufen bekommen :<

Also damit hatte ich noch nie Probleme, das funktioniert wunderbar, und das ohne dass ich 'nen sonderlichen Aufwand betreiben muss. Der einzige Nachteil sind die u.U. sehr großen Binaries, unter 10 MB kommt man da für gewöhnlich nicht weg.
Dafür kann's halt alles, ich würd dir also empfehlen dass du dir 4.X nochma ansiehst :D (5 kannste wegwerfen, das ist nur noch Blödsinn)

Padmak

Quote:

Nein, es war kein Witz. Ich mag kein QT, habs nicht zum Laufen bekommen :<

gtkmm ist noch extremer bei den Abhängigkeiten und deren Abhängigkeiten und deren Abhängigkeiten.

Quote:

Originally Posted by MrSm!th Nein, es war kein Witz. Ich mag kein QT, habs nicht zum Laufen bekommen :<

-MinGW installieren
-[Only registered and activated users can see links. Click Here To Register...] installieren
-[Only registered and activated users can see links. Click Here To Register...] installieren

Dem QtCreator sagen das er Qt4.8.4 verwenden soll.
(Extras - Einstellungen - "Erstellung und Ausführung" - Qt Version - Hinzufügen)

Also ein riesen Aufwand ist das jetzt auch wieder nicht :P