AlmaChua - So 11.04.10 16:27
Titel: Besonderheiten an "Delphi .NET"?

---

guten Tag allerseits,
da das .NET-Board geschlossen ist und ich kein Board für Anfängerfragen gefunden habe, frage ich hier mal:

Ich teste gerade Delphi mit folgender Versionsbezeichnung: "CodeGear Delphi® 2009 für Microsoft® .NET"
Meine Frage ist nun grundsätzlicher Natur, nämlich ob die erzeugten .exe-Dateien überhaupt ohne .NET lauffähig sind? Bei mir laufen sie zwar, aber Delphi hat ja auch alles Nötige für mich installiert. Ich steig da im Moment überhaupt nicht durch. Ich habe bisher nur Konsolenanwendungen in C geschrieben, bzw. Onlinesachen mit PHP usw. Jetzt will ich halt auf relativ einfachem Weg Fensterprogramme schreiben. Mir ist schon am Anfang unklar, welche Art von Projekt ich da im Dateimenü auswählen muß. Meine Anleitungen geben mir da auch nicht wirklich Auskunft. Die steigen einfach direkt mit kleinen Projekten ein.


griezie.
Hoffe, Ihr habt hier keine Probleme mit blutigen Anfängern.

jfheins - So 11.04.10 16:39

---

Ist das noch das alte Delphi .NET in der Delphi-IDE oder das neue Delphi Prism (Visual Studio ähnliche IDE) :?:

Wenns das alte ist: Such den Papierkorb aufm Desktop und ziehe es da hinen :mrgreen:
Prism hingegen ist richtiges .net und das läuft auch überall, wo .net installiert ist. Tutorial gibt's hier: http://prismwiki.codegear.com/en/The_Prism_Primer

AlmaChua - So 11.04.10 18:17

---

jfheins hat folgendes geschrieben :

Prism hingegen ist richtiges .net und das läuft auch überall, wo .net installiert ist.

Die Frage war aber, ob die damit erstellten ANWENDUNGEN überall laufen. Und zwar OHNE .net! Was soll ich damit? Ich kann doch einem Endnutzer meiner Programme nicht zumuten, daß er erstmal das ganze .net-Geschwurbel installieren muß. Da könnte ich ja gleich in JAVA schreiben. Aber wer hat da schon Bock drauf? Die User jedenfalls nicht ;-)

Delphi-Laie - So 11.04.10 18:37

---

AlmaChua hat folgendes geschrieben :

jfheins hat folgendes geschrieben : Prism hingegen ist richtiges .net und das läuft auch überall, wo .net installiert ist. Die Frage war aber, ob die damit erstellten ANWENDUNGEN überall laufen. Und zwar OHNE .net!

Ich rege vorsichtig an, es irgendwo auszuprobieren. Ein Computer mit einem x-beliebigem 32-Bit-Windows ohne .Net wird doch noch irgendwo aufzutreiben sein?!

AlmaChua hat folgendes geschrieben :

Was soll ich damit? Ich kann doch einem Endnutzer meiner Programme nicht zumuten, daß er erstmal das ganze .net-Geschwurbel installieren muß. Da könnte ich ja gleich in JAVA schreiben. Aber wer hat da schon Bock drauf? Die User jedenfalls nicht ;-)

Das ist ein grundsätzliches Problem. Die Entwicklung geht weiter, und die ursprünglichen Betriebsprogramme werden im Laufe der Zeit immer inkompatibler. Bei Vista (?) und Windows "7" (=6.1) soll das .Net(-Framework) schon im Betriebsprogramm integriert sein. Sieh es positiv: Man kan auch XP & Co. noch eine Weile an dieser Entwicklung teilhaben lassen, die Zwangsveraltung älterer Betriebsprogramme verlangsamt sich damit. Das zweite positive: Die Dateien sind so herrlich klein. Das dritte: Der Laufzeitcode wird angepaßt und optimiert. Das vierte: Der Kram bzw. dieses Zeug muß nur einmal installiert werden (obwohl es durchaus sein kann, daß verschiedene .Net-Versionen nebeneinander installiert werden müssen, parallel installierbar sind sie ohnehin).

