Reumütig zurück

[mschaefer]

Erstaunlich was ein Rückkehrer alles auslösen kann.

Selbst bin ich mit vier Sprachen unerwegs und merke auch, dass Delphi für eine Contracter derzeit eher schwierig ist. Da ist im Embbeded Bereich doch stabileres Einkommen. C kann man auch gut neben Delphi aktuell halten.

Aber Delphi hat für Desktopapplikationen immer noch einen guten Ruf. Für die Zukunft würde ich mir die Unterstützung von Java-Bytecode durch Embracadero wünschen. Sowas wie Xdev nur mit Delphi. Schauen wir mal.

Grüße in die Runde // Martin

[Assarbad]

Zitat von implementation:

Plattformunabhängigkeit fängt ja auch im Kopf an Man kann auch wundervoll Anwendungen entwickeln, ohne auf die WinAPI zurückgreifen zu müssen. Ich kann mir keine Situation vorstellen, an denen es keine Alternativen gibt.

Die gibt es schon, aber ich gebe dir recht. Leider sind viele Leute sehr verbohrt, was ich an einem meiner Kollegen immer wieder merke. Der würde jederzeit irgendwas mit dem Etikett "Microsoft" anderen Dingen vorziehen und stürzt sich immer sogleich auf die neueste von Redmond angepriesene MS-Technologie. Sein Argument warum eines unserer kommenden Produkte nicht mehr Windows 2000 unterstützen sollte basierte darauf, daß er kurze Entwicklungszeit und gute Wartbarkeit verwechselt und daher mal fröhlich auf .NET (WFP usw.) setzt. Prinzipiell habe ich nichts gegen .NET, aber es kommt auf die Einsatzgebiete an und in diesem Fall bin ich strikt dagegen.

Weiterhin argumentierte er, daß die Unterschiede zwischen Windows 2000 und XP (ab SP2) zu gravierend seien um Windows 2000 noch zu unterstützen. Was natürlich Quark (bzw. Skyr) ist. Alles was es in Windows 2000 noch nicht gab könnte man mit funktionslosen Stubs auffüllen und durch Delay-Loading kaschieren, für den Rest ließen sich dann noch immer plattformspezifische Module erstellen, wenn es denn nötig wäre.

Aber der gleiche Kollege ist es auch, der seit Jahren verhindert daß eine plattformübergreifende (Windows, Linux, AIX, Solaris, MacOS X, FreeBSD, NetBSD, OpenBSD) Bibliothek für diverse gemeinsame Funktionalität innerhalb unserer Produkte eingesetzt wird. Das Argument ist im Grunde das gleiche wie bei Windows 2000 vs. XP, wobei dann mit diversen anderen Dingen argumentiert wird. Auch das läßt sich natürlich leicht widerlegen. Denn wenn es bspw. nur auf Windows Alternate Data Streams (ADS war in diesen Sachen immer sein Hauptargument) gibt, kann man die bspw. über die gleiche Funktion auflisten welche die Dateinamen in einem Verzeichnis zurückgibt und diese auf Windows eben entsprechend implementieren. Da ADS wie auch der Standarddatenstrom einer Datei über die klassischen APIs angesprochen werden können (inkl. deren C-Lauzeit-Pendants), sollte dies keinerlei Problem darstellen.

Zitat von implementation:

Wenn man ein entsprechend großes, für Windows geschriebenes Programm portieren will, kann man es häufig auch besser gleich neu schreiben. Aber wer seinen Code von vornherein ädaquat schreibt, wird keine Probleme haben.

Sehe ich auch so. Wobei es durchaus möglich ist derlei Dinge zu portieren wenn sie denn nicht direkt auf bspw. den GUI-APIs aufsetzen. Handelt es sich um eine Kommandozeilenanwendung (Daemon/Dienst), ist die Aufgabe durchaus machbar - der Aufwand aber dennoch fragwürdig.

Zitat von implementation:

Was kann die WinAPI, was nicht auch durch Bibliotheken abgedeckt werden kann, die auf allen Zielplattformen laufen?

ADS, siehe oben. Aber das ist zumindest für mich keine vernünftige Ausrede.