Eure Anregungen für das DEC 5.3 gebraucht

[alphaflight83]

Letztes Lebenszeichen war ein kurzer Kommentar in Arvids letztem Blog-Eintrag am 08. März 2013:
"I am going to post about the changes to my blog, the DEC and so on in a few weeks. Stay tuned! Had been a busy time."
Ich bin ebenfalls bei der Portierung eines Projekts nach XE4 wieder einmal darauf gestoßen.

[Codehunter]

Ich bin da eher skeptisch. Unicode, 64 Bit, das alles dürfte dem bisherigen 5.3er Code ziemliche Schwierigkeiten machen. Schade eigentlich, da DEC immernoch eine Referenz in Sachen Kryptografie bei Delphi ist.

Es gibt leider nicht viele Leute, die die notwendige Kompetenz dafür haben, das DEC für moderne Delphis anzupassen.

Was sagt eigentlich Hagen zu dem Thema?

[cookie22]

Zitat:

Zitat von Codehunter (Beitrag 1228401)

Schade eigentlich, da DEC immernoch eine Referenz in Sachen Kryptografie bei Delphi ist.

Die Implemetierungen von Gammatester hier aus dem Forum sind ein wirklich adäquater Ersatz für das DEC. Das Ganze wird auch regelmässig gepflegt. http://wolfgang-ehrhardt.de/crypt_de.html

[Zacherl]

Zitat:

Zitat von Codehunter (Beitrag 1228401)

Ich bin da eher skeptisch. Unicode, 64 Bit, das alles dürfte dem bisherigen 5.3er Code ziemliche Schwierigkeiten machen. Schade eigentlich, da DEC immernoch eine Referenz in Sachen Kryptografie bei Delphi ist.

Mit Unicode hat DEC 5.3 doch schon zum Großteil funktioniert. Und 32 Bit dürfte den meisten Users vermutlich auch erstmal reichen.

Zitat:

Zitat von cookie22 (Beitrag 1228403)

Die Implemetierungen von Gammatester hier aus dem Forum sind ein wirklich adäquater Ersatz für das DEC.

Werde ich mir mal anschauen, wobei ich immer noch auf ein Update vom DEC hoffe. Weniger wegen des Umstellungsaufwands, sondern eher, weil ich mit dem Umgang vom DEC vertraut bin und ich da schon aus eigener Erfahrung sagen kann, dass alles zu 100% korrekt implementiert ist.

[Codehunter]

Zitat:

Zitat von Zacherl (Beitrag 1228428)

32 Bit dürfte den meisten Users vermutlich auch erstmal reichen.

Ist eben nicht mehr State of the Art. Wenn ich sehe dass wir neue Projekte grundsätzlich in 64 Bit und nur nachrangig als 32 Bit bauen, manche sogar NUR in 64 Bit. Es ist ja auch nicht nur die Frage, ob DEC mit Unicode und 64 Bit läuft. Es geht ja vorallem auch darum, ob man sich damit neue Sicherheitslücken rein reißt. Da muss jemand ran der den Code wirklich durchschaut. Simples Variablentypentauschen bringt da keine Pluspunkte.

[TurboMagic]

Hallo,

ich wüsste auch mal gerne den aktuellen Stand, da ich für ein mobiles Projekt eine Pure Pascal
Umsetzung gut gebrauchen könnte. Hatte sogar angefangen die 5.2 dahin zu überarbeiten, bin
aber noch nicht weit, da ich nur wenig ASM kann.

Es war ja die Rede davon, dass einige Arbeiten schon gemacht wurden, nur meint Assertor, es sei
noch nicht veröffentlichbar. Da er die DEC 5.2 ja auf GitHub hat, könnte er diese Arbeiten doch
einfach in einem Branch veröffentlichen der klar als experimentell gekennzeichnet ist und wir
könnten evtl. bei den noch ausstehenden Arbeiten etwas helfen.

Ich könnte mir z.B. vorstellen vorhandene Kommentare in XMLDOC umzuformatieren, womit man in
der IDE mehr von den Kommentaren hätte.

Ich würde derzeit auch kein wirkliches Augenmerk auf das Thema Performance legen. Wenn die
Bibliothek wieder in einem wirklich veröffentlichbaren Zustand ist, kann man das dann Schritt
für Schritt angehen.

