Win32 und .NET (Parallelentw. bzw. Zukunftsperspektive)

[Lothar]

Hallo!

Vorab: Ich habe bereits den Thread Umstieg von Win32 auf .NET? gelesen; darüberhinaus stöbere ich seit Tagen alle Informationsquellen zum Thema durch, vermisse aber etliche für mich ganz entscheidende Infos.

Meine Situation ist so: Ich versuche nicht komplett von Delphi (Win32) nach Delphi .NET zu portieren, sondern mich allmählich mit .NET auseinanderzusetzen. Hintergrund: Ich entwickle seit 17 Jahren in Selbständigkeit ein kommerzielles System, begonnen bei Turbo Pascal (DOS), dann weiter über die Delphi-Versionen in Win, Codeumfang > 100 000 Zeilen. Ich benutze eine selbstgeschriebene Datenbank, wobei ich die Win32-Befehle fürs Filelocking häufig einsetze.

Vorläufig ist .NET für mich überhaupt nicht aktuell, auch mit Vista nicht. Zum einen aber, weil ich die spätere Entwicklung nicht verschlafen will, zum anderen, weil ich gerade Zeit und Lust habe, habe ich mir Turbo Delphi .NET heruntergeladen und probiere gerade, was mit der VCL.NET noch von meinem Code läuft und was nicht. Insgesamt gesehen schluckt der Compiler bemerkenswert viel, bleibt aber speziell bei wichtigen Datei-Befehlen wie Erase oder Rename hängen. (Beim Filelocking fehlt das Handle; was ich aber umstellen kann, sind sämtliche "File of (record)" zu TFileStream.)

Nun meine Frage:
Ich vermisse hier eine klare Frage/Antwort-Plattform zu derartigen Detailfragen, also nicht die üblichen Diskussionen "Ist Delphi tot oder nicht?" oder "Was wird in 5-10 Jahren mit Win32 bzw. .NET?" Habe ich noch nicht richtig nachgeschaut, bzw. wo soll ich solche Detailfragen stellen? Die Turbo-Delphi Hilfefunktion ist eine glatte Frechheit; es kommen immer dann, wenn es interessant wird, Antworten zu Visual Basic und C#, oder einfach nur "Link nicht gefunden".

Also:
Ich stehe momentan nicht unter Druck, aber mit Zukunftsperspektive würde ich gerne parallel auch unter dem Aspekt .NET entwickeln. Ich stelle mir vor, Codepassagen mit $IFDEF CLR bzw. $IFNDEF CLR aufzuteilen und mich entsprechend mit den offenen Punkten weiter vorzuarbeiten. Ihr versteht hoffentlich, daß mich die Fragen, ob Visual Studio/C# bzw. Java und dergleichen "besser" sind als Delphi oder ob man als Purist lieber ganz auf die VCL.NET verzichten sollte, gar nicht betreffen.

Gruß
Lothar

[shmia]

Zitat von Lothar:

Ich benutze eine selbstgeschriebene Datenbank, wobei ich die Win32-Befehle fürs Filelocking häufig einsetze.

Das wäre das Erste, was ich ändern würde.
Wenn du deine selbstgeschriebene DB durch eine SQL-fähige Datenbank ersetzt, ist das ein Quantensprung für deine Anwendung. Ich gehe mal davon aus, dass deine "Homebrew-DB" kein SQL beherrscht.

Du musst damit rechnen, dass manche Operationen (z.B. Einfügen von Daten) auf einer richtigen Datenbank deutlich mehr Zeit benötigen; andererseits werden Abfragen wahrscheinlich viel schneller werden.

Ob das Ganze nun in Win32 oder .NET programmiert wird ist im Vergleich ob ein "vernünftiges" DBMS verwendet wird oder nicht zweitrangig.
Das Wichtigste für die Zukunftsfähigkeit deiner Anwendung ist wirklich ein gutes Datenbankdesign.

Diese Umstellung ist mit viel Arbeit verbunden und du musst dir zusätzliches Know-How über SQL und DB-Design erarbeiten, aber das ist zwingend nötig.

[hoika]

Hallo,

dem stimme ich voll u.
Was Vista als "Dateisystem" mitbringt, ist zumindestens für mich
eine Riesenproduktivitätsbremse.

"Zeit wird berechnet" für 1 MB Daten 30 sek (übers Netz kopieren)
ist ja wohl das letzte.

Unter Vista entwickeln geht mit Delphi <= 6 ja wohl gar nicht.
(Debugger erzeugt Fehlermeldung oder hängt).


Heiko

[Phoenix]

Zitat von Lothar:

