THEMA:

Halli Hallo,

ich habe mich vor ein paar Monaten hier registriert, aber noch keine Gelegenheit gehabt, mich mit CX5 zu beschäftigen. Dank vieler anderer Sprachen habe ich das ganze damals aus den Augen verloren. cX Habe ich bei Pearl für 90 Cent im Angebot gekauft gehabt (war glaub ich 2003 oder 2004). Davor hatte ich versucht, das programmieren über verschiedene Bücher zu lernen. Aber habe es nie wirklich verstanden. ClickEXE hat geschafft, woran die Autoren der Bücher von Pascal über C bis hin zu Visual Basic gescheitert sind. Aber dann zog ich weiter und verlor das ganze aus dem Blickfeld. Es hatte mir damals zu wenig Möglichkeiten. Aber wenn ich mir cX 5 ansehe und wie nervig es ist, mittlerweile mit anderen Sprachen und Toolsets zu arbeiten, juckt es echt in den Fingern, mir cX 5 zu holen und meine Tools ganz entspannt hiermit zu bauen.

Aber eine Kleinigkeit irritiert mich. Es lassen sich externe Funktionen aus VBScript (Windows Script Host), JavaScript und cX-Skripts ansprechen/aufrufen. Handelt es sich bei JavaScript denn um Skripts mit Anbindung an den Script Host, steht einem ein JavaScript mit einer Browserengine zur Verfügung oder handelt es sich dabei um ürde interessieren, wie weit ich mit diesen Sprachen gehen könnte. Denn Javascript dürfte mir die Arbeit mit JSON schon erheblich erleichtern. Aber wenn ich darüber nur Parsen bzw. Serialisieren kann, aber dann schon die Grenze erreicht ist, wäre das dann doch für mich etwas nutzlos.

Und die letzte Sache. In der Doku steht, das ich über Externe Funktionen auch Funktionen aus anderen cX-Scripts ansprechen kann. Diese Skripts werden dann beim erstellen der Executable mit in selbige übernommen, wenn ich das entsprechend konfiguriere. Das dürfte mein gängiger Weg werden, um komplexere Anwendungen über mehrere Dateien zu verteilen und die Übersicht zu behalten. Diese Skripts werden beim kompilieren ebenfalls kompiliert oder werden diese einfach nur zur Laufzeit interpretiert? Das geht aus der Doku nicht so ganz hervor. Das dürfte durchaus einen Unterschied bei der Performance machen.

Ich muss echt schon sagen. Wenn man in die Details von cX schaut, offenbart sich da echt schon ein Leistungsstarkes Monster. Bin echt platt, was damit alles geht. Ich fand das damals schon echt cool, aber eben auch Schade, das man da so schnell die Grenzen erreicht hat. Aber heute mit der 5er? Echt stark. Ich bin echt gespannt, wann ich die Grenze der 5er erreiche.

Hey und Herzlich Willkommen, Troax!

es freut mich sehr, dass du so großes Interesse und auch Begeisterung für cX5 zeigst. Ich selbst gehöre auch zu denjenigen Menschen, die cX2001 seinerzeit von Pearl bezogen haben - und das war wahrlich kein Fehlkauf. Natürlich hat sich, wie du richtig erfasst hast, in dieser Zeit einiges getan.

Zunächst einmal muss ich allerdings das Thema der Autoren aufgreifen. Einer dieser Autoren hat viele Bücher über Visual Basic und vergleichbare Sprachen geschrieben - und verwendete sein Wissen, um zunächst mit Visual Basic cX zu erschaffen Also konnte er dich zumindest mit cX für das Programmieren begeistern.


Dein "Jucken" kann ich verstehen. cX5 ist ein echt mächtiges Werkzeug geworden, das an verschiedenen stellen wirklich bis ins letzte Detail mitdenkt und selbst komplexeste Anwendungen hervorbringen kann. Auch Anfänger sollten schnell Erfolge erzielen können. Durch viele Funktionen, die komplexe Abläufe mal eben mit einer Variable oder Checkbox realisieren, kann man dazu noch in nie dagewesener Geschwindigkeit Programme entstehen lassen - als wäre Magie im Spiel.