Gruß

TurboMagic

[Delphi-Laie]

Zitat:

Zitat von TurboMagic (Beitrag 1331626)

Hallo,

ich wüsste auch mal gerne den aktuellen Stand

Das Projekt DEC 5.3 wurde vor etlichen Jahren angekündigt, tot soll es nicht sein, doch es tut sich hartnäckig nichts, jedenfalls nichts nach außen erkennbares. Bezeichnen wir das als Dauerschlaf mit ungwissem Erwachen. Schade.

[Codehunter]

Schade dass Hagen nicht mehr dran beteiligt ist. Dann hätt ich mal kurz bei ihm vorbei fahren können...

[Delphi-Laie]

Zitat:

Zitat von Codehunter (Beitrag 1331713)

Schade dass Hagen nicht mehr dran beteiligt ist. Dann hätt ich mal kurz bei ihm vorbei fahren können...

Wenn ihr Euch schon persönlich kennt, kannst Du das doch trotzdem tun. Irgendetwas zu diesem Projekt, auch zu seinem jetzigen Zustand, wird er doch wohl aussagen können. Und egal was, es scheint doch einige Leute arg zu interessieren.

[Codehunter]

Zitat:

Zitat von Delphi-Laie (Beitrag 1331716)

Wenn ihr Euch schon persönlich kennt, kannst Du das doch trotzdem tun. Irgendetwas zu diesem Projekt, auch zu seinem jetzigen Zustand, wird er doch wohl aussagen können. Und egal was, es scheint doch einige Leute arg zu interessieren.

Persönlich kennen ist reichlich übertrieben. Ich weiß dass er keine 50 km von mir entfernt wohnt(e). Allerdings meine ich dass seine Begründung für die Einstellung vom DEC damals war dass er die Branche gewechselt hat und keine Software mehr entwickelt.

Die Frage ist auch, ob es DEC wirklich noch braucht. Das Windows Crypto API könnte durchaus eine Alternative sein. Wenn man bereit ist, einer Closed Source Crypto zu vertrauen.

[TurboMagic]

Naja, WindowsCrypto ist auf anderen Plattformen wohl unnütz. Daher braucht's DEC schon noch. Mal sehen, ob das nicht wieder zum leben zu erwecken ist. Wenn's aber weitere freiwillige zur Mitarbeit gäbe wär's sicher einfacher. Die können sich ja einfach in diesem Thread outen. Ziel sollte es sein, eine DEC Version zu erstellen, die auf allen Plattformen nutzbar ist.

[Zacherl]

Zitat:

Zitat von TurboMagic (Beitrag 1331824)

Naja, WindowsCrypto ist auf anderen Plattformen wohl unnütz. Daher braucht's DEC schon noch. Mal sehen, ob das nicht wieder zum leben zu erwecken ist. Wenn's aber weitere freiwillige zur Mitarbeit gäbe wär's sicher einfacher. Die können sich ja einfach in diesem Thread outen. Ziel sollte es sein, eine DEC Version zu erstellen, die auf allen Plattformen nutzbar ist.

Fand DEC auch immer gut. Was Plattformunabhängigkeit angeht, gab es damit aber auch immer Probleme, wegen des verwendeten inline Assemblys.

[Delphi-Laie]

Also, "gewisse" Programmierunternehmen Nordamerikas sind die allerletzten, denen bzw. deren Produkten ich vertraue bzw. vertrauen würde.

Nur zur Konkretisierung: Objektpascal und dessen Hersteller gehören nicht dazu....

[Zacherl]

Zitat:

Zitat von Delphi-Laie (Beitrag 1331829)

Also, "gewisse" Programmierunternehmen Nordamerikas sind die allerletzten, denen bzw. deren Produkten ich vertraue bzw. vertrauen würde.

Prinzipiell stimme ich dir da bei Sicherheits-kritischen Komponenten auf jeden Fall zu (OpenSource Libs. sind hierbei erste Wahl). Aber in der heutigen Zeit kannst du davon ausgehen, dass auch die Windows Crypto-APIs von diversen Leuten reversed und ge-audited wurden. Die Wahrscheinlichkeit, dass dort extra Schwächen oder Hintertüren (wie der berühmte Win95 NSA Backdoor Key) eingebaut wurden, die noch nicht gefunden worden sind, ist denke ich relativ gering.

