# Umstieg von Delphi nach?



## bike (6 Oktober 2009)

Hallo,

zur Zeit ist unsere Visualiserung in Delphi geschrieben.
Doch ist der Weg nach jetzigem Wissensstand nicht mehr zeitgemäss.
Auf .net umzusteigen ist nach unserer Meinung auch nicht der richtige Weg, da bei Win M$ bei jedem Release seine eigene Suppe kocht. Und das Angebot bei Open source für andere OS ist nicht so echt gross und ist dann ggF. nicht kompatibel zu dem Win.
Als Programmiersprache haben wir uns zunächst  C++ vorgenommen. 
Doch bei der Oberfläche scheiden sich die Geister 
Qt oder wxWidgets stehen zur Zeit zur Auswahl.

Die Frage ist folgende:
Wenn ihr eigene Visualisierungen schreibt, welche Sprache bzw welche Grafik nehmt ihr?

Es ist aber noch nicht endgültig entschieden ob C oder nicht. 
Hat schon jemand etwas in Java produktionsfertig oder Versuche gemacht?
Was und wie sind eure Erfahrungen?

Wir wollen und müssen verhindern, eine falsche Endscheidung zu treffen.

Danke für Hinweise und Tipps.


bike


----------



## Question_mark (7 Oktober 2009)

*Bleibe mal lieber bei Delphi*

Hallo,



			
				bike schrieb:
			
		

> Wenn ihr eigene Visualisierungen schreibt, welche Sprache bzw welche Grafik nehmt ihr?



Als Programmiersprache bleibt für mich z.Zt. immer nur Delphi als beste IDE übrig, nicht zuletzt wegen der einfachen und problemlosen Anbindung an alle gängigen Datenbanken.

Für die Grafik in der Visu (Ventile, Tanks, Rohrleitungen etc.) verwende ich selbst entwickelte Delphi Komponenten. Die kann ich dann, wenn einmal programmiert, in beliebigen Projekten quasi wie eine Bibliothek wieder verwenden.

Und warum soll ich für ein totes Pferd wie ANSI-C oder C++ noch einen neuen Sattel kaufen ???

Eventuell kommt in der Zukunft noch C# in Frage, aber Du hast ja (aus guten Gründen) das .NET schon vorher ausgeschlossen.


