Reumütig zurück

[Assarbad]

Zitat:

Zitat von implementation (Beitrag 1162142)

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:

Zitat von implementation (Beitrag 1162142)

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:

Zitat von implementation (Beitrag 1162146)

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.

[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

[mkinzler]

Die Diskussion zum Thema WinFS habe ich in diesen Thread ausgelagert

[HausiZ]

Danke für den grossen Feedback.

An Delphi-Laie: Ursprünglich habe ich mit Basic Diealekten gearbeitet. Vor 5 Jahren kam ich zu Delphi und zu Lazarus. Leider war damals Lazarus noch nicht soweit.

Lazarus finde ich toll, ich kann dort vieles, das noch nicht vorhanden ist, selber erstellen und programmieren und ich kann alles, was ich damit machen will, programmieren.

Hausi

[Delphi-Laie]

Danke, HausiZ!

Lazarus ist leider noch ziemlich "alphig", soll heißen, mehr Alpha- als Betastadium. Insbesondere die 64-Bit-Installationen können noch so einiges nicht, leider. Die Arbeit damit ist keine Freude, aber selbst Delphi XE2, das ja nunmehr die 64 Bit entgegensetzen/-halten kann, war in einem für eine professionelle Software erbärmlich geringem Qualitätsniveau (das ich allerdings auch von AutoCAD kenne, genaugenommen grauenhaft fehlerhaft).

Als eine wirklich sehr weit entwickelte Programmier-IDE nahm ich "Indigo" (Java) war. Zu diesem Reifegrad wird Lazarus wohl erst in einigen (wenigen?) Jahren vorstoßen. Für mich aber kein Grund zu "fremdeln".

[HausiZ]

Hallo Delphi-Laie

Klar hat Lazarus noch seine Bugs, doch welche Software hat das nicht. Ich mache halt noch vieles selber, so richtig programmieren und nicht nur Komponenten zusammen kopieren. Da habe ich Lazarus wirklich viele Freiheiten.

Lazarus 64 Bit gibt es seit bald 4 Jahren und dieses sollte in der Zwischenzeit zimlich gut laufen.

Ich mache vorallem kleine Tools mit denen ich SQL Daten auslese etc. So Spezialitäten die Firmen einsetzen, die die entsprechende Software im Einsatz haben. Da ist es mir wichtig, dass ich nur ein EXE versenden muss.

Früher habe ich auch noch Applikationen entwickelt, doch das lohnt sich heute nur noch beschränkt.

Hausi

[QuickAndDirty]

Ich wünschte mir ja ein VS plugin für Freepascal....oder andersrum...völlisch egal