[BUG]

Oder anders herum: Wenn du Microsoft so wenig vertraust, dass du nicht die Crypto-API benutzen willst, dann solltest du vermutlich auch insgesamt kein Windows verwenden :wink: :mrgreen:

[Capstone]

kein Windows und keinen Compiler nach 1994 ... oder wie war das mit TrueCrypt ? ...
die hatten diesen alten Compiler angeblich verwendet, da neuere im Verdacht stünden, Code intelligent auf kryptographische Algorithmen und Fragmente zu untersuchen und diese bei der Compilierung durch schwache Algorithmen in der EXE zu ersetzen.

unmöööglich? unglaubwürdig?

naja .. selbstgewurschtelt implmentiertes zu entdecken und als Krypto-Code/Algo zu identifizieren mag schwieriger werden, als solches zu erkennen. Verwendete, bekannte Libs mit überall identischen Codezeilen zu entdecken und abzuschalten/ zu ersetzen dürfte für einen Compiler ein Leichtes sein.
und seien es nur BigInteger Libs oder spezielle Funktionen/ Kombinationen von Funktionen*/Anweisungen in unmittelbarer Nähe. :D
(Modulo, Power, PowMod, etc.)

Wer untersucht/reversed denn schon Compiler, seine Libs und DLLs ... und das bei jedem SP/Update ... und jedes Byte ..

achja ...

[Luckie]

Bitte findet wieder zurück zum Thema!

[Codehunter]

Ich habe zur Offtopic-Diskussion einen eigenen Thread im Klatsch-Forum aufgemacht.

[TurboMagic]

Hallo,

1. Die Forumssoftware zeigt mit in der Hybrid Darstellung für diese Diskussion nur die Beiträge bis ca. 2011 an. Komisch.
2. Ja zurück zum Thema fände ich auch gut. Es wurde zwar schnell über Sinn und Unsinn des MS Crypto API diskutiert, aber
keiner hat darüber diskutiert, ob DEC durch mitmachen weiterer Personen evtl. wieder aus dem Dämmerschlaf zu erwecken
wäre.

Grüße

TurboMagic

[Codehunter]

Zitat:

Zitat von TurboMagic (Beitrag 1331995)

aber keiner hat darüber diskutiert, ob DEC durch mitmachen weiterer Personen evtl. wieder aus dem Dämmerschlaf zu erwecken wäre.

Genau das ist der eigentliche Kern der neueren Diskussion. Assertor scheint zumindest momentan nicht auf Benachrichtigungen zu reagieren. Andernfalls hätte er sich sicher schon dazu geäußert. Ich kenne das Problem noch aus DelphiWorks-Zeiten: Wenn man so eine OpenSource-Lib pflegt, dann hat man es immer mit sehr vielen Wünschen und sehr wenig Mitarbeit zu tun. Irgendwann stellt man sich die Frage, ob man das Projekt nur für sich selbst pflegen oder in einem öffentlichen CVS zu betreuen.

Man müsste als erstes ein Code Review machen, dann eine Todo-Liste aufstellen, es müssten sich Leute finden die daran mitwirken wollen und qualifiziert sind, und natürlich müsste Assertor auch neue Mitstreiter haben wollen. Oder man müsste einen Fork bauen, was aber nur suboptimal wäre.

[TurboMagic]

Hallo,

was wäre, wenn manche der Dinge schon in Arbeit wären und es einfach noch helfen würde wenn weitere Personen mitarbeiten würden?

Grüße

TurboMagic

[Codehunter]

Dann wäre das hier genau der richtige Platz um darüber zu sprechen, nicht wahr? :-) Denn augenscheinlich liegt das Projekt in einem Tiefschlaf. Wenn der Schein trügt sollten die Beteiligten das doch einfach sagen.

[gammatester]

Ihr solltet Euch im Klaren sein, was das eigentlich für eine Arbeit sein wird. Wenn man nicht ein wenig konkret wird, ist das kaum abzuschätzen.

Für mich wäre DEC wieder interessant, wenn

• PurePascal benutzt wird; möglichst wenig neuer Spach/Compiler-Schnick-Schnack, das fördert die Kompatibilität.
  