[QUOTE="bikEe]Qt oder wxWidgets stehen zur Zeit zur Auswahl. [/QUOTE]

Das willst Du doch keinem potentiellen Kunden ernsthaft anbieten, oder ???

Gruß

Question_mark


----------



## bike (7 Oktober 2009)

Question_mark schrieb:


> Eventuell kommt in der Zukunft noch C# in Frage, aber Du hast ja (aus guten Gründen) das .NET schon vorher ausgeschlossen.



Gut und danke, dass du das auch so siehst



Question_mark schrieb:


> Das willst Du doch keinem potentiellen Kunden ernsthaft anbieten, oder ???
> 
> Gruß
> 
> Question_mark


Wollen?
Noch? nicht wirklich, doch was dann?

Zur Zeit und bis zur Abkündigung von XP ist das Thema auch nicht so echt heiss. 
Doch was kommt bzw machst du dann?
Weiter mit Win7 oder linux oder?
Laufende  Projekte sind klar, doch ich will für die nächsten 5 bis 10 Jahre wissen wohin der Zug fährt und dafür schon jetzt Vorsorge treffen.

bike


----------



## marlob (7 Oktober 2009)

Question_mark schrieb:


> > Qt oder wxWidgets stehen zur Zeit zur Auswahl.
> 
> 
> 
> ...


Was ist deiner Meinung nach eine vernünftige GUI-Bibliothek und was ist an den obigen auszusetzen?


----------



## bike (7 Oktober 2009)

marlob schrieb:


> Was ist deiner Meinung nach eine vernünftige GUI-Bibliothek und was ist an den obigen auszusetzen?


Verwendest du eine oder beide Bibliozheken in deinen Projekten?
Welche Programmiersprache verwendest du?

Es ist sehr schwer eine Weg zu finden, der für die nächste Zukunft sinnvoll ist


bike


----------



## Rainer Hönle (7 Oktober 2009)

Das große S soll in Bereichen in neuen Appliaktionen auf qt setzen. qt ist für kommerzielle Anwendungen nicht kostenlos (im Gegensatzzu wxwidgets), bietet aber dafür auch direkt Support für die benannten Entwickler (Wechsel nur alle 6 Monate möglich). Fakt ist, dass sowohl qt als auch wxwidgets eine entsprechende Einarbeitungszeit benötigen. Wir standen bei der Entwicklung des Konfigurationsprogrammes von ACCON-AGLink vor dem gleichen Problem und haben uns damals für wxwidgets entschieden. Heute würde ich, da z.B. mono deutlich weiter entwickelt wurde, wahrscheinlich doch eher .net für die portable Programmierung verwenden. Man darf dann nur nicht gleich den neuesten Schrei sofort verwenden wollen. Aber dann sind sogar Windows-.net-Programme direkt (= binärkompatibel) unter Linux ablauffähig.


----------



## Thomas_v2.1 (7 Oktober 2009)

Bei wxWidgets gibt es z.B. keinen (vernünftigen) GUI-Designer. Da muss man je nach Umfang der GUI entscheiden ob einen das stört. Es gibt auch Leute die schreiben die Ressourcen Dateien für umfangreiche Sachen per Hand.

Den Designer von Qt kenne ich nur von Berichten / Videos, und der sieht schonmal nicht schlecht aus.

Damit hast du aber noch nicht die Sprache, denn die GUI-Frameworks kannst du auch aus verschiedenen Sprachen ansprechen, wobei C++ das naheliegendste wäre.


----------



## bike (7 Oktober 2009)

Rainer Hönle schrieb:


> Das große S soll in Bereichen in neuen Appliaktionen auf qt setzen. qt ist für kommerzielle Anwendungen nicht kostenlos



Danke das weiss ich, da bei der 840D SL linux im Hintergrund arbeitet und die OEM Applikationen zur Zeit in WIn erstellt werden und dann über eine VM für Linux kompilert werden.
Wenn es gut ist darf und soll es auch etwas kosten, wenn notwendig.




Thomas_v2.1 schrieb:


> Bei wxWidgets gibt es z.B. keinen (vernünftigen) GUI-Designer. Da muss man je nach Umfang der GUI entscheiden ob einen das stört. Es gibt auch Leute die schreiben die Ressourcen Dateien für umfangreiche Sachen per Hand.
> 
> Den Designer von Qt kenne ich nur von Berichten / Videos, und der sieht schonmal nicht schlecht aus.



Der hat aber wie inzwischen jedes Werkzeug Stärken und leider auch Schwächen.
Ich habe damit verschiedene Versuche gemacht und war nicht zufrieden.



Thomas_v2.1 schrieb:


> Damit hast du aber noch nicht die Sprache, denn die GUI-Frameworks kannst du auch aus verschiedenen Sprachen ansprechen, wobei C++ das naheliegendste wäre.



Die Sprache ist der zweite oder sagen wir so ein Schritt der entschieden werden muss.
Nach allem was ich in den letzten 30 Jahren oder so gesehen habe wird es "die" richtige Entscheidung nicht geben.
Doch neu ausrichten müssen wir uns dennoch, daher die Grundlagenfragen zur Grundlagenforschung.

Stehen eigentlich nur wir vor dem Problem oder wie wird sonst damit umgegangen?

bike


----------



## marlob (7 Oktober 2009)

Rainer Hönle schrieb:


> Das große S soll in Bereichen in neuen Appliaktionen auf qt setzen. qt ist für kommerzielle Anwendungen nicht kostenlos (im Gegensatzzu wxwidgets), bietet aber dafür auch direkt Support für die benannten Entwickler (Wechsel nur alle 6 Monate möglich)...


Soviel ich weiss steht die neueste Version von QT unter der LGPL.  Dadurch sollten Firmen mit propietärer Software Qt nun kostenlos nutzen können


----------



## marlob (8 Oktober 2009)

bike schrieb:


> Verwendest du eine oder beide Bibliozheken in deinen Projekten?
> Welche Programmiersprache verwendest du?
> 
> ...


Für mich programmiere ich meist in Python und wenn ich eine GUI brauche, benutze ich die wxwidgets (bzw. den wrapper wxPython). Die sind plattformunabhängig, quelloffen und stehen unter der LGPL.


----------



## pvbrowser (8 Oktober 2009)

Eine gute Wahl dürfte C++ und Qt sein, weil das aktuell gepflegt wird und zudem plattformunabhängig ist.

Um nicht bei Adam und Eva neu anfangen zu müssen kannst Du auf vorhandene Frameworks zurückgreifen.

Da möchte ich Dir besonders unseren
http://pvbrowser.org
empfehlen.
Also ein Framework, das auf C++ und Qt aufbaut und plattformunabhängig ist.


----------



## bike (8 Oktober 2009)

Danke für die Info.
Also der Trend geht zu C++, doch bei QT sind wir noch in Zweifel.
Eigentlich wollten wir die Software verkaufen und nicht die SOurcen offen legen.
Dann brauchen wir Lizenzen und das ist ein teueres Hobby.
Und die Kosten bleiben während der gesamten Lebenszeit des Projektes, da bin ich mir nicht ganz schlüssig ob das gut ist.
Bei Delphi habe ich mit dem Erwerb des Produktes alles abgegolten und kann damit Geld verdienen. 

bike


----------



## argv_user (8 Oktober 2009)

Wenn es so ist wie oben schon jemand erwähnt hat, dass Qt jetzt unter der LGPL steht, dann braucht Ihr a) keine Lizenz und b) keine Quellen rausrücken.