oder ob man als Purist lieber ganz auf die VCL.NET verzichten sollte, gar nicht betreffen.

Hallo Lothar,

Ich denke, vor allem dieser Punkt wird Dich in der Diskussion zur Zukunftssicherheit früher oder später Zwangsläufig betreffen. Auch in Bezug auf Vista. Kurzes Beispiel, denn einen Meiner Kunden hat es hier auch schon erwischt: In der Entwicklung wurde entschieden, eine Webanwendung nicht unter Vista / IE7 zu testen, "weil das die Kunden eh noch lange nicht haben und auch so schnell nicht einsetzen werden". Vor 3 Tagen kam ein Kunde und hat gemeckert, weil Excel-Exports von unseren Webdaten nicht geöffnet werden konnten, als er sie mit dem IE7 unter Vista runtergeladen hatte. Und das war der Kunde, bei dem am wenigsten damit gerechnet wurde.

Zwecks Zukunftssicherheit: Ich würde alles, was P/Invoke ist, so weit wie möglich umgehen wollen. Dazu zählt für mich auch die VCL.NET. Es hilft alles nichts, wenn man eine Anwendung hat, die zwar auf dem .NET Framework aufsetzt, aber hintenrum doch durch das Framework schiesst und direkt auf der Plattform Code ausführt. Zum einen ist das langsam, zum anderen nimmt es Dir den Vorteil von .NET, nämlich dass wenn die zugrundeliegende API umgebaut/entfernt wird Deine Anwendung weiterläuft. Das ginge dann nämlich nicht.

Also: Wenn man sich dazu entscheidet, strategisch auf .NET umzusatteln, dann sollte man das möglichst konsequent tun, und nicht die Nachteile die man eigentlich damit umgehen will trotzdem noch mitzuschleifen. Als Zwischenschritt mag die VCL.NET tauglich sein, aber wenn man umsteigt sollte man von Anfang an darauf hinplanen, die dann doch irgendwann abzulösen. - Ausser CodeGear will die P/Invokes demnächst rausziehen und die VCL fully managed machen, nur davon habe ich leider noch nix gehört.

Sollte man den vollen konsequenten Umstieg nicht vorhaben, dann würde ich bei Altprojekten auch komplett bei nativem Win32 bleiben, und die Probleme die man sich mit der .NET Umstellung ggf. einheimst damit von vorneherein ausschliessen. Von einer als solchen geplanten Mischlösung würde ich aus Performance- und Aufwandsgründen definitiv abraten, zumal man damit im Prinzip die Nachteile beider Lösungen vereint und die Vorteile beider verwirft. Das sollte also nur in absoluten begründeten Ausnahmefällen eine Option sein.


Aber nun back to Topic:

Ich denke, die DP ist schon der richtige Platz für Spezialfragen.

Eine Frage von wegen: "Alter Code hier: xxx, wie geht das in .NET? Mir fehlt da das Handle..." dürfte im konkreten Fall recht flott beantwortet sein.

@Hilfe: Ich arbeite nicht mit D.NET, weil es mir zu sehr hinterherhinkt. Ich befürchte jedoch, die Zeiten der bekannten Qualität der Hilfe aus Delphi 7 sind vorbei.
C# Codesamples sollten an und für sich nicht das Problem sein. Als Entwickler sollte man andere Sprachen zumindest readonly ziemlich flott drauf haben. Die Klassen und Methoden sind ja zum Glück in der .NET Welt immer die gleichen

Anlaufpunkt für .NET Doku sollte definitiv MSDN sein und gute Beispiele für so ziemlich alles gibt es bei Codeproject.

[Bernhard Geyer]

Zitat von hoika:

"Zeit wird berechnet" für 1 MB Daten 30 sek (übers Netz kopieren)
ist ja wohl das letzte.

Diese miesen Zeiten liegen auch an nicht angepaßten Netzwerkkarten-Treibern begründet.

Zitat von hoika:

Unter Vista entwickeln geht mit Delphi <= 6 ja wohl gar nicht.
(Debugger erzeugt Fehlermeldung oder hängt).