• Standard-Modi für Blockchiffren (CTR, GCM, CCM, EAX) und die berüchtigten eigenen entfernen oder zu mindest nicht mehr fördern (außerhalb der Delphi-Fan-Gemeinde benutzt die eh keiner).
• Neue bewährte und standardisierte Algorithmen implementieren: Chiffren (Salsa, ChaCha, Camellia); Hash (SHA-2, SHA-3); Password-Hashing (BCrypt, Scrypt, Argon2)

Und das wären ja erst die Bausteine, welche High-Level Protokolle kommen dazu, etc.

Ich kann mir ehrlich nicht vostellen, daß jemand das heute alles im Sinne der alten DEC-Philosophie frei (kostenlos) zur Verfügung stellt und wartet, d.h eine umfangreiche, aktuelle, integrierte Pascal-Bibliotek wird's wohl leider noch nur kommerziel geben (zB http://www.streamsec.com/ oder https://www.eldos.com/sbb/)

Gruß Gammatester

[Jens01]

Man kann sich auch mal diese Krypto-Seite angucken. Der Einstieg kostet aber auch etwas Zeit.:thumb:

[Delphi-Laie]

Zitat:

Zitat von Codehunter (Beitrag 1332041)

Dann wäre das hier genau der richtige Platz um darüber zu sprechen, nicht wahr? :-) Denn augenscheinlich liegt das Projekt in einem Tiefschlaf. Wenn der Schein trügt sollten die Beteiligten das doch einfach sagen.

Passiert nicht.

Machen wir uns nichts vor: Dieses hervorragende Projekt hat seine besten Zeiten hinter sich. Wahrscheinlich wird es aus seinem 5.2-Stadium leider nie mehr herauskommen.

[TurboMagic]

Das Problem mit dem Outen ist, dass die Wünsche der Anwender vielfältig sind und die Ressourcen der Maintainer begrenzt. Es würden dann ganz schnell mehr Leute hier neue Wünsche äußern als sich neue Maintainer melden würden.

Aus meiner Sicht müsste ein neues Release auf folgendes Wert legen:

1. Für alle Teile PurePascal Versionen bereit stellen.
2. Soweit wie möglich aufrufkompatibel zu DEC 5.2 sein
3. Keine Datentypen verwenden die auf mobilen Compilern nicht verfügbar sind und wenn,
dann so mittels $IFNDEF NEXTGEN ausgeklammert, dass die mobilen Compiler das nicht compilieren versuchen
4. Die Struktur evtl. intern so umbauen, dass es wartungsfreundlicher wird
5. Alles besser dokumentieren und zumindest grob mit Unit-Tests absichern

=> das ist eine größere Aufgabe, neue Crypto-Algorithmen wären da erstmal nur im Weg. Ist diese
Aufgabe gelöst kann man sich auch übner neuere Algorithmen Gedanken machen. Aber erst dann.

Eine neue Version könnte ruhig auch die Unterstützung für ältere Compiler < D2009 einstellen.
Neuere Sprachfeatures sollten nur mit Bedacht eingesetzt werden, eben da wo wirklich sinnvoll.

So, würden sich für so etwas weitere Maintainer finden lassen?

Grüße

TurboMagic

[Codehunter]

Man sollte vorallem auch Prioritäten setzen. Zum Beispiel solche Teile nach hinten schieben, die bisher im DEC nur in Software realisiert waren und inzwischen gegen hardwarebeschleunigte Varianten keine Chance in Sachen Performance mehr haben. Hardwarebeschleunigung wäre zwar schön zu haben, aber eben auch schwer zu implementieren. In Bezug auf Plattformunabhängigkeit sowieso.

Ich bin nicht sicher, warum damals beim DEC auf Assembler gesetzt wurde. Ich vermute aber mal, es ging ebenfalls um Performancevorteile. Da stellt sich ja ohnehin inzwischen die Sinnfrage. Sprich: Wie viel schneller läuft Assemblercode heute noch im Vergleich zu PurePascal auf modernen Prozessoren? Wie viel Wartbarkeit und Portierbarkeit verliert man durch Assembler? Und am Ende muss man Vor- und Nachteile eben abwägen.

[Zacherl]

Zitat:

Zitat von Codehunter (Beitrag 1332147)

Ich bin nicht sicher, warum damals beim DEC auf Assembler gesetzt wurde. Ich vermute aber mal, es ging ebenfalls um Performancevorteile.