Eine recht gute Freeware ist z.B. der CDBurnerXP, leider auch nur mit .Net nutzbar. Zuerst störte es mich auch, nun habe ich mich diesem Zustand wegen o.g. Vorteile immerhin in Form einer Art Haßliebe angenähert. Echte Liebe wird sich zu der Mikroweichware/Microsoftware ohnehin nie entwickeln.

jfheins - So 11.04.10 19:52

---

AlmaChua hat folgendes geschrieben :

ob die damit erstellten ANWENDUNGEN überall laufen. Und zwar OHNE .net! Was soll ich damit? Ich kann doch einem Endnutzer meiner Programme nicht zumuten, daß er erstmal das ganze .net-Geschwurbel installieren muß. Da könnte ich ja gleich in JAVA schreiben. Aber wer hat da schon Bock drauf? Die User jedenfalls nicht ;-)

Ach soooo .... nein, natürlich laufen sie nicht ohne das .net Framework. Ist aber auf jedem PC drauf, der XP SP2, Vista oder Windows 7 installiert hat. (Also bei Vista&7 isses auf jeden Fall dabei, bei WinXP oft auch, aber nicht unbedingt)
Es könnte übrigens auch passieren, dass sie (mit mono) auf Linux laufen. Aber das nur Nebenbei ;)

Ach und: Ich liebe Paint.net 8)

Bernhard Geyer - So 11.04.10 21:08

---

AlmaChua hat folgendes geschrieben :

Die Frage war aber, ob die damit erstellten ANWENDUNGEN überall laufen. Und zwar OHNE .net! Was soll ich damit? Ich kann doch einem Endnutzer meiner Programme nicht zumuten, daß er erstmal das ganze .net-Geschwurbel installieren muß.

Die meistens PC werden es schon drauf haben.

AlmaChua hat folgendes geschrieben :

Da könnte ich ja gleich in JAVA schreiben.

Also wir lassen unser Java-Apps laufen ohne was installeren zu müssen. Installation von Java ist nur für den Browser nötig. Ansonsten Java-Verzeichnis mitliefern und java.exe entsprechend (Über Starter-Anwendung) aufrufen.

jaenicke - So 11.04.10 21:35

---

AlmaChua hat folgendes geschrieben :

Ich kann doch einem Endnutzer meiner Programme nicht zumuten, daß er erstmal das ganze .net-Geschwurbel installieren muß.

Das mag bei Systemtools ein Argument sein, die zur Fehlerbehebung o.ä. direkt laufen müssen, aber bei normalen Programmen ja wohl kaum.

Mittlerweile gibt es so viele .NET Programme, dass man da ohnehin kaum drumherum kommt (selbst wenn man es aus irgendeinem Grund wollen sollte).

AlmaChua - Mo 12.04.10 08:12

---

Mir kommmen die Anwendungen etwas langsam vor, kann das sein? Also wie bei Java. Ich hab jetzt ein paar so kleine 'hallo Welt' Programme gebastelt und die brauchen locker 1-2 Sekunden für den Start (10 kB). In der Zeit startet auch die 'Plattenkiste' (1,6 MB) - ein wesentlich umfangreicheres Programm, das eine komplette Plattensammlung verwaltet, Covers zeigt, Musik abspielt, eine Suchfunktion hat usw. usw... Oder Textpad ist im Prinzip sofort da, der M$-Rechner auch (nagut, der hat vielleicht schon was im Speicher).

Und daß .net schon auf Vista und Win7 drauf ist, naja... ich habe XP und das haben viele noch, dich sich klug von dem damaligen Vistahype ferngehalten haben. Die haben auch keinen Grund auf Win7 upzugraden. Und vor einem halben Jahr hatte ich noch Win98. Wüsste nicht, daß da .net drauf war. Aber meine C-Konsolenanwendungen liefen sauschnell.