Aber:
Ich habs ja eher mit Anwendungen, die man nicht alle paar Wochen neu starten muss, daher noch folgender kleiner Seitenhieb

Ich kann es mir nicht verkneifen: auch Qt ist ein Framework, das zwar funktioniert, und sogar die Quellen einsehbar sind, ich habe aber immer Bedenken hinsichtlich der Garbage-Collection von C++. Irgendwann steht die Kiste, und keiner weis warum.

Daher soll der erste Satz auch keine Empfehlung darstellen.


----------



## zotos (8 Oktober 2009)

argv_user schrieb:


> Wenn es so ist wie oben schon jemand erwähnt hat, dass Qt jetzt unter der LGPL steht, dann braucht Ihr a) keine Lizenz und b) keine Quellen rausrücken.





			
				de.wikipedia.org schrieb:
			
		

> Im Januar 2009 teilte Qt Software mit, dass die Version 4.5 unter der LGPL verfügbar sein wird.[8] Am 3. März 2009 wurde diese dann veröffentlicht.[9] Durch die LGPL ist es möglich auch ohne eine kostenpflichtige Lizenz proprietäre Software mit Qt zu entwickeln, ohne den Quellcode veröffentlichen zu müssen. Lediglich bei Änderungen am Quellcode von Qt selbst müssen diese Änderungen, als Quellcode, veröffentlicht werden.



Füllzeichen


----------



## Rainer Hönle (8 Oktober 2009)

argv_user schrieb:


> Wenn es so ist wie oben schon jemand erwähnt hat, dass Qt jetzt unter der LGPL steht, dann braucht Ihr a) keine Lizenz und b) keine Quellen rausrücken.
> 
> Aber:
> Ich habs ja eher mit Anwendungen, die man nicht alle paar Wochen neu starten muss, daher noch folgender kleiner Seitenhieb
> ...


Der Garbage Collector ist doch .net (oder früher auch VB). Bei plain C++ ist jeder selber für den Speicher verantwortlich.


----------



## pvbrowser (8 Oktober 2009)

@bike

1. Qt steht unter LGPL -> Deine eigenen Sourcen musst Du nicht offen legen
2. Bei Spezialsoftware sind die Kunden sehr dankbar für den Sourcecode
3. Bei Stangensoftware hast Du recht (Verdienst)
4. Du verkaufst Dein Engineering, nicht Software
5. Sieh Dir pvbrowser zumindest mal an. (GPL/commercial license)


----------



## bike (8 Oktober 2009)