Genau, Performance spielt eine große Rolle bei Crpyto Anwendungen. Sowohl im Sinne der Geschwindigkeit, als auch im Bezug auf sparsame Nutzung von Resourcen.

Zitat:

Zitat von Codehunter (Beitrag 1332147)

Wie viel schneller läuft Assemblercode heute noch im Vergleich zu PurePascal auf modernen Prozessoren?

Das kann man pauschal nicht sagen. Der Delphi Compiler optimiert allerdings derart schlecht, dass man eigentlich gar nicht von Optimierung sprechen kann (im Vergleich zu modernen C/C++ Compilern). Oft sieht man auch total unsinnige Konstrukte, wie

Code:

xor eax, eax

direkt gefolgt von einer Zuweisung wie beispielsweise

Code:

mov eax, [ebx]

Warum zum Teufel wird hier vorher das Register nochmal genullt, obwohl es eine Instruction später sowieso komplett überschrieben wird?

Für "normale" GUI oder Service Anwendungen ist dieser unnötige und schlecht optimierte Code sicherlich nicht relevant, aber wenn es um Algorithmen geht, welche im Zweifelsfalle auch mal eine riesige Anzahl von Iterationen beinhalten, kann man mit Assembler definitiv eine Menge optimieren. Wenn der Code dann noch intelligent, abhängig von den CPU Features, moderne Instruction Sets, wie AVX oder AESNI verwendet, kann das schon einen erheblichen Unterschied machen.

Zitat:

Zitat von Codehunter (Beitrag 1332147)

Wie viel Wartbarkeit und Portierbarkeit verliert man durch Assembler? Und am Ende muss man Vor- und Nachteile eben abwägen.

Wartbarkeit ist meiner Meinung nach hier kein großes Problem, da die Crypto Algorithmen sich nicht mehr ändern, nachdem sie einmal standartisiert wurden. Portierbarkeit ist sicherlich ein Argument gegen inline Assembly, wobei es hier eher eine Frage des initial zu leistenden Arbeitsaufwands ist. Ich würde erstmal komplett alles in PurePascal implementieren und später, wo nötig, per IFDEFs entsprechende Assembler Optimierungen für x86 und x86-64 nachrüsten.

[Codehunter]

Zitat:

Zitat von Zacherl (Beitrag 1332187)

und später, wo nötig, per IFDEFs entsprechende Assembler Optimierungen für x86 und x86-64 nachrüsten.

Wie sieht das eigentlich mit dem MacOS-Compiler aus? Ist der genauso bescheiden? Was ist dort mit ASM?

Bei den Mobil-Compilern braucht man ja über Performance eh nicht nachdenken. Erst Pascal in Java Bytecode umwandeln und diesen dann in einer Java-VM laufen lassen, da kommt es auf ein paar PurePascal-Routinen mehr auch nicht mehr an.

Auch wenn Windows und x86(-64) der Hauptzielmarkt von Delphi sind, sollte man die anderen Plattformen nicht gänzlich ausblenden und zumindest mal drüber gesprochen haben.

[Zacherl]

Zitat:

Zitat von Codehunter (Beitrag 1332196)

Wie sieht das eigentlich mit dem MacOS-Compiler aus? Ist der genauso bescheiden? Was ist dort mit ASM?

Zum MacOS Compiler kann ich leider nichts sagen bezüglich Optimierung und Performance. Ich bin mir auch grade unsicher, ob Delphi überhaupt inline Assembly zulässt, wenn man für Mac compiliert.

Die Mobile Sachen wird man definitiv nicht manuell auf Assembler Ebene optimieren können. Die Performance der PurePascal Routinen sollte sich aber auch von Mobile zu Desktop nicht groß unterscheiden. Die Apple Geräte benutzen ja sowieso natives ARM und auch Android verwendet in der Regel eigentlich keine Java-VM mehr. Das wird alles JIT-compiled und dann nativ ausgeführt.

[Codehunter]

Zitat:

Zitat von Zacherl (Beitrag 1332199)

Das wird alles JIT-compiled und dann nativ ausgeführt.

Wobei ich mich schon frage ob diese JIT-Compiler nicht noch lustigere Konstrukte produzieren als dein obiges Beispiel. Vorallem hat man als Entwickler ja überhaupt keine Kontrolle darüber, welcher Compiler dann für das eigene Programm zum Einsatz kommt.