Gibt es denn keine Möglichkeit, die Anwendungen so zu kompilieren, daß sie völlig unabhängig laufen?

elundril - Mo 12.04.10 08:29

---

Kommt drauf an, aber ich denke die neusten Java und .NET-Versionen verwenden Techniken [http://de.wikipedia.org/wiki/Just-in-time-Kompilierung] die den Code nicht langsamer machen als normale Programme. Und es kommt da auch immer drauf an was der Programmierer zusammengepfuscht hat. ;) Also 2 unterschiedliche Programme kann man da eindeutig nicht vergleichen würd ich sagen. ZB.: Eclipse ist in Java programmiert und startet schneller als mein Delphi-7.

Was mich bei Java stört ist die leichte Transformation von Compilierten-Java-Dateien wieder in Sourcecode (und ich nehme mal an es ist das gleiche bei .NET). Ich hatte mal in der Uni ne Aufgabe und hab als Grundgerüst compilierte Dateien mitbekommen. Damit ich seh was mein Prof. gemacht hab, hab ich das Ding durch einen Decompiler geschickt und der hat nicht nur Java-Code erzeugt sondern auch die richtigen Variablen und Methodennamen wiederherstellen können.

lg elundril

Delphi-Laie - Mo 12.04.10 13:17

---

AlmaChua hat folgendes geschrieben :

Mir kommmen die Anwendungen etwas langsam vor, kann das sein? Also wie bei Java. Ich hab jetzt ein paar so kleine 'hallo Welt' Programme gebastelt und die brauchen locker 1-2 Sekunden für den Start (10 kB).

Ich kenne Java nicht näher, kann mir aber vorstellen, daß dort der gleiche Grundgedanke dahintersteckt: Kompilierung zur Laufzeit, konkret am Anfang.

Vergiß bitte nicht, daß die mit .Net erstellten Exe-Dateien das bisherige Exe-Format sprengen. Sie sind zwar noch ohne .Net grundsätzlich aufrufbar, aber deren Funktionalität reicht nur dazu, das Fehlen irgendeiner DLL zu monieren. Ansonsten ist in diesen Exe-Dateien sozusagen der Quellcode gepackt, der, um es noch mal zu wiederholen, am Anfang compiliert werden muß. Diese Verzögerung ist m.E. noch akzeptabel. Kritischer wird es, wenn auch das generelle Laufzeitverhalten langsamer wird, doch diesbzeüglich ist die .Net-Technologie nach dem, was ich dazu bisher las, höchstens geringfügig unterlegen.

AlmaChua hat folgendes geschrieben :

In der Zeit startet auch die 'Plattenkiste' (1,6 MB) - ein wesentlich umfangreicheres Programm, das eine komplette Plattensammlung verwaltet, Covers zeigt, Musik abspielt, eine Suchfunktion hat usw. usw... Oder Textpad ist im Prinzip sofort da, der M$-Rechner auch (nagut, der hat vielleicht schon was im Speicher).

Eben. Prefetching ist ein solcher Mechanismus, mit dem Mikroweich gleich wieder zweimal seinem Ruf gerecht wird: Unredlichkeit sowie pauschale und sinnlose Ressourcenverschwendung. Alles nur, um dem Nutzer mehr Geschwindigkeit vorzutäuschen, als es in Wirklichkeit genaugenommen bieten kann. Was man sich auf der einen Seite stiehlt, rächt sich an der anderen doppelt: Letztlich wird alles nur quälend langsam.

AlmaChua hat folgendes geschrieben :

Und daß .net schon auf Vista und Win7 drauf ist, naja... ich habe XP und das haben viele noch, dich sich klug von dem damaligen Vistahype ferngehalten haben. Die haben auch keinen Grund auf Win7 upzugraden. Und vor einem halben Jahr hatte ich noch Win98. Wüsste nicht, daß da .net drauf war. Aber meine C-Konsolenanwendungen liefen sauschnell.

.Net soll es laut der Interneamateurenzyklopädie für Win9x m.E. in der ersten Version (1.0, auch noch für 1.1?) geben. Natürlich laufen C-Anwendungen schnell. Und nicht zu vergessen: Auch XP wurde recht schnell eine Massenhysterie, der ich mich aber bis heute nicht anschloß, weil es nur geringe Vorteile gegenüber Windows 2000 gibt, die beim guten Willen auch noch alle in Windows 2000 hätten integriert werden können.

AlmaChua hat folgendes geschrieben :

Gibt es denn keine Möglichkeit, die Anwendungen so zu kompilieren, daß sie völlig unabhängig laufen?

Unabhängig von was? Alles ist in irgeneiner Weise von irgendwem abhängig, Programme konkret von Hard- und Software. Du meinst wahrscheinlich, daß es auf jedem 32-Bit-Windows läuft, nicht wahr? Dann mußt Du auf .Net verzichten und den Compiler, den du benutzt, so betreiben bzw. einstellen, daß er alles enthält, was benötigt wird und nicht auf jedem Windows vorhanden ist (Laufzeitpackages und Laufzeitbibliotheken integrieren). Das muß keinesfalls zu großen Exe-Dateien führen. So compiliert Nir Sofer seine Software in C++ mit Microsofts Visual Studio (letztere erkundigte ich mich bei ihm). Seine Programmdateien sind sehr klein und schnell, benötigen jedoch keine zusätzlichen Laufzeitpackages und sind auch auf Windows 9x (sogar 95?) lauffähig.

AlmaChua - Mo 12.04.10 14:49

---

Delphi-Laie hat folgendes geschrieben :

Du meinst wahrscheinlich, daß es auf jedem 32-Bit-Windows läuft, nicht wahr?

Doch, ist wahr ;-)