Ich selbst arbeite sehr viel mit XML und JSON, was nativ über den "Einstellungen" Befehl ausgewertet, erzeugt und verändert werden kann. Dazu ergänzen Var und Stapel Platzhalter mit ihren JSON oder XML Ausgabeformaten das noch praktisch.

Du kannst sowohl VB- wie auch JavaScript nativ ausführen und dabei über Variablen mit dem cX-Skript interagieren. Für JSON sollte das wie erwähnt jedoch nicht notwendig sein.

Richtig erfasst hast du auch, dass man cX5 Skripte auf mehrere Dateien verteilen kann. Das tue ich auch oft, um die Übersichtlichkeit zu wahren. Im Externe-Funktion Befehl kannst du die ausgelagerten Teile dann auch so einbinden, dass beim Erstellen der EXE eine einzige Datei entsteht. Die Performance ist in beiden Fällen gleich gut.

Zu guter letzt sei noch erwähnt, dass die cX5-Runtime auch nativ kompatibel zum Microsoft IIS ist. Darüber kann man mit cX5 auch Webservices herstellen, die durch die Performanz des IIS anderen Sprachen wie PHP absolut nicht nachstehen.


Wenn du Fragen haben solltest, stell' sie gern - dir wird hier in der Gemeinde sicherlich bestens geholfen. Auch wenn du Inspirationen oder Konzepte suchst, wird man dir sicher den passenden Denkanstoss geben können.

Viele liebe Grüße Dennis

Vielen Dank für die Rückmeldung.

Ich habe nach cX mich den etablierteren Sprachen gewidmet. Und das war damals zu beginn auch gut und wichtig. Von PHP über C#, VBNet, Java, diverser kleinerer Basic-Dialekte (PureBasic, FreeBasic, B4X) oder auch moderneren Designerdrogen wie Python, Go, Dart ...

Und mich störte immer mehr, das gefühlt nicht mehr zu Grunde liegende Probleme gelöst werden, sondern eher Probleme der Effizienz und Komfort bei der Programmierung gelöst worden sind. Für mich hat aber der ganze Kram nichts mit Komfort zu tun. Für Hobbycoder wie mich wurde das immer unerträglicher und bin im Grunde komplett bei den Basic-Dialekten hängen geblieben. Vor allem PureBasic findet noch gelegentliche Anwendung. Aber da fehlt mir zu viel. Paketmanager sind für mich zur Seuche geworden. Für einen spezifischen Einsatzzweck gibt es hunderte Pakete, die alle das Problem anders angehen. Durchsetzen tun sich aber meist nur die umfangreichsten Lösungen. Das mündet darin, das man immer für kleinste Probleme die umfangreichsten Bibliotheken nutzt. Man repariert doch kein Quarzuhrwerk mit Vorschlaghammer.

Aber das spielt für mich alles keine Rolle mehr. Den Stress gebe ich mir nicht mehr.

Zum Thema Javascript. Vordergründig interessiert mich da eher, was für Funktionalitäten der Interpreter außerhalb von cX anbietet. Ich denke mit JSON arbeiten sollte damit kein Thema sein. Ich habe aber noch irgendwo einen Markdown-Parser auf der Platte liegen, der pur in Javascript geschrieben ist (und ohne NodeJS). Nun ist mir nicht so ganz klar, ob Javascript auf die eigenen (nicht cX) Regex-Funktionalitäten zugreifen kann, oder ob ich den Code stark anpassen muss. Nur dann kann ich das auch direkt in cX neu schreiben. Daher die Frage nach der Anbindung. Der Windows Script Host kann meines Wissens nach nicht die Regex-Funktionen nutzen (zumindest nicht die, die im Browser zur Verfügung gestellt werden). Ich denke mal dafür bedarf es einer Browser-Runtime. Nur wenn ich wirklich cX5 fürs Web einsetze ist das für mich schon wichtig. Ich kann über cX problematische HTML-Elemente escapen. Top. Damit kann ich Sicherheitsrelevante HTML-Elemente unscharf machen. Ich muss aber auch noch die Möglichkeit geben können, längere Texte semantisch formatieren zu lassen. Und da ist meiner Meinung nach Markdown einfach absolut unschlagbar.