Wegen solcher Probleme bin ich der Meinung, man sollte auf ASM komplett verzichten und lieber nur den Pascalcode optimieren. Ist vielleicht nicht das letzte Quentchen Performance, aber man hätte bei einem Projekt wie DEC auch wichtigeres zu tun.

Hätte, wäre, wenn... Wer macht jetzt was? ;-)

[TurboMagic]

Genau: wer macht jetzt was?

Und noch etwas: Delphi für Android compiliert nicht nach Java Byte Code, es compiliert direkt nach ARM code. Deswegen funktionieren solche Apps ja auf x86 Android Geräten nur, wenn dort Intels Houdini Emulation integriert ist (was m.W. bei neueren Android x86 Versionen automatisch der Fall ist aber trotzdem immer wieder Ärger macht weil die Delphi App beim Start eine Kompatibilitätsprüfung durchführt die dann gerne meckert)

[MaBuSE]

Zitat:

Zitat von TurboMagic (Beitrag 1331626)

... ich wüsste auch mal gerne den aktuellen Stand, da ich für ein mobiles Projekt eine Pure Pascal Umsetzung gut gebrauchen könnte. ...

Hallo zusammen,
ich habe mir erlaubt Assertor mal direkt anzusprechen :)

Er bat mich die Informationen direkt an Euch weiterzugeben.

Er bestätigt, dass das Projekt leider komplett liegen geblieben ist. Das bedauer er sehr, da ihm das Projekt doch sehr am Herzen liegt.
Es gab zwar viele Komponentenhersteller, die DEC selbst nutzen und anfragten, aber keiner war bereit Unterstützung bei der Portierung / Weiterentwicklung anzubieten.
Ihm fehlt schlicht die Freizeit um das noch "nebenbei" zu machen.
Es war privat und beruflich viel los, gab große Änderungen. Zu viel um das hier zu schreiben.

ABER (und das ist die gute Nachicht):
Seit neuestem ist da wieder was im Gange, Markus Humm integriert seine Änderungen am ASM Code in etwas lauffähiges seit vorletzter Woche.

So wie es aussieht sollte es bis Mitte des Jahres zum DEC 6 Release kommen, wahrscheinlich sogar früher (ETA wäre wohl Mai).
Das ganze kommt dann auf GitHub. Support D2009+, für altes gibt es die alte DEC.

Sobald er wieder etwas Luft hat, meldet er sich hier im Forum.
(Das kann aber noch eine Weile dauern.)

Ich hoffe das alles so klappt, wie er sich das vorstellt.
Ich warte auch schon auf das Update.
Die Gründe warum er die DEC Änderungen nicht schon vorher auf github stellt, beschrieb er ja schon in einem ältern Post.

In diesem Sinne wünsche ich euch (und mir) etwas Gedult.

Viele Grüße
MaBuSE

[Codehunter]

Danke @MaBuSE für die Info.

[mjustin]

Zitat:

Zitat von Zacherl (Beitrag 1332199)

Android verwendet in der Regel eigentlich keine Java-VM mehr. Das wird alles JIT-compiled und dann nativ ausgeführt.

Beziehungsweise (ab Android 5.0) Ahead-Of-Time über ART, nicht mehr mit JIT und Dalvik.

[TurboMagic]

Zitat:

Zitat von MaBuSE (Beitrag 1332433)

Zitat:

Zitat von TurboMagic (Beitrag 1331626)

... ich wüsste auch mal gerne den aktuellen Stand, da ich für ein mobiles Projekt eine Pure Pascal Umsetzung gut gebrauchen könnte. ...

Hallo zusammen,
ich habe mir erlaubt Assertor mal direkt anzusprechen :)

Er bat mich die Informationen direkt an Euch weiterzugeben.

Er bestätigt, dass das Projekt leider komplett liegen geblieben ist. Das bedauer er sehr, da ihm das Projekt doch sehr am Herzen liegt.
Es gab zwar viele Komponentenhersteller, die DEC selbst nutzen und anfragten, aber keiner war bereit Unterstützung bei der Portierung / Weiterentwicklung anzubieten.
Ihm fehlt schlicht die Freizeit um das noch "nebenbei" zu machen.
Es war privat und beruflich viel los, gab große Änderungen. Zu viel um das hier zu schreiben.