Delphi-Laie hat folgendes geschrieben :

Dann mußt Du auf .Net verzichten und den Compiler, den du benutzt, so betreiben bzw. einstellen, daß er alles enthält, was benötigt wird und nicht auf jedem Windows vorhanden ist (Laufzeitpackages und Laufzeitbibliotheken integrieren).

ja, ist das denn mit Delphi möglich? Oder muß ich mich da von vornherein woanders umsehen? Also, ich finde da ja nichtmal den kompletten Quelltext. In der .pas-Datei sind wohl nur die Aktionen des Programms beschrieben. Die Beschreibung der Fenster habe ich bisher vergeblich gesucht. Bin - wie gesagt - ganz neu auf dem Gebiet der Fensterprogrammierung. In meinen C-Programmen war immer alles in einer Datei und natürlich werden da die Bibliotheksfunktionen beim Compilieren mit eingebunden.

Wenn Ihr sagt, das geht mit Delphi (vielleicht auch mit einer anderen Version), dann arbeite ich mich da rein. Aber ich möchte ungern ein spätes Erwachen und die Arbeit umsonst gemacht haben.

Delphi-Laie - Mo 12.04.10 15:07

---

AlmaChua hat folgendes geschrieben :

Delphi-Laie hat folgendes geschrieben : Dann mußt Du auf .Net verzichten und den Compiler, den du benutzt, so betreiben bzw. einstellen, daß er alles enthält, was benötigt wird und nicht auf jedem Windows vorhanden ist (Laufzeitpackages und Laufzeitbibliotheken integrieren). ja, ist das denn mit Delphi möglich? Oder muß ich mich da von vornherein woanders umsehen?