Was das Thema Server angeht. MS IIS ist für mich tatsächlich in keinster Weise interessant. Webserver auf Windows-Basis sind für kleine private Projekte weder ökonomisch noch ökologisch vertretbar. Eine Serverlizenz ist einfach teuer, das Betriebsystem schluckt erhebliche Ressourcen, ohne das es wirklich etwas sinnvolles tut. Dadurch verbraucht der Server unnötig Energie. Fühle ich nicht so. Aber es ist in der Doku ja die Rede von FastCGI und das sich cX und dessen Programme auch hervorragend unter Linux mit Hilfe des Mono-Frameworks einsetzen lässt. Und wenn ich die Maschine mit dem Webserver komplett auslasten will, kann ich das cX-Programm mehrfach mit unterschiedlichen Ports ausführen und dann mit Hilfe des Loadbalancers des Webservers (NGINX, Lighttpd, Apache etc.) füttern lassen. Damit lassen sich dann auch easy Multicore-CPU's komplett auslasten.

Gestern habe ich auch in der Doku gelesen, das cX sogar als Template-Engine agieren kann. Aber für mich sind da noch 2 Probleme, die ich lösen muss. Wenn ich Services nach dem REST-Prinzip erstellen will, benötige ich JWT, um kompatibel zu externen Frameworks zu sein. Dafür benötige ich HMAC, um Payloads validieren zu können. Base64 ist ja dabei. Aber zu HMAC habe ich noch nichts in der Doku zu gefunden. Und das zweite Problem liegt im Hashen der Passwörter. MD5 sowie die SHA-Varianten sind da keine Option. Minimum ist PBKDF2 auf SHA3 Basis. Besser wären Blowfisch oder Argon2. Da lag ebenfalls meine Hoffnung auf Javascript. Aber ich denke das muss ich dann mal einfach testen, wenn ich Zeit habe. Diese Woche ist da nicht so dolle. Urlaubszeit bedeutet für mich meist blöd gelegene Schichten  

Es sind noch sehr viele generelle Fragen für mich offen. Ich wurschtel mich momentan noch durch die Doku und muss noch einiges testen, bevor ich mir eine Lizenz hole. Aber es gibt ja zum Glück den Testmodus. Über die nächste Zeit werden sich denke ich die Fragen beantworten. Zur Not schaue ich, wie ich mir das selber integriere. 

Viele Grüße ... auch Dennis

PS: Kann es sein, das hier ein ekelhafter regulärer Ausdruck alles rausfiltert, wo zwei Worte bzw. Zeichenkombinationen durch einen Punkt getrennt werden? Das hat mir schon meinen ersten Beitrag erheblich zerrissen. Node(dot)JS ist eigentlich eine gängige Schreibweise mit Punkt. Oder VB(dot)NET. Das hat mich im ersten Beitrag echt wahnsinnig gemacht.

Ich mag Doppelposts zwar nicht. Aber ich mag es auch nicht, für jedes Thema einen neuen Thread aufzumachen, da sich der folgende Text auf die zu Grunde liegenden Fragen meinerseits bezieht.

1. Javascript
cX bietet zwar die Option, Javascript Code auszuführen. Allerdings scheint es nur zusammen mit dem Assembly Interop(dot)MSScriptControl(dot)dll zu funktionieren, wie es in der Doku beschrieben steht.

