Bei den Fulgan DLLs geht es um die Dependencies auf die Microsoft Runtime DLLs so ich mich recht erinnere.
Wenn du Apache unzippst, dann kommt der genauso wenig auf die Füße. Deswegen nimmt man den Installer. Dazu gleich später.
---
Eine Anwendung ist ein eigenes Betriebssystem. Du kannst ruhig eine eigene Version Implementieren.
Das mit den Abhängigkeiten hat damit zu tun, dass Delphi Anwendungen oft im UNIX Style verteilt werden.
Der Installer kommt von geschlossenen Systemen. Die ursprünglichen geschlossenen Systeme kannten keine Workstation. Der Operator hat ein Band eingelegt das sich selbst installiert hat mehr oder weniger. Bei IBM Rechner hattest du je nach Ergebnis eine Zahl auf einem Display am Server (Return Code wenn man so will). Es gab nur einen Rechner.
---
Eine Oracle wir ja nicht am Server installiert. Die wird auf einer Workstation installiert und dann vom Systemadministrator kopiert. Der Sysadmin weiß was installiert ist. (Dependency Management)
Ein Teil der Installation das Linken der statischen Libraries oder der Stubs ... Die Schnittstelle nach außen ist gleich und die Implementierung im Kontext des
OS eine andere.
Denke an die Java Application Server. Jeder hat ein JBOSS installiert und dann wird wild herumkopiert.
---
UNIX ist ein Peer to Peer Konzept. Die hatten Workstations.
UNIX Style Deployment heißt, dass du lokal übersetzt und Sysadmin kopiert 'manuell'.
Jetzt ist man immer wieder gefangen in der Welt zwischen Infrastruktur das vom
OS bereitgestellt wird und dem Linken der Security relevanten Teile in die Applikation.
Windows ist der Versuch von
DEC auf dem sich verbreitenden Anachronismus dem PC Server ein geschlossenes System anzubieten (Windows NT). Was heute in die Cloud wandert entspringt der Logik der geschlossenen Systeme, spätestens beim Thema Security.
Der Nachbau des IBM Mainframe mit Terminals sit die Web Applikation. Jetzt hast du auf einmal so die Idee, dass der Apache mit Scripting die Security des
OS bemüht. Der Weg das nachzubilden ist die Shared Library (oder auch
DLL unter Windows).
In der UNIX Philosophie der frühen Tage ist der Server und Client dasselbe Programm. Wenn du die Library statisch linkst. Das entspräche in der Delphi Welt bspw. dem Linken von ELDOS SSL oder eine anderen Delphi SSL Implementierung.
---
SSL sichert an sich ja nur den Client vor einem 'bösen' Server und in weiter Folge die Kommunikation. SSL sowie das im Moment im C/S Stil verwendet greift grad mal so weit wie die Anforderungen an einen Webshop. Two-sided SSL käme dem näher was der Benutzer so glaubt ...
---
Eine nettes für eine echte Multi Tier Implementierung von Anwendungssecurity wird bei SecurBrige mitgliegert (
SSH).
---
An sich wird aus der Idee des geschlossenen Systems heraus bspw. ein Zertifikat oder die Anmeldung von der Infrastruktur verwaltet. Sonst musst du die dir selbst bauen.
---
Ansonsten nehme ich einfach irgendwelche SSL dlls. Fulgan ist nicht Pflicht unter
Indy 10. Warum Fulgan im Moment down ist weiß ich nicht.
---
Am Netz sudern viel Leute die ein wenig Hudri Wudri unterwegs sind. Das ist typisch Windows Welt. Windows ist Peer To Peer einersteits und geschlossen auf der anderen.
Auch sehr typisch für die Windows Welt ist, dass es extrem viel Funktionalität in den APIs gibt sich Security in seinem eigenen
OS nämlich der Anwendung anzupassen. Da beginnt der Konflikt. Wenn man das unter Windows durchzieht müsste man fast auf die Funktionen bpsw. in
JEDI Windows Security Code Library zurückgreifen.
Mit SSL aktiv und der Tag ist gerettet machst du keine Meter. Ansonsten kann man nur wie .net oder auch Mono eine Certificate Storage machen usw...
Du hast im
Indy aber die Interceptoren. Auf dem Weg kannst du in eine bestehende Infrastruktur durchaus auch nicht praxisfern dich integrieren.
---
Sobald die Server in der Cloud wo dann der Anachronismus PC Server verschwindet, dann ist man eher wieder sauberer in der geschlossen Welt. Ob das erstrebenswert ist sei dahingestellt.