Nein, Du mußt Dich nicht woanders umsehen, und ja, es ist möglich. Delphi ist in allen mir bekannten Versionen sogar so voreingestellt, daß alles benötigte in die Exe-Datei eingebunden wird (insofern hatte ich mich weiter oben etwas mißverständlich ausgedrückt) - im Gegensatz z.B. zum C++-Builder, der kleine Exe-Dateien erzeugt, das böse Erwachen jedoch nach hinten auf einen anderen Computer schiebt (letzteres kann man aber auch so einstellen, daß dessen Compilate überall laufen). Die Delphi-Compilate mit allem Drum & Dran sind sogar etwas kleiner als die vom Builder. Wären da nicht die klitzekleinen und doch kompletten Exe-Dateien (auch die echten Exe-Dateien ohne .Net-Gedödel), die das Visual-Studio erzeugen kann, wäre die Welt sogar vollends in Ordnung.

AlmaChua hat folgendes geschrieben :

Also, ich finde da ja nichtmal den kompletten Quelltext. In der .pas-Datei sind wohl nur die Aktionen des Programms beschrieben. Die Beschreibung der Fenster habe ich bisher vergeblich gesucht. Bin - wie gesagt - ganz neu auf dem Gebiet der Fensterprogrammierung. In meinen C-Programmen war immer alles in einer Datei und natürlich werden da die Bibliotheksfunktionen beim Compilieren mit eingebunden.

Es gibt auch noch die Formulardateien, die die Objekteigenschaften zum Programmstart festhalten. Dann die zentrale Projektdatei, die aufgerufen wird und alles vereint. Hinzu kommen ggf. weitere Dateien, zum Zeitpunkt der Compilierung eingebundene, so z.B. Ressourcendateien, per inline eingebundene Quelltextdateien, Cursor- und andere Bilddateien usw. usfw. .

Das ganze Fensterrumgemache mit nur einem Quelltext hinzubekommen, wie Du es ja auch mal getan zu haben scheinst, ist aber eine verdammte Arbeit (nicht umsonst war z.B. Turbo-Pascal für Windows kein langer Erfolg beschieden, und auch sonst ist die Programmierung ohne die sog. Visual Component Library in Delphi einarbeitungsintensiv, aufwendig und langsam bzw. schwerfällig).

AlmaChua hat folgendes geschrieben :

Wenn Ihr sagt, das geht mit Delphi (vielleicht auch mit einer anderen Version), dann arbeite ich mich da rein. Aber ich möchte ungern ein spätes Erwachen und die Arbeit umsonst gemacht haben.

Ihr? Ich sage ja, es ist möglich. Allerdings ist .Net (leider?!) zumindest in der Welt der Redmonder Fenster der aktuelle Stand der Zeit und Softwaretechnologie.

acadam71 - Mo 12.04.10 15:25

---

Des langen Threads kurzer Sinn:
Kaufe Delphi 2010 (oder 2009 oder 2007) für Win32 und Du brauchst weder .net noch Java noch sonstwas.

Die erstellten Programme laufen schnell und stabil. Außerdem kenne ich keine schnellere Möglichkeit, einfache, fensterbasierende Software für Windows zu entwickeln als mit Delphi. Auch DB-Zugriffe inkl. Eingabe-Fenster innerhalb einer zweischichtigen Architektur sind in wenigen Minuten programmiert. Alles wozu Du in PHP viele Stunden benötigst (Daten aus DB holen zur HTML Seite an Text-Felder senden etc.), kannst Du in Delphi in wenigen Minuten erledigen :-).

Nochmal: Du benötigst "Delphi für Win32", das läuft ohne .net.

AlmaChua - Mo 12.04.10 15:59

---

Dankeschön. Danach werde ich mich umsehen. Es gibt so viele Versionen, daß ich da keinen Einblick habe.

acadam71 - Mo 12.04.10 16:07

---

Hier kannst Du Infos bzgl. Delphi OHNE .net bekommen (Delphi 2010):
http://www.embarcadero.com/products/delphi

Wenn du beides (MIT und OHNE .net) haben willst, dann hier (RAD Studio 2010):
http://www.embarcadero.com/products/rad-studio