Getriggert mit folgender Zeile. Aber auch mit weiteren Codes aus externen JS-Files getestet:
Dieses Assembly ist allerdings nur schwer auszumachen. Wenn man direkt danach sucht, bekommt man nur Hinweise auf alte Versionen bis 2013. In den aktuellen .NET SDK's ist diese Datei auch nicht enthalten. Es gibt Seitens Microsoft kaum Infos zu der Datei und einzeln laden kann ich sie nur von irgendwelchen Seiten, die ich in keinster Weise vertrauen möchte. Ich vermute mal, das MS die Interop-Funktionalität mittlerweile anders gelöst hat und deswegen diese Datei einfach nicht mehr existiert. Und in der Doku steht eh, das es nur unter Windows funktioniert. Ich bräuchte es aber auf einem Linux-Server. Also fällt die Möglichkeit raus.

2. Bcrypt oder PBKDF2 per OLE-Befehl
In der Testumgebung habe ich es geschafft, ein externes Assembly so einzubinden, das ich keine Fehlermeldung bekommen. Dazu habe ich die BCrypt.NET-Next Assembly aus NuGet geladen. Aber anscheinend bekomme ich die Methode nicht aufgerufen, mit der ich einen String zu einem datenbankfähigem BCrypt-Hash umwandeln kann. Ich vermute mal, das es daran liegt, das die Methode statisch ist. Da würde mich einmal interessieren, ob es in zukünftigen Versionen möglich ist, eine Fehlermeldung auszugeben, wenn etwas nicht funktioniert. Ich bin mir sicher, das eine spezifische Fehlermeldung zum Problem nur schwer bei kompilierten Assemblies zu erzeugen ist. Ich kann mir aber nicht vorstellen, das eine Funktionen in einem Assembly einfach nichts tut und cX das nicht merkt. Ein einfaches "geht so nicht, Dude" reicht mir völlig. Aber das Ding sagt und macht halt einfach nichts.
PBKDF2 hingegen ist in System(dot)Security(dot)cryptography direkt im Framework enthalten. Allerdings scheint dieses über cX garnicht funktionieren zu wollen. Ich erhalte dabei folgenden Fehler:

Ich hatte die Methode erst einmal ohne Parameter aufgerufen um zu schauen, ob ich da etwas gemeldet bekomme, mit dem man etwas anfangen kann. Aber hier scheint es schon bei Instanzierung ein Problem zu geben. Folgend getriggert:
Worauf muss man denn bei den Assemblies achten? Wie müssen die Klassen aussehen? Die Dokumentation wirft da nicht viel aus. :/

Fazit
Da ich diese Erweiterungen nur für den Fall gebraucht hätte, cX auf einem Webserver zu nutzen, fällt dieser Einsatz mit cX für mich erstmal raus. Bin ich aber auch mittlerweile nicht wirklich traurig drum. Wenn man mal darüber nachdenkt, hat PHP einfach einen unschlagbaren Vorteil. Es läuft nahezu auf jeden Webspace und Webspace kostet nen Witz. Für cX hätte ich einen vServer bzw. dedicated Server gebraucht.
Und mit dem FatFreeFramework ist mit PHP z.B. ein Webdienst schnell gemacht. Das hat BCrypt und Markdown direkt mit integriert. Komm Schwamm drüber. Ich denke zum bauen von Desktop-Programmen und Konsolen-Tools eignet sich cX deutlich besser. Dafür wird es vermutlich von den allermeisten genutzt. Und da habe ich bei meinen Tests festgestellt, das da durchaus deutlich mehr potenzial existiert. Für das Web serverseitig ist für mich KeyDerivation (PBKDF2/BCrypt/Argon2) für Passwörter unerlässlich, JWT für Webservices mittlerweile Standard und Markdown für usergenerierten Content unerlässlich. Wenn ich eine Webseite zur Verfügung stelle, dann mache ich das Design und lass es mir nicht mit HTML oder BBCode versauen
Aber wenn es mehr Infos zu dem Thema Assemblies über OLE einbinden und Javascript über Externe Funkion geben würde, wäre ich trotzdem extrem dankbar. Denn uninteressant ist das nicht. Vielleicht kann man da auch etwas Wrappen, wenn es nicht direkt lauffähig ist.