ABER (und das ist die gute Nachicht):
Seit neuestem ist da wieder was im Gange, Markus Humm integriert seine Änderungen am ASM Code in etwas lauffähiges seit vorletzter Woche.

So wie es aussieht sollte es bis Mitte des Jahres zum DEC 6 Release kommen, wahrscheinlich sogar früher (ETA wäre wohl Mai).
Das ganze kommt dann auf GitHub. Support D2009+, für altes gibt es die alte DEC.

Sobald er wieder etwas Luft hat, meldet er sich hier im Forum.
(Das kann aber noch eine Weile dauern.)

Ich hoffe das alles so klappt, wie er sich das vorstellt.
Ich warte auch schon auf das Update.
Die Gründe warum er die DEC Änderungen nicht schon vorher auf github stellt, beschrieb er ja schon in einem ältern Post.

In diesem Sinne wünsche ich euch (und mir) etwas Gedult.

Viele Grüße
MaBuSE

Soso, das habe ich damals gar nicht mitbekommen, dass mich jemand sobald geoutet hat! ;-)
Ich wusste auch nicht das Assertor ein Pseudonym des bisherigen Maintainers ist...

Naja, ein neues Release gibt's noch nicht wirklich (es kam uns diverses dazwischen, vieles davon nennt man "Leben") aber:
vielleicht schaut ja der eine oder andere mal auf GitHub vorbei (nein, nicht unter dem Fork den jemand im November
gemacht hat und der viel von FPC schreibt) sondern unter unserem DEC Projekt. Wer dort nämlich genauer hinschaut,
findet evtl. doch schon was ;-)

Nur: wir könnten an diversen Punkten weiterhin Unterstützung gebrauchen.
Manche der Unterstützungstätigkeiten sind sogar recht simpel, wie z.B. mal die DUnit tests unter einer älteren
Delphi Version auszuführen um sicherzustellen, dass es auch da compiliert. Sonst müsste ich da welche installieren
die ich sonst gar nicht mehr bräuchte...
=> freiwillige bitte vortreten und melden, dann gibt's für diese auch mehr Infos zum Stand.

Und keine Panik: wir sind durchaus schon ein gutes Stück weiter als viele jetzt evtl. denken mögen.
Und wen's interessiert: natürlich ist eines unserer Ziele die Cross-Plattform Kompatibilität!
Ich hab' mal selber weil's noch nicht 100% fertig ist vor Monaten je einen hash und einen Cryptoalgo die ich brauchte
rausextrahiert und nutze die jetzt in einer Android ARM App. Das mal als eine Art erster Beweis, dass wir da auch schon
weit fortgeschritten sind.

[TurboMagic]

Ach ja, noch vergessen unseren neuen Slogan zu Verkünden: DEC is back, on track! ;-)
=> wir sind wieder in der Spur ;-)

[TurboMagic]

Zitat:

Zitat von Delphi-Laie (Beitrag 1332088)

Zitat:

Zitat von Codehunter (Beitrag 1332041)

Dann wäre das hier genau der richtige Platz um darüber zu sprechen, nicht wahr? :-) Denn augenscheinlich liegt das Projekt in einem Tiefschlaf. Wenn der Schein trügt sollten die Beteiligten das doch einfach sagen.

Passiert nicht.

Machen wir uns nichts vor: Dieses hervorragende Projekt hat seine besten Zeiten hinter sich. Wahrscheinlich wird es aus seinem 5.2-Stadium leider nie mehr herauskommen.

Falsch! Guckst du GitHub... ;-)

Nur: auch du könntest beim Wachküssen des Dornröschens mithelfen.
Traust du dich das? ;-)

[Zacherl]

Könntest du den Link zum richtigen GitHub Repo mal posten? Bin nicht sicher, was hier das "Offizielle" ist.

[TurboMagic]

Zitat:

Zitat von Zacherl (Beitrag 1396467)

Könntest du den Link zum richtigen GitHub Repo mal posten? Bin nicht sicher, was hier das "Offizielle" ist.

Gerne:
https://github.com/winkelsdorf/Delph...tionCompendium

Mal gespannt, ob du entdeckst was es zu entdecken gibt und ob du dich dann vielleicht als Freiwilliger meldest? ;-)