Noch eine Info: Du benötigst für die IDE das .net Framework (auch für Delphi für Win32). Aber keine Angst: Deine mit Delphi erstellte exe läuft dann OHNE .net auf dem Rechner des Kunden.

AlmaChua - Mo 12.04.10 16:51

---

ja, ich selbst habe .net. Aber das will ich keinesfalls voraussetzen. Es gibt nichts Schlimmeres, als diese kryptischen Fehlermeldungen in Windows, daß irgendwas fehlt.

Delphi-Laie - Mo 12.04.10 17:21

---

AlmaChua hat folgendes geschrieben :

Es gibt nichts Schlimmeres, als diese kryptischen Fehlermeldungen in Windows, daß irgendwas fehlt.

Eine Meldung bezüglich des Fehlens irgendeiner DLL ist doch noch nicht kryptisch, weil diese ja klar benannt wird. Wenn allerdings in Wirklichkeit das gesamte .Net-Framework vorausgesetzt wird, ist eine solche Fehlermeldung .... gelinde formuliert ...... unzureichend und irreführend.

Viel schlimmer ist es, wenn irgendetwas nicht funktioniert, weil ein vorausgesetzter Dienst nicht gestartet wurde. Bedienergononie hat Mikroweich in diesem Falle bis heute nicht ansatzweise hinbekommen.

jfheins - Mo 12.04.10 20:11

---

Anwendungen, die mit Delphi 2009 oder neue kompiliert werden, laufen übrigens nicht mit Windows 9x ;)

Grundsätzlich ist es eine Geschmacksfrage, ob man damit leben kann, das .net framework vorauszusetzen. Ich persönlich kann das sehr gut, und ich programmiere nur noch mit .net (sofern ich es mir aussuchen kann).

AlmaChua - Mo 12.04.10 21:43

---

Macht das denn vom Programmieren her einen Unterschied?

jfheins - Mo 12.04.10 22:44

---

Ja - und wie ich finde einen ziemlich großen.
Es ist halt bei .net sehr viel dabei (ein grund, weshalb das Framework so groß ist) und man muss weniger Standardaufgaben selber machen. Zum Beispiel:
- Generics: Sind mittlerweile auch in Delphi Win32 angekommen. Man kann mit ihnen nichts machen, was man nicht auch ohne sie könnte, aber sie machen das Leben leichter. Ich deklariere eine Klasse Film und dann habe ich mit List<Film> eine Liste. Und wenn ich die Filme nach Genre strukturieren möchte kann ich auch eine Dictionary<Genre, List<Film>> deklarieren.
- GDI Plus: Bézier-Splines, Antialiasing, alles mit drin. Pfeile an den Enden einer Line gefällig? Mit drin. Was die Grafikfähigkeiten angeht, verweise ich mal auf Paint.net [http://www.getpaint.net/]
- LINQ: Etwas anspruchsvoller (min. .net 3.5) aber echt praktisch.
Man könnte hier noch weiter fortsetzen, aber ich glaube das muss nicht sein ;)
(Wenn du willst, kann ich dir auch ein kleines Demo-Programm zukommen lassen - so eine Art graphischer Grapheneditor)

Delphi-Laie - Mo 12.04.10 22:46

---

AlmaChua hat folgendes geschrieben :

Macht das denn vom Programmieren her einen Unterschied?

Bezüglich der Frage, ob echte oder nur vorcompilierte Exe erzeugt werden: Jein (mehr nein als ja). Die Programmiersprache C# ist das eine, wie mit dem Quelltexten umgegangen wird, ist das andere. Es ist kein Naturgesetz, daß aus diesem weiterentwickelten von C aus weiterentwickelten Dialekt zunächst nur Pseudo-Exe-Dateien, die auf dem Zielrechner noch zu compilieren sind, generiert werden.

Bezüglich der Frage, ob C# etwas anderes ist: Überwiegend Ja, denn es ist eine Weiterentwicklung (und nicht nur das) von C++.