MHumm / DelphiEncryptionCompendium

Cryptographic library for Embarcadero Delphi and potentially for FPC as well
Apache License 2.0
255 stars 66 forks source link

Cleanup #11

Closed geheimniswelten closed 10 months ago

geheimniswelten commented 3 years ago
MHumm commented 3 years ago

Phew! Quite a lot of changes. I'll have to look at those and will try to integrate them. It might take some time though and I might have some questions about some details, but I value this contribution!

geheimniswelten commented 3 years ago

Ein bisschen kann ich auch nochmal erklären.

Die MainUnits der Demos hießen wie die Forms (ohne T), als ich die direkt eingebundenen DECUnits aus den Projekten entfernte, hatte mir der Projektmanager die DPRs zerschossen, weil er die Variablen wie die Forms benennen wollte, aber so hieß auch schon die Unit. Drum die DemoForms umbenannt.

Ansonsten hatte ich aus den Demo- und Test-Projekten die DECUnits aus dem Projekt entfernt (vom Projektmanager entfernen lassen), also das >unit in 'unit.pas',< aus den DPR und den Link aus der DRPOJ raus. Und dann die Suchpfade und Ausgabepfade so, dass die Projekte nun die vorkompilierten DCUs des DEC60-Projekts verwenden. siehe BuildInfo.txt und die OptionsSets (SearchPaths-*.optset)

Vorallem in einer BuildUmgebung will man nicht, dass FremdUnits direkt einkompiliert werden. Bei uns in der Firma werden die meisten BPL und alle DLL/EXE multithreaded kompiliert. Da knallt es immer beim Build und öfters beim Compile, wenn zwei/mehrere Projekte die selben Units zeitgleich kompilieren wollen, also die DCU schreiben, während ein Anderer auch grade lesen/schreiben will.

Außerdem haben alle DCU-Versionen absichtlich ein eigenes Verzeichnis, inkl. Delphi-Version. Einmal kann man so für Alle vorcompilieren, und wenn du die Ausgabe änderst, z.B. Config oder Platform umschalten, vorm Compile, oder mit mehren Delphiversionen arbeitest, dann kommen dir nicht ausversehn "falsche" DCUs in die Quere.

Und die Compilate sind aus den Source-Verzeichnissen raus.

MHumm commented 3 years ago

Ich verstehe noch nicht, warum deine FPC Kompatibilitäts-Commits für DECUtil.pas aus den ProtectString Prozeduren für RawByteString und AnsiString eine Entweder/Oder Geschichte machen. Kann FPC kein RawByteString? Falls es das wäre, wäre ich für entsprechende FPC IFDEFS die das dort dann nicht verfügbar machen, denn RawByteString und AnsiString sind für mich semantisch schon was anderes und ich hab' auch nicht geprüft, was der Compiler macht wenn AnsiString verfügbar ist und man aber einen RawByteString hat den man an die ProtectString methode übergeben würde.

MHumm commented 10 months ago

I manually implemented those parts I found helpful etc. so I close this one now.