EMB DEC 12 - Linux Programme erstellen - HowTo ?

[paule32.jk]

Hallo,

ich möchte gerne Linux-Programme mit EMB DCE 12.0 erstellen, und habe bei der Suche von Informationen recherciert, das es auch möglich ist, mit Delphi unter Windows, Linux-Programme zu entwickeln.
Viele Informationen, die aus dem Netz gefischt hatte, das man den Installer nutzen sollte, um Komponenten nachzuinstallieren.
Nur dummer weise verlangt der Delphi Installer eine Neuinstallation (bei der die alte Version komplett gelöscht werden muss, bevor man mit dem Installer Packete auswählen kann...
Das ist für mich aber ein no-go.

Daher nun die Frage: wie kann man in DCE 12.0 das Installier-Programm so aufrufen, das Linux installiert werden kann ?

[noisy_master]

Zitat von paule32.jk:

Daher nun die Frage: wie kann man in DCE 12.0 das Installier-Programm so aufrufen, das Linux installiert werden kann ?

Gar nicht: Die Community Version supportet keine Linux Entwicklung...funktioniert erst ab Enterprise https://www.embarcadero.com/de/produ...oduct-editions

[Sinspin]

Mit Wine geht das. Da kannst Du auf Linux mit Delphi Programme erstellen.

[himitsu]

Es gab anfangs nur den Bug, dass man im Setup Linux auswählen kann/konnte (bei der Professional und vermutlich nun auch CE), aber es dann dennoch "leider" nicht installiert wurde.

[dummzeuch]

Zitat von Sinspin:

Mit Wine geht das. Da kannst Du auf Linux mit Delphi Programme erstellen.

Delphi 12 funktioniert unter Wine? Ausprobiert?

[himitsu]

lässt sich dort installieren .. glaub fast nicht?

Und mindestens das .NET geht von Haus aus nicht.

[paule32.jk]

schade eigentlich, das man tonnenweise zusatz toolchains installieren muss,
wenn man für verschiedene Systeme kompilieren will (ich rede hier nicht vom
ausführen, das ist auch noch so nen Ding - Emu hier Emu dort...).
Gerade auch deswegen, weil hier FPC und Lazarus Support gegeben wird.

Hat jemand schonmal FPC für Linux unter Windows zum laufen gebracht ?
Wie kann das erreicht werden ?

[MichaelT]

FPC/LAZ ist deine Option. Du wirst dem nicht entkommen. Glaube es einen 'alten Mann' oder deren mehrere. Die Chance, dass Linux Support ohne Support jemals in eine Community Edition kommt ist gering, selbst die Professional Version ist bei den Usern beliebt, aber nicht zwingend bei EMB.

Linux Support gibt es mit der Enterprise Edition von RAD-Studio.

Delphi war schon immer ein IDE für Enterprises. Es hat sich in den 1990ern so eingebürgert, dass es aufgrund des bis so um die V5 günstigen Preises und dem schwarz herumkopierten Quellcode der Third-Party Komponenten in 'niedrigere Gefielde' hat angesiedelt.

Embarcadero liefert bei passendem SLA dir möglw. einen eigenes für dich gefixten Compiler und solche Sachen. Wenn du mehr von der Selbst ist der Mann Liga bist, dann siehe Zeile 1.

Es gab ein paar Versuche die hungrigen Mäuler mit bspw. den Turbos (Delphi 2006) zu stopfen usw. und die Turbos waren erquicklich und relativ schlank und im Funktionsumfang, wo ich mich recht erinnere kaum eingeschränkt.

Wer moderne Turbos sucht und möglw. gegebenenfalls so den Floating Forms anhängt, muss man nicht, siehe Zeile 1.

Nichts gegen Delphi oder RAD Studio, ich nehme zwar noch immer Delphi 10.3.2 und 10.4.1, aber hege und pflege eine Installation von 11.3 Enterprise auf einem zweiten Gerät.

In der Praxis knalle ich mir eine Box mit Linux und FPC/Laz in den Virtual Box Manager, muss man mit der Zahl an Images haushalten und das war es für 99% von allem anderen als VCL Desktop. Local macht Freude und zur Not holst du dir von Remote den Lazarus auf deinen aktiven Linux Desktop (dup bspw.). Braucht man allein, hatte das öfters unter Linux mit nicht LTS Releases aufgrund einer geänderten Security Einstellung im Image, dass man selbst in der Shell den gdbserver hat gefunden, aber nicht remote. Das war zur Zeit als Water (Elements) noch eher jung war und native Compilation in den Kinderschuhen steckte. Mittlerweile kommt mit dem FPC/Laz selbst unter Windows ein funktionierender gdb mit.

Aber jetzt mit dem internen Debugger ist schon ein Punkt weniger auf der Cons Liste.

Zitat von paule32.jk:

Hallo,

ich möchte gerne Linux-Programme mit EMB DCE 12.0 erstellen,

[paule32.jk]

okay.
Dann bleibe ich wohl lieber bei Python und meinen aktuellen Compiler-Projekt:
hier

Das müsste dann unter Windows und Linux laufen.
Hab das aber noch nicht ausgiebig getestet...

[MichaelT]

Python bietet sich mittlerweile an. Python hatte abseits der Oracle PHP Erweiterung eine brauchbare Unterstützung für die Datenbank und war bis zu einem gewissen Grad webfähig. Damals war PHP am Absterben. Das war so um PHP 4 herum. Python hatte zu der Zeit schon ein soliden Support für 'Bindings Out of the Box', sprich keine Notwendigkeit Header Files zu übersetzen und die 'zentrale' Registratur.

Die Glanzzeit von Delphi am Web war zu Zeiten von ASP. Ein Enterprise Umfeld zeichnet insbesondere die totale Kontrolle über die Infrastruktur aus. FPC/Laz war an sich auch schon nach 2010 in Kombination mit Fast-CGI brauchbar, aber die Billighoster haben einfach die Boxen nach einm Systemauptade in der 'Cloud' haben abgeschossen. Weswegen viel mit Scripting usw. wurde gearbeitet.

In 2009 versuchte ein Freund von mir ein Deployment eines Python Programms zu erreichen. Im Prinzip eine Systemmigration in einem Konzern und von einer einfachen aber praktischen Python 'Anwendung', welche es erlaubte Tabellen zu navigieren, aber für damalige Verhältnisse so richtig fette und über den Webbrowser aus der Zeit nach 2k. Der Anruf beim Support endete, 'Python wer? Python wie? Davon hörten wir nie!' und noch dazu in einer bestimmten Version.

Auch das fällt unter volle Kontrolle der Infrastruktur. Delphi Anwendungen sind diesbezüglich noch immer beliebter, bspw. im selben Konzern eine Anwendung zum Management von Infrastruktur und bei Anlagenreparaturen. In so einem Fall laufen 400 Leute kreuz und quer durch die Gegend und die ausfassten Materialen müssen getrackt werden inkl. Lagerstandsbuchungen (zumindest erfasst). Wenn, wie in einem praxisrelevanten Fall, die Serververbindung zum Rechenzentrum weg ist, dann konnte man mit der Delphi Anwendung einfach eine Sicherung vom Rechenzentrum im Betriebsgelände holen, die Datenbankdateien lokal installieren, den Datenbankpfad verbiegen und weiter ging es. Als diese Anwendungen entstand war es mit .net noch nit weit her, besser gesagt, selbiges in weiter Ferne. Die Anwendung läuft mittlerweile im Alter von über 25 Jahren wie damals. Wenn die 400 Leute ins Stehen kommen, ... und der Anlagenstillstand mit Folgekosten usw. Für Enterprise Szenaren ist Delphi tip top. Sprich auf einer Maske wurde abgebildet wofür man in SAP 24 braucht und viel Modifikation. Tja und so zogen Unmengen an SAP Berater wieder von der IBM von dannen und das nachdem 'Das machen wir so nebenbei mit. Aus Wochen wurde Monate und nach 1,5 Jahren hat die IBM den Stecker gezogen'. Was diese Small Footprint Databases nicht alles in der Lage sind zu leisten.

Anwendungen unter UNIX oder Linux sind nicht wie unter Windows, sprich weniger integriert. Diese Spezialität bietet eher der Windows Desktop.

Der FireMonkey aka. FMX war zu Beginn auch für Business Anwendungen am Mac, siehe U.S. und für Business Anwendung gedacht und in die Linux Option für den EMS, zu Beginn. Später kam der GUI Aspekt supported über einen kürzlich leider verstorbenen Third-Party Provider hinzu.

Enterprise und Professional ist keine Rangordnung. Tools für Professionals waren schon immer anspruchsvoller, da diese 'Berufsgruppe' von der IT lebt. Ein Konzern lebt davon, dass insbesondere auch alles andere klaglos funktioniert. Wenn man serverseitig für Windows Server implementiert und clientseitig eine GUI Anwendung, dann ist man schon in einer Mischung aus Enterprise plus Professional. Der David I. sprach das Thema einmal an, Thema Datenbanksupport in Delphi und C++ Builder, dass die Professional eigentlich für GUI Desktop ist.

In unseren Breitengraden haben wir diesbezüglich eine wenig eine andere Kultur, vermutlich noch aus der Tradition der Integrierten DB-4GL Umgebungen aus den 1990ern und der Verbreitung von Servern unter Windows insb. 4. Bei uns war zuvor eher die Abkehr von CASE-Tools, denn die gerieten zurecht z.T. auch nicht unter Verruf. Diese Lücke haben zuerst VB und Delphi geschlossen, aber wer den Inder am Schoß der Abteilungsleiterin in den 1990ern loswerden wollte, die Typen in den 1990ern eine Handvoll Masken pflegten und das seit der Version 1 und das über die Dekade hinweg, der hat einfach die Entwicklungstechnologie getauscht und Inhouse gegen Professional. Java ist dort relativ hurtig als Reaktion darauf mit den Huge Stacks reingegrätscht.

Aber vor den 1990ern hatten viele mehrere Entwicklungstechnologien zur Hand, das kam in Verruf und seit gut 15 Jahren wieder. Das 'C' als die only one, war eine Reaktion auf Kundenbeschwerden insb. bezüglich COM Programmierung. Die Idee von MS, an sich nicht dumm, war der Professional entwickelt den Teil näher dem OS und der VB Programmierer, zumeist im Business angesiedelt, macht die Masken. Diese zwei Rollen standen sich teils 'verfeindet' gegenüber. Eine Kompromisslösung waren die CRM Systeme mit Dictionary. Die sind gut, aber ich kenne keines mehr, welches entweder wie eine fröhliche Mumie virtualisiert noch immer schnurrt, begleitet von einer Unzahl an ergänzenden 'Utilities', welche sich bspw. um die Erstellung von PDF Report (bspw. in einem Krankenhaus hier), sprich die modernen Aspekte kümmern. Deswegen kam oft eine Anfrage nach Delphi auf Linux schon vor gut 15 Jahren. Das Problem bezüglich FPC Lazarus war die Dokumentation der Systemänderung. Lieber die Daten 100mal mit der Kirche ums Kreuz, als einmal die Änderung eines symbolischen Links dokumentieren und zugegeben zuvor von Gott und der Welt, Leuten die von der IT null Ahnung haben, Unterschriften einholen.

Die Stärken von Delphi & Co kommen dann zur Geltung, wenn die Benutzer und Administratoren im Enterprise Umfeld und dessen Wahnsinn angekommen sind. Noch dazu haben IT Organisationen und mit der Zeit auch die User einen limited Scope, auch z.T. der Fähigkeit gewisse Technologieschienen industriell, sprich 24*7, am Laufen zu halten.

Zitat von paule32.jk:

okay.
Dann bleibe ich wohl lieber bei Python und meinen aktuellen Compiler-Projekt:
hier

Das müsste dann unter Windows und Linux laufen.
Hab das aber noch nicht ausgiebig getestet...