Geht schon. Mußt nur eine Sache berücksichtigen das bei aktiven Speicherschutz die zu debuggenden Anwendungen ausgenommen werden. Ich weiß nicht ob FastMM, der Debugger oder sonst jemand hier was macht was nicht so ganz OK ist. Aber ich habe mit der IDE nicht mehr Probleme als unter XP wenn man das berücksichtigt. Ach ja: UAC habe ich auch abgeschaltet. Diesen "besoffenen Türsteher" (Aussage c't) brauch ich nicht. Selbst der Explorer hat seine Macken damit.

Back to Topic:

Für einen Sanften Umstieg kannst du dir mal Hydra, Managed VCL und evtl. Chrome anschauen.

[hoika]

Hallo Bernhard,

"aktiver Speicherschutz"
wie nehme ich denn den raus aus meinen Exe?


Heiko

[Bernhard Geyer]

Computer-Icon anwählen, im Popupmenu "Eigenschaften" anwählen.
Erweiterte Systemeinstellungen, Reiter Erweitert Button "Einstellungen",
Reiter Datenausführungsverhinderung.

Also dort wo es jeder suchen würde

[Lothar]

Hallo!

Danke allerseits für die sehr ausführlichen und engagierten Kommentare. Ich weiß das sehr zu schätzen, wenn sich jemand (noch dazu mehrere) die Zeit nehmen, die nötig ist, um solche fundierten Antworten zu schreiben. Andererseits: Diese Art Antworten (Umsteigen auf neue DB, Vermeiden von VCL.NET) habe ich genau befürchtet und das ja bereits in meinem Eintrag von vornherein klargestellt. Es geht also genau nicht darum „strategisch auf .NET umzusatteln“. Als Außenstehender kann man immer leicht sagen, daß man ein mehrstöckiges Haus besser bis auf die Fundamente abreißt und dafür ein neues baut, das uptodate ist.

1. Meine DB ist extrem effektiv. Es werden in diesem Praxisverwaltungssystem zigtausend Patientendaten in ein paar Sekunden (einigermaßen aktuellen PC gerechnet) gelesen, auch ohne Probleme in einem Netzwerk aktueller Machart. Die ganze Quartalsabrechnung läuft wiederum in ein paar Sekunden. Daß eine Standard-DB schneller wäre, glaube ich nicht; die üblichen auf dem Markt befindlichen anderen Systeme sind alle langsamer. Und wie schnell soll es dann werden: Statt 3 Sekunden 2, oder 1? Und dafür dann 1-2 Jahre Umarbeitungszeit?? (Ich müßte weite Teile des Programms umschreiben; hat schon einmal einer überschlagen, wieviel das für 100 000 Zeilen und 17 Jahre Arbeit in etwa ausmacht?)
Nochmal: Mir geht es um nichts anderes als ums Lesen und Schreiben von einfachen Daten in einer Datei. Ich kann mir nicht vorstellen, daß das nicht lösbar wäre, ohne gleich auf SQL o.ä. umzusteigen. Überdies entsteht auch dadurch wieder eine Abhängigkeit. Ein Kollege von mir (ebenfalls kommerzieller Delphi-Entwickler eines Praxissystems, seit 20 Jahren) hat auf derartige Argumente vor vielleicht 15 Jahren gehört und hat nun seine Abhängigkeit von der BDE am Hals. Das ist ja gerade bislang mein Vorteil gewesen, mit der direkten Programmierung direkt und schnell arbeiten zu können und gleichzeitig weitgehend unabhängig zu sein (die Source läuft sowohl unter Delphi 3 aufwärts bis Turbo Delphi). Ich würde das System sogar ggf. unter Lazarus (Free Pascal IDE) zum Laufen bekommen.

2. Zu „Dann würde ich bei Altprojekten auch komplett bei nativem Win32 bleiben“. Das trifft hier wohl zu. Andererseits schaue ich gerne über den Tellerrand hinaus. Das habe ich mit dem erwähnten Lazarus auch schon getan, und nun mit Turbo Delphi .NET.
"Alter Code hier: xxx, wie geht das in .NET? Mir fehlt da das Handle..." -> Ich habe hier - im Gegensatz zum „Delphi-Forum“ - keine Rubrik für derartige Fragen zur Migration bzw. Portierung von Win32 zu .NET gefunden; als Newbie möchte ich aber nicht durch falsche Foreneinträge nerven. Wo also gehört das dann hin?

Grüße
Lothar

[Phoenix]

Ach, im schlimmsten Fall verschieben wir das dann einfach ins richtige Forum

Was VCL / VCL.NET angeht bist Du hier richtig.
Was native API bzw. alles im .NET Framework was keine Controls sing angeht ist wohl eher diese Rubrik die richtige.

[DMW]

Zitat von Phoenix:

Ausser CodeGear will die P/Invokes demnächst rausziehen und die VCL fully managed machen, nur davon habe ich leider noch nix gehört.

Wie könnte das denn aussehen? Auf WinForms zu setzen ist doch eher weniger sinnvoll - es ist ein Wrapper um einen Wrapper, und daß WinForms nicht die Zukunft sind, hat Microsoft doch auch schon verlauten lassen. Und eine VCL für WPF ist IIRC mal in Planung gewesen...