Danke für die guten Infos.:TOOL:
Also das mit der Lizenzsierung ist mir nicht so ganz klar, was wann wie gemacht werden darf oder gemacht werden muss.
Ich habe mir den pvbrowser schon angeschaut. Bin mir aber noch nicht ganz schlüssig ob das die richtige Richtung für uns ist. 
Das Teil ist gut gemacht, doch wir stellen CNC- und Automatisierungsanlagen für verschiedenste Produkte her.

Zur Erklärung: Unser Visualisierung kann über einige wenige Einträge in einer Konfigdatei für die verschiedenen Anlagen verwendet werden. 
Es wird immer die selbe Visualisierung installiert, die Konfiguration macht den Unterschied. Ist im weiteren Sinn an Transline2000 angelehnt.
Die Programmiersprache wird, auch nach den Statment hier, C++ sein. 
Wegen der GUI werden wir es wie oft machen: 
Jugend forscht 

Und welchse OS wird später entschieden.
Ein MAC als Visualiserung wäre doch eine interessante Idee 

bike


----------



## Rainer Hönle (9 Oktober 2009)

Frage am Rande: Wie erfolgt der Zugriff auf die NCK-Variablen?


----------



## bike (9 Oktober 2009)

Der Zugriff erfolgt über dde von der PCU. 
Wenn du von extern zugreifen willst musst du dir einen Server schreiben und auf der PCU installieren.
Wenn du mir sagst welche Sprache, kann ich dir die Info und ggF ein Programm zuschicken.

bike


----------



## RobiHerb (9 Oktober 2009)

*.net*

Für ein neues grösseres Projekt hatten wir Anfang des Jahres eine ähnliche Entscheidung zu treffen. Es ging von Java über Qt bis zu .NET.

Gegen .NET haben alle Emotionen gesprochen, aber es hat das Rennen gemacht und wir sind heute zufrieden.

Erstaunlich, wie ähnlich C# an C++(über 10 Jahre Erfahrung) liegt.
WPF 3.5 ist eine mächtige Technologie.
Die Resourcen, die der PC verschlingt, sind bezahlbar.
Visual Studio ist ausgereift, lediglich Eclipse finden manche im Team besser.

Und Last not Least, wir machen nicht nur SPS und Verwandtes, das Gelernte kann man als gute Investition auch in anderen Projekten anwenden.


----------



## juergen1969 (9 Oktober 2009)

Hi,
ist evtl. ein bischen spät, aber dennoch:
Ich benutze fast ausschließlich nur noch C# und das seid fast 4 Jahren.
Ich habe mal Mono ausprobiert, was mittlerweile durchaus zu empfehlen ist. Viele der großen Linux-Distributionen haben Mono schon "on Board" mit .Net Framework 2.x, was schon sehr leistungsfähig ist. Um auf Mono umzusteigen, sollte WPF integriert sein, was dann aber eine mächtige Alternative zu allen anderen GUIs wäre.
C++ kommt für mich nur noch in Ausnahmefällen zum Zuge, da Benutzeroberflächenprogrammierung einfach zu umständlich ist.

Gruß,
Jürgen


----------



## Rainer Hönle (9 Oktober 2009)

Du meinst dann C++ unmananged (oder old style)?


----------



## juergen1969 (9 Oktober 2009)

Ja, richtig, unmanaged.

Musste letztens eine dll in C++ managed programmieren, was auch nicht gerade der Brüller ist.


----------



## marcengbarth (27 Oktober 2009)

Ich sehe das wie Question_Mark und würde ruhig bei Delphi bleiben. Außerdem gibts ja auch Delphi Prism, was dann .Net bzw. Mono ist.


----------



## Indi.An-er (27 Oktober 2009)

Hallo,
ich kann mich eigentlich Juergen1969 anschliessen. Ich erstelle schon seit geraumer Zeit Visualisierungen innerhalb der .NET-Schiene (VB,C#) und habe damit eigentlich sehr gute Erfahrungen gemacht. Die .NET Anwendungen laufen eigentlich problemlos durch, Probleme mit dem GC hatte ich eigentlich noch keine. Wenn man dann noch ein wenig aufpasst und das Mono-Framework als kleinsten gemeinsamen Nenner betrachtet laufen die Apps dann auch unter Linux/Mono. 
Aber ich denke dass es immer auch eine gewisse "Geschmacksfrage" des Entwicklers ist welche immer eine große Rolle bei der Wahl der Entwicklungssprache spielt.

Gruß Jörg


----------



## Grubba (4 November 2009)

> Und warum soll ich für ein totes Pferd wie ANSI-C oder C++ noch einen neuen Sattel kaufen ???


...war mal ein Zitat als Pro-Argument für Delphi.

Wenn ich aber schon kein totes Pferd mehr neu satteln will, warum dann aber ausgerechnet ein schon verfaultes?

Ich mag Delphi sehr, auch wegen der Einfachheit und Lesbarkeit. Ich würde ja auch gerne bei Delphi bleiben, aber ein paar Sachen haben mich doch davon abgebracht.

Ich programmiere für unsere Visu inzwischen auch viel mit 3D. (OpenGL oder Direct3D) Dann gehts auch schon los. Natürlich kann ich (und habe ich auch) OpenGl unter Delphi machen. Header dafür gibts aber erstmal keine. Es gibt zwar immer noch nette Leute, die einem diese Arbeit abnehmen, man ist dann aber halt immer auf diese angewiesen. Kommt was neues, steht man mal erst wieder auf dem Schlauch. 

Habe dann mal auf C++ umgestellt, weil ich irgendwann Direct3D machen wollte. Habe Borland C++ verwendet, weil die Oberfläche ja schon von Delphi bekannt war und ich nicht wieder alles neu lernen wollte. Direct3D Header eingebunden (die es für Delphi auch nur von lieben Menschen gibt, die sich da die Arbeit gemacht haben) - Tataaa..... Header Dateien vom Borland Compiler nicht vernünftig einzubinden. Internet durchsucht, irgendein sehr netter Mensch aus Russland hat sich die Mühe gemacht, den auch für Borland Nutzer nutzbar zu machen. 
Usw. usf. 

Inzwischen habe ich mich für C# entschieden, obwohl (oder gerade) weil es von MS kommt und schon seit ein paar Jahren auf dem Markt ist. .Net ist kein Hindernis, da es inzwischen ja auch Mono gibt und eben auch schon sehr, sehr weit verbreitet ist. Davon mal abgesehen : Wieviele Anwendungen hat man schon geschrieben, die auf Linux und Windows laufen mussten? 
Von allen Herstellern gibt es für neue Produkte Bibliotheken für C++, C+ usw. Aber Delphi suche ich immer öfter vergeblich.

Prism ist ja (laut meinem Kenntnisstand) Delphi unter .Net. Dann bleib ich doch lieber bei C#, weil MS das garantiert nicht so schnell untergehen lassen wird. Borland (oder Embarcado) hat in den letzten Jahren so viele Delphi-Versionen rausgebracht, wie andere Leute die Wäsche wechseln. Nur jedesmal wieder mit neuen Fehlern. 

Und sollte man irgendwann auch mal die Firma wechseln und die Stellenangebote lesen, steht da leider nie was drin a la "Delphi Erfahrung zwingend gesucht", sondern halt häufig "c#, c++ oder .Net" 

Insofern vielleicht auch eine Bildungsinvestition in die Zukunft, nicht bei Delphi zu bleiben.


----------



## Hand (7 November 2009)

Delphi ist tot.


----------



## zotos (7 November 2009)

Hand schrieb:


> Delphi ist tot.





			
				Friedrich Nietzsche schrieb:
			
		

> Gott ist tot.



Sollen wir diese Todesanzeigen nun ins unendliche fortsetzen?

Es gibt nicht die einzige und wahrhaftige Programmiersprache und je nach dem welche Schwerpunkte man setzt kommen ganz andere Favoriten dabei raus. Ich persönlich finde es schade das sich die Pascal Nachfolger nicht in der breiten Masse durchgesetzt haben.

Die Tendenzen zeigen wohl auf C#. Aber auch dies wird eine Zeitlich begrenzte Erscheinung bleiben. Es lebe der Fortschritt!


----------



## Ralle (7 November 2009)

zotos schrieb:


> Sollen wir diese Todesanzeigen nun ins unendliche fortsetzen?
> 
> Es gibt nicht die einzige und wahrhaftige Programmiersprache und je nach dem welche Schwerpunkte man setzt kommen ganz andere Favoriten dabei raus. Ich persönlich finde es schade das sich die Pascal Nachfolger nicht in der breiten Masse durchgesetzt haben.
> 
> Die Tendenzen zeigen wohl auf C#. Aber auch dies wird eine Zeitlich begrenzte Erscheinung bleiben. Es lebe der Fortschritt!



Ja, was Delphi betrifft, sehe ich das auch so, aber Borland hat da wirklich so richtig Sch... gebaut, sowohl was die ständigen Namens- und Firmenwechsel, als auch die Preise betrifft!


----------



## Hand (9 November 2009)

Hallo,

ich setzte auf Python mit wxWidgets bzw. pyQT als GUI Toolkit.
Das ganze läuft somit unter linux, windows und mac.

Falls ich irgendwann zu .NET wechseln muss, kann ich den Code mittels IronPython wiederverwenden.

Kleine Module werden je nach Leistungsanforderung auch mal nach c++ ausgelagert.

Somit habe ich eine möglichst große portabilität, modularität und vorteile in der Entwicklungsdauer.


----------



## RobiHerb (22 November 2009)

*Reflektor*

Ich hatte ganz vergessen in der Diskussion. Wenn man irgendein Programm in einer .NET Sprache geschrieben hat und es kompiliert zu einer EXE oder DLL, kann man darauf das Freeware Programm Reflektor ansetzen.

Dieses Programm analysiert das "EXE" (.NET ist kein EXE im klassischen Sinne) und kann den Source Code wieder aus dem Exe erstellen. 

Der Clou ist, man kann sich bei der Rückwandlung die Source Sprache wählen, C#, C++, VB oder auch Delphi. So sieht man sehr gut, wie die verschiedenen Sporachen arbeiten.

Wers nicht glaubt, wird überrascht sein!


----------



## Thomas_v2.1 (22 November 2009)

Interessant, wusste garnicht dass da sogar die Funktions- und Variablennamen in der exe-Datei gespeichert werden.

Einige Webseiten versuchen sogar bei ihrem Javascript den Codeklau - oder zumindest das Einsehen des Codes - zu verhindern, in dem alles durch einen Code Obfuscator geschickt wird, welcher Formatierung entfernt, sowie Funktions- und Variablennamen durch Zufallszeichenfolgen ersetzt. 

Solche Obfuscatoren gibt es für .Net Programme auch wie ich gerade gesehen habe.


----------



## Indi.An-er (23 November 2009)

NET-Compiler erzeugen keinen Native-Byte-Code sondern wandeln den Code in CIL-Code. Das ist so eine Art vorkompilierter Zwischencode welcher auch noch mit einem einfachen Editor lesbar ist. 
Erst zur Laufzeit wird der Code vom jeweiligen .NET-Framework "Endkompiliert". Dadurch wird die Assembly theoretisch Plattformunabhängig, läuft zum Beispiel auch unter 64-Bit, oder immer da wo ein .NET-Framework installiert ist. Durch diese Zwischenkompilierung ist es auch möglich mittels Reflektion den implementierten Code zurück in eine .Net-Sprache (C#, VB etc.) zurückzuwandeln.
Allerdings ist es auch möglich Net-Assemblys gleich von Anfang an mittels Ngen.exe in nativen Bytecode zu kompilieren. Dann wird der letzte Schritt des Endkompilierens vorweggenommen, und ein Rückwandeln mittels Disassembler ist nicht mehr so einfach möglich. Die Datei verliert damit aber auch ihre Plattformunabhängigkeit, und muss dann für jedes Betriebssystem einzeln bereitgestellt werden. 
Mit Obfuscatoren kann der CIL-Code auch mehrstufig bis zur Unlesbarkeit verschleiert werden. Ein Reverse-Engineering macht dann nicht wirklich mehr Spass.:neutral:

Das alles gilt genauso in der Java-Welt.


----------

