Frage doch einfach im Nova Forum 
wäre am einfachsten *Augenroll*
Ist doch egal mit was es geschrieben ist, du kannst es sicherlich in fast jeder gängigen Sprache auch schreiben. 
Bei Keybindern bist du sehr gut bedient mit Autohotkey oder Auto IT 
Der sBinder ist mit AHK geschrieben
Man kann den Code "verschlüsseln" und das GUI mit HTML pimpen. Muss aber dazu sagen, dass ich den sBinder nicht kenne und keine Bilder von der Benutzeroberfläche etc. gesehen habe.
Chooper ganz wahrscheinlich nicht, den Quellcode siehst du nicht. Das GUI ist nicht typisch Autohotkey
wenn das der sBinder ist von SAPlayer aus Samp api Forum dann ist der mit AHK geschrieben, kann aber auch sein dass ich mich vertue.
Ich frage aus dem Grund, da ich selber an so nen Keybinder abseits von AHK sitze.
Die Gründe kennen wohl alle...
Also mir sind die Gründe gerade nicht schlüssig...
Du kannst einen Keybinder in so vielen verschiedenen Sprachen coden.
Das kommt eben ganz darauf an, was für einen Einsatzbereich der Keybinder hinterher haben soll, denn grundsätzlich mal nen
Keybinder kann eben in so gut wie jeder Sprache geschrieben werden.
Auch eine Anbindung an SAMP über eine entsprechende API sollte für die meisten Sprachen bereits vorhanden sein (Ansonsten auch kein Hexenwerk sich die selbst zu kompilieren. Die Sources sind ja weitestgehend vorhanden).
Ab dem Punkt musst du dann eben selbst gucken, was der Keybinder noch alles können soll.
Soll er beispielsweise Plattformübergreifend funktionieren dann ist NodeJS mit ElectronJS ne recht komfortable Sache.
Willst du damit tiefer in Prozesse und das System eingreifen, machst du dir das Leben mit C++ recht einfach.
Brauchst du nen GUI Designer und bist net ganz so fit im Programmieren, dann ist vielleicht C# das richtige für dich.
Wie du siehst die Auswahl ist nicht wirklich leicht und das, was ich hier aufgeführt habe ist nur ein winziger Teil. Somit wirst du vielleicht auch einsehen, dass
diese Entscheidung hier keiner für dich abnehemn kann und auch die Empfehlung einer Programmiersprache nicht umbedingt so trivial ist.
Nach deiner Kritik an AHK, aufgrund der Quellcode-Zugänglichkeit und dem GUI-Design ( was wie bereits erwähnt durch das kompilieren zu einer Anwendung und die Verwendung von HTML behoben werden kann )
wirst du wohl eine Programmiersprache verwenden müssen, die den Quellcode direkt in eine Anwendung kompiliert und nicht erst auf dem .NET Framework oder ähnlichem aufsetzt, denn da ist der Quellcode
im Großen und Ganzen genau so einfach erreichbar, wie bei einer kompilierten AHK Datei. Allerdings sollte dir auch hierbei bewusst sein, dass jemand mit Ahnung, der an deinen Quellcode kommen möchte auch dran kommt.
Der Quellcode ist dann zwar vielleicht nicht so einfach per copy n paste verwertbar, aber dennoch per reverse-engineering nachvollziehbar.
Die Gründe sind doch schlüssig.
Den Quellcode kann man bei AHK sehen,
Das Problem wirst du mit jeder Sprache haben, die nicht direkt in Assembler kompiliert. Und selbst dann kann man eben auch den noch für Schabernack benutzen.
Was spricht denn dagegen an deinen Code zu kommen? Open Source ist dir sicherlich ein Begriff und da klappt das ja ganz gut.
Selbst C++ lässt sich dekompilieren. Zwar ist der Code dann alles andere als das, was du ehemals kompiliert hast, letztlich geht das aber. Der Compiler führt bei diversen Hochsprachen massivst Änderungen am Code aus um ihn zu optimieren. Ich glaube aber, du hast nichts in deinem Code, dass es so zu schützen gilt. Keinen super Algorithmus, den man nicht binnen kürzester Zeit nachprogrammieren kann. Deshalb verstehe ich den Aufwand nicht?
Nehm eine beliebige Sprache mit der du klar kommst oder in die du dich einarbeiten möchtest und leg einfach los.
Die Gründe sind doch schlüssig.
Den Quellcode kann man bei AHK sehen, das Gui ist nicht prickelnd, sowie alle Buttons.
Ich suche eine Sprache, die ihr mir abseits von AHK empfehlen könntet.
Dazu habe ich mich stark an den sBinder orientiert.
Nagut, das war von mir vielleicht etwas ungünstig formuliert und zitiert.
Eigentlich wollte ich wissen, warum dich es so interessiert in welcher Sprache der geschrieben ist?
C#, C++, Delphi, Visual Basic, etc. pp.
Da gibt es so viele Möglichkeiten. Je nach aktuellen Kenntnisstand musst du abwägen, was du nutzen solltest.
Was spricht denn dagegen an deinen Code zu kommen? Open Source ist dir sicherlich ein Begriff und da klappt das ja ganz gut.
Selbst C++ lässt sich dekompilieren. Zwar ist der Code dann alles andere als das, was du ehemals kompiliert hast, letztlich geht das aber. Der Compiler führt bei diversen Hochsprachen massivst Änderungen am Code aus um ihn zu optimieren. Ich glaube aber, du hast nichts in deinem Code, dass es so zu schützen gilt. Keinen super Algorithmus, den man nicht binnen kürzester Zeit nachprogrammieren kann. Deshalb verstehe ich den Aufwand nicht?
Nehm eine beliebige Sprache mit der du klar kommst oder in die du dich einarbeiten möchtest und leg einfach los.
Naja ich habe eine Einloggmethode geplant, doch wenn man an den Quellcode kommt, kann man viel böses anrichten.
Naja ich habe eine Einloggmethode geplant, doch wenn man an den Quellcode kommt, kann man viel böses anrichten.
Wie willst du die denn Aufbauen? Willst du deine MySQL Zugangsdaten (or whatever) im Quellcode des KB hinterlegen? Wenn ja, ganz böse! Dafür gibt es sicherere Wege --> Thema APIs, dann wäre es auch egal ob jemand den Code lesen könnte.
Naja ich habe eine Einloggmethode geplant, doch wenn man an den Quellcode kommt, kann man viel böses anrichten.
Wenn du wirklich kritische Informationen oder Funktionen in deiner Anwendung hast, dann würde ich dir empfehlen das Thema API, wie bereits von @Developer erwähnt
nicht bezüglich des Logins angucken, denn egal wie du eine Authentifikation in einer Anwendung aufbaust, irgendeinen Weg gibt es immer diese auszutricksen. Auch eine API wird dir
dabei nicht 100% Sicherheit gewähren, denn auch da können zumindest die Anfragen der Anwendung abgefangen und ggf. manipuliert werden. Wenn du allerdings die Infos gesichert über
die API abholst und kritische Funktionen über diese ausführen lässt, sieht die Sache wieder gleich ganz anders aus.
