Delphi am "Ende"?

[DeddyH]

Lisp? Ist das nicht dieses Dings mit den unwahrscheinlich vielen Klammern?

[mschaefer]

Das mit dem BPL-Konzept war mal ein Nachteil als die Datenträger zum ausliefern noch klein waren und man nicht das ganze Programmpaket ausliefern könnte. Heute würde ich sagen, bei einer neuen Version alles neu compileren auf DVD oder Web und das war es. Ist heute kein relvanter Nachteil mehr. Mir war nicht klar, as Lisp so populär ist.

Grüße in die Runde

[Assarbad]

Zitat:

Zitat von DeddyH (Beitrag 1073343)

Lisp? Ist das nicht dieses Dings mit den unwahrscheinlich vielen Klammern?

"I eat parentheses for breakfast" :mrgreen: -> http://www.youtube.com/watch?v=HM1Zb3xmvMc

Zitat:

Zitat von mschaefer (Beitrag 1073346)

Das mit dem BPL-Konzept war mal ein Nachteil als die Datenträger zum ausliefern noch klein waren und man nicht das ganze Programmpaket ausliefern könnte. Heute würde ich sagen, bei einer neuen Version alles neu compileren auf DVD oder Web und das war es. Ist heute kein relvanter Nachteil mehr.

Aber der Vorteil ist hin, wenn man doch wieder alles zusammen ausliefern muß, anstatt die sauber getrennten BPLs einzeln auszuliefern.

[BUG]

OT:

Zitat:

Zitat von Assarbad (Beitrag 1073347)

Zitat:

Zitat von DeddyH (Beitrag 1073343)

Lisp? Ist das nicht dieses Dings mit den unwahrscheinlich vielen Klammern?

"I eat parentheses for breakfast" :mrgreen: -> http://www.youtube.com/watch?v=HM1Zb3xmvMc

Kannst du das da beworbene Buch empfehlen?

[Assarbad]

OT:

Zitat:

Zitat von BUG (Beitrag 1073350)

Kannst du das da beworbene Buch empfehlen?

Ich bin derzeit in Kapitel 3, bisher ja. Frag mich in ein paar Wochen nochmal, dann bin ich vermutlich komplett durch. Habe schon drei Leute die es danach ausleihen wollen :mrgreen:

[DSCHUCH]

Zitat:

Zitat von Assarbad (Beitrag 1073347)

Aber der Vorteil ist hin, wenn man doch wieder alles zusammen ausliefern muß, anstatt die sauber getrennten BPLs einzeln auszuliefern.

also wir handhaben das so, das im svn immer der release-stand ist. wenn es rückwärtige updates in bpl gibt wird natürlich darauf geachtet das keine header geändert werden, dann reicht auch aus eine einzelne datei zu ändern. wer bpl oder sonstiges im windows-system ablegt, ist selbst schuld am chaos. ;o)

ausserdem muß wenn header geändert werden maximal das eigene zeug neu ausgeliefert werden, nicht aber sämtliche system-bpl oder drittkomponenten-bpl.

ok, also der nachteil ist eigentlich ein vorteil, wenn man weiß wie man es zu verwenden hat. ;o)

[newbe]

Solange die Macher von Delphi mit nun schon wirklich peinlicher Penetranz an den Bedürfnissen des Marktes (Multicore support, 64 Bit) und damit den Wünschen der Anwender vorbei Entwickeln/Releasen, werden solche Threads auch immer wieder aufkommen. Und das lieber Luckie ist mit Verlaub gesagt auch ligitim. Nur weil ein Thema bereits in anderen Threads behandelt wurde heisst das noch lange nicht, das ich keinen neuen Thread zum selben Thema erstellen darf.
(nur weil es bestimmten Leuten hier aus welchen Gründen auch immer net in den Kram passt)

Etwas anderes ist es natürlich, wenn EINE Person diverse Threads mit dem selben Thema innerhalb kurzer Zeit aufmacht.

mfg newbe

[DSCHUCH]

Zitat:

Zitat von newbe (Beitrag 1073378)

Solange die Macher von Delphi mit nun schon wirklich peinlicher Penetranz an den Bedürfnissen des Marktes (Multicore support, 64 Bit) und damit den Wünschen der Anwender vorbei Entwickeln/Releasen, werden solche Threads auch immer wieder aufkommen.

mfg newbe

irgendwie fehlt mir bei solchen aussagen etwas die differenzierung.

1) kann man problemlos threads mit delphi abbilden (multicore). ich weiß es gibt in .net nette sprachkonstrukte die das wesentlich vereinfachen - ich gehe aber davon aus das das noch kommen wird (will ich zumindest mal hoffen ^^).
2) benötigt man für die meisten gui-anwendungen weder 64 bit noch sonstwas (derzeit). natürlich wird das perspektivisch vom kunden erwartet, derzeit funktioniert allerdings nichtmal ms office richtig unter 64 bit mit allen interfaces. bzw es ist nicht abwärtskompatibel und somit nicht zu gebrauchen. von daher ist diese aussage "mit nun schon wirklich peinlicher Penetranz an den Bedürfnissen des Marktes...vorbei Entwickeln/Releasen" - entschuldige - lächerlich. (mal von dem ganzen treiber zirkus bei 64 bit abgesehen). problematisch ist hier eher - wie bereits mehrfach angesprochen - das keine belastbare aussage vorhanden ist wann das kommt.
http://www.chip.de/news/Office-2010-..._43428002.html
http://technet.microsoft.com/de-de/l.../ee681792.aspx
http://www.outlookforums.com/showthr...-2010-64-bit-R
3) wir beispielsweise verwenden delphi ausschliesslich für die frontendentwicklung. alles andere läuft über andere technologien ab, die dann mit delphi kommunizieren. unser backend läuft auf 64 bit, das frontend 32 (sicher wäre es nett wenn das von delphi mal käme. ;o) )

[mkinzler]

Für die reine GUI braucht man kein 64Bit, aber für:
-Pluginentwicklung Office
-speicherlastigen Anwendungen
-COM-Dienste
...

[Insider2004]

BPL ist nicht anderes als eine DLL. Also Finger weg, wenn man es nicht im Griff hat. D.h. abschalten bei den Projekt-settings.

Delphi 64 kommt im August.

[mkinzler]

Zitat:

Delphi 64 kommt im August.

Hoffen wir mal

[Bernhard Geyer]

Zitat:

Zitat von mkinzler (Beitrag 1073411)

Für die reine GUI braucht man kein 64Bit, aber für:
-Pluginentwicklung Office
-speicherlastigen Anwendungen
-COM-Dienste
...

- Plugins für CAD-Systeme (Diverse davon kündigen schon das EOF für die 32-Bit-Version an)
- Plugins für Windows Explorer
- Plugins für IE-64 (Ok, da hier noch Adobe pennt hat man noch etwas zeit)

Zitat:

Zitat von DSCHUCH (Beitrag 1073408)

... nichtmal ms office richtig unter 64 bit mit allen interfaces. bzw es ist nicht abwärtskompatibel und somit nicht zu gebrauchen.
...
http://technet.microsoft.com/de-de/l.../ee681792.aspx
...

Hier steht nicht das MS Office 64-Bit nicht richtig funktioniert. Es steht da das es viele Plugins/Extension gibt die nicht als 64-Bit-Version funktionieren (vermutlich sind auch einige davon mit Delphi entwickelt).
Wenn man über COM/OLE Automation geht stört es nicht wenn die 64-Bit Version installiert ist.

Zitat:

Zitat von mkinzler (Beitrag 1073416)

Zitat:

Delphi 64 kommt im August.

Hoffen wir mal

Welchs Jahr :-)

[Assarbad]

Zitat:

Zitat von DSCHUCH (Beitrag 1073408)

1) kann man problemlos threads mit delphi abbilden (multicore). ich weiß es gibt in .net nette sprachkonstrukte die das wesentlich vereinfachen - ich gehe aber davon aus das das noch kommen wird (will ich zumindest mal hoffen ^^).

Thread == Thema, im Kontext eines Forums. Da war keinerlei Aussage zu Threads (wie: parallele Ausführung) in Delphi enthalten.

Zitat:

Zitat von DSCHUCH (Beitrag 1073408)

(mal von dem ganzen treiber zirkus bei 64 bit abgesehen)

Wo siehst du da ein Problem?

Zitat:

Zitat von DSCHUCH (Beitrag 1073408)

3) wir beispielsweise verwenden delphi ausschliesslich für die frontendentwicklung. alles andere läuft über andere technologien ab, die dann mit delphi kommunizieren. unser backend läuft auf 64 bit, das frontend 32 (sicher wäre es nett wenn das von delphi mal käme. ;o) )

Heißt das, daß ihr eine Shellerweiterung künstlich zu dem Backend zählt, um gleichzeitig die Macher von Delphi verteidigen zu können und Kunden mit x64 bedienen zu können? :zwinker:

Zitat:

Zitat von Bernhard Geyer (Beitrag 1073422)

Zitat:

Zitat von mkinzler (Beitrag 1073416)

Zitat:

Delphi 64 kommt im August.

Hoffen wir mal

Welchs Jahr :-)

Voraussichtlich noch in einem mit ner "2" vorn. Und jetzt frag nicht wieviele Stellen!!! :mrgreen:

[Robotiker]

Zitat:

Zitat von DSCHUCH (Beitrag 1073408)

1) kann man problemlos threads mit delphi abbilden (multicore). ich weiß es gibt in .net nette sprachkonstrukte die das wesentlich vereinfachen - ich gehe aber davon aus das das noch kommen wird (will ich zumindest mal hoffen ^^).

Handgemachte Threads sind kein Thema. Aber die Entwicklung geht weiter, soll sich das Programm automatisch an die Anzahl der Kerne (und das werden zukünftig viele sein) anpassen, braucht man da mehr Logik. Das habe ich in diesem Beitrag gemeint:
http://www.delphipraxis.net/1073199-post153.html

In C++ gibt es dafür z.B. OpenMP, das wird von den meisten Compilern unterstützt, aber natürlich nicht vom C++ Builder.

In der Roadmap steht etwas von "Support for parallelization in the RTL" bei Commodore. Das könnt eine Antwort auf Microsofts Concurreny Runtime sein.
http://msdn.microsoft.com/de-de/library/dd504870.aspx
Nur sind die wohl mal wieder früher dran und mit mehr Manpower unterwegs.

[cookie22]

Zitat:

Zitat von DSCHUCH (Beitrag 1073408)

2) benötigt man für die meisten gui-anwendungen weder 64 bit noch sonstwas (derzeit). natürlich wird das perspektivisch vom kunden erwartet, derzeit funktioniert allerdings nichtmal ms office richtig unter 64 bit mit allen interfaces. bzw es ist nicht abwärtskompatibel und somit nicht zu gebrauchen. von daher ist diese aussage "mit nun schon wirklich peinlicher Penetranz an den Bedürfnissen des Marktes...vorbei Entwickeln/Releasen" - entschuldige - lächerlich. (mal von dem ganzen treiber zirkus bei 64 bit abgesehen). problematisch ist hier eher - wie bereits mehrfach angesprochen - das keine belastbare aussage vorhanden ist wann das kommt.
http://www.chip.de/news/Office-2010-..._43428002.html
http://technet.microsoft.com/de-de/l.../ee681792.aspx
http://www.outlookforums.com/showthr...-2010-64-bit-R

Ich arbeite im Bereich Desktop-Anwendungen und wir brauchen den 64-Bit Compiler schon seit Jahren. Sinnvoll oder nicht, es gibt nunmal die 64-Bit Systeme und die Kunden verlangen 64-Bit Software. Hat man diese nicht oder funktionieren Programmteile nicht unter 64-Bit, kauft der Kunde wo anders.

Es ist nicht mal möglich eine einfache Shell Extension für 64-Bit zu erstellen und eine Shell Extension ist nun wirklich nichts abgedrehtes.

[DSCHUCH]

îch gebe euch ja im prinzip recht, natürlich fehlt hier noch ein ganzes stück. allerdings fehlt mir ein wenig wertschätzung dessen, was doch in den letzten 2 jahren passiert ist. das ist nämlich mehr, als in den 7 jahren zuvor, im prinzip hat sich seit delphi5-2009 nichts wirklich getan bzw. nur chaos gegeben, da sieht man jetzt nun doch endlich wieder etwas licht am horizont.
und das der compiler, welcher im großen und ganzen einen 10 jahre alten stand hat, schwierigkeiten macht weiter oder besser gesagt neuzuentwickeln, sollte klar sein. ^^
ich sage es mal so - müßte ich neu entscheiden, würde ich derzeit wahrscheinlich auch vor delphi abgeschreckt sein. aber im moment habe ich hoffnung das es wieder besser wird. ;o)

ps: das mit dem thread war gut. ^^

[cookie22]

Zitat:

Zitat von DSCHUCH (Beitrag 1073538)

îch gebe euch ja im prinzip recht, natürlich fehlt hier noch ein ganzes stück. allerdings fehlt mir ein wenig wertschätzung dessen, was doch in den letzten 2 jahren passiert ist. das ist nämlich mehr, als in den 7 jahren zuvor, im prinzip hat sich seit delphi5-2009 nichts wirklich getan bzw. nur chaos gegeben, da sieht man jetzt nun doch endlich wieder etwas licht am horizont.
und das der compiler, welcher im großen und ganzen einen 10 jahre alten stand hat, schwierigkeiten macht weiter oder besser gesagt neuzuentwickeln, sollte klar sein. ^^
ich sage es mal so - müßte ich neu entscheiden, würde ich derzeit wahrscheinlich auch vor delphi abgeschreckt sein. aber im moment habe ich hoffnung das es wieder besser wird. ;o)

ps: das mit dem thread war gut. ^^

Gut es ist was passiert in den letzten zwei Jahren, aber das ist viel zu wenig. Am meisten stört mich die schlechte Wartung. Man bekommt wenn man Glück hat, 2-3 Hotfixes hingeschmissen und das war es dann mit Bug-Fixing. Das ist einfach zu dünn. Naja wurde ja auch schon oft genug gesagt.

Emba sollte lansam wissen was zu tun ist.

[QuickAndDirty]

Ich frage mich ob der Herr Eißner(oder so)....jetzt den versprochenen 64 Compiler aus dem Hut ziehen kann.
Zieht er überhaupt irgendwelche Konsequenzen aus dem, von ihm so dringend verlangte Beleg das für 2008 ein 64 Bit Compiler angekündigt war? Wenn ja, welche? Wenn nein, was sollte dann das penetrante verlangen eines Beleges wo sich doch alle noch recht gut dran erinnern?

Irgendwie ist es ja auch ziemlich albern erst die Ankündigung auf der eigenen Seite zu löschen, dann zu behaupten das es die Ankündigung nie gegeben hätte und doch bitte Belege für die Existenz dieser Ankündigung einzufordern...als wenn man da haus intern nicht die besseren Möglichkeit hätte das mal eben nachzuprüfen...

Ich bin gespannt auf die Reaktion, nach dem die Existenz der Ankündigung aus Fachzeitschriften noch belegbar ist....

Wunsch ist Wunsch....

[bernau]

Was wird hier die ganze Zeit über BPLs geschrieben? Es macht (für mich) keinen Sinn mehr, BPLs auszuliefern. Alles kommt in die EXE-Datei. Eine EXE ohne BPL ist das Pflegeleichteste was es gibt. Bei den heutigen Übertragungsraten ist es doch Wurst, ob ich 10MB oder 50MB ausliefern muss. Oder? Oder welchen Grud gibt es bei euch noch, weshalb BPLs verwendet werden?

[DSCHUCH]

Zitat:

Zitat von bernau (Beitrag 1073585)

Was wird hier die ganze Zeit über BPLs geschrieben? Es macht (für mich) keinen Sinn mehr, BPLs auszuliefern. Alles kommt in die EXE-Datei. Eine EXE ohne BPL ist das Pflegeleichteste was es gibt. Bei den heutigen Übertragungsraten ist es doch Wurst, ob ich 10MB oder 50MB ausliefern muss. Oder? Oder welchen Grud gibt es bei euch noch, weshalb BPLs verwendet werden?

naja - bei kleinen programmen vielleicht. du kannst das ja mal in einem großen netzwerk mit 50-100 AST probieren. von den ladezeiten, speicherverbrauch wenn immer alle module geladen sind usw mal abgesehen. ;o)

und von der wartung ebenso. man müßte ja jedesmal alles ändern bzw updaten, nur wenn in einem formular ein label falsch wäre. omg. ^^

[QuickAndDirty]

Ohne BPL kann man Komponenten wohl nicht in die IDE integrieren...deswegen kommen die ständig zum Einsatz!

[Assarbad]

Zitat:

Zitat von bernau (Beitrag 1073585)

Bei den heutigen Übertragungsraten ist es doch Wurst, ob ich 10MB oder 50MB ausliefern muss. Oder?

Auf dem deutschen Markt vielleicht weitgehend ... obwohl du auch da einige finden wirst die noch ohne DSL vor sich hindümpeln. Ich weiß, es ist bequem diese Annahme zu treffen, auch hier in Island. Bspw. ist alles rund um Reykjavík wunderbar schnell angebunden - ADSL, Glasfaser ... alles an vielen Stellen verfügbar. Aber die kleineren Ortschaften (und im Vergleich zu Deutschland ist alles außer Reykjavík selbst in dt. Maßstäben nur eine Stadt oder ein Dorf/Dörfchen, nichtmal Großstadt) im Osten und Nordwesten und anderen abgelegeneren Gebieten haben es da nicht so gut. Selbst wenn es nur eine wackelige ISDN-Verbindung ist, man muß es wissen und muß sich darauf einrichten (hatten da im letzten Jahr einen Kunden in Ostisland der Probleme hatte wg. der Downloadgrößen). Weltweit gesehen wird es eher schlimmer.

Zugegebenermaßen hängt es auch davon ab was genau dein Programm tut.

Zitat:

Zitat von DSCHUCH (Beitrag 1073593)

in einem großen netzwerk mit 50-100 AST

Ich bin ratlos. Kannst du mich aufklären was AST ist/sind?

[hanspeter]

Zitat:

Zitat von bernau (Beitrag 1073585)

Was wird hier die ganze Zeit über BPLs geschrieben? Es macht (für mich) keinen Sinn mehr, BPLs auszuliefern. Alles kommt in die EXE-Datei. Eine EXE ohne BPL ist das Pflegeleichteste was es gibt. Bei den heutigen Übertragungsraten ist es doch Wurst, ob ich 10MB oder 50MB ausliefern muss. Oder? Oder welchen Grud gibt es bei euch noch, weshalb BPLs verwendet werden?

Wenn ich z.B. Hydra von Remobjects verwende.
Es ist fast die einzige Möglichkeit, um von Net auf Delphi zugreifen zu können.
Wenn ich dll , egal ob eigene oder zugekaufte verwenden will, muß ich das Laufzeitsystem als BPL ausliefern.
Jedes Modul, was Registerclass verwendet, kann nur einmal eingebunden werden.
dll benötige ich, wenn bestimmte Routinen auch in anderen Sprachen eingebunden werden sollen.
Wenn ich das gleiche Programmsystem in unterschiedlichen Konfigurationen ausliefern will.
Es ist schon ein Unterschied ob ich 10Mbyte oder 300 mbyte wegen einer Änderung ausliefere.
Das ganze dann auf 10 bis 20 Computern installiert werden muss.
Und dann gibt es eine XYZ.BPL für Programm A, eine für Programm B u.s.w.
TMS Software z.B. bläst die Exe um ca. 15 Mbyte auf.
Es gibt seit Jahren bessere Technologien. Das BPL Konzept besteht seit Delphi 2 oder 3 und wird mit jeder Version nur inkompatibel gemacht.
Da es sich um ein hauseigenes Format von Emb. handelt, wäre es sicher kein unüberwindbares Problem, BPL in einem BPL-Cache über eine Signatur zu identifizieren.

Bei uns hat ein AZUBI mal gleichnamige BPL in einem Verzeichnis zusammengefasst. (Gleicher Name, gleiche Größe)
Ich habe 7 Programme neu installieren müssen.

Gruß
Peter

[Assarbad]

Zitat:

Zitat von hanspeter (Beitrag 1073600)

Es gibt seit Jahren bessere Technologien. Das BPL Konzept besteht seit Delphi 2 oder 3 und wird mit jeder Version nur inkompatibel gemacht.
Da es sich um ein hauseigenes Format von Emb. handelt, wäre es sicher kein unüberwindbares Problem, BPL in einem BPL-Cache über eine Signatur zu identifizieren.

Inkompatibel sind "nur" die Klassen (wg. der Vtables, soweit mir bekannt). Aber hast schon recht, da ließe sich sicher etwas drehen. Bspw. könnte man in den Ressourcen auch die Info unterbringen zu welcher Version es kompatibel ist ... obwohl, mit DVCLAL gib't das ja sogar schon :stupid:

[bernau]

Zitat:

Zitat von QuickAndDirty (Beitrag 1073595)

Ohne BPL kann man Komponenten wohl nicht in die IDE integrieren...deswegen kommen die ständig zum Einsatz!

Habe Fremdkomponenten und eigene Komponenten in der IDE. Dennoch wird daraus eine EXE.


@Alle anderen: OK. Ihr habt recht. Habe nur Kunden mit DSL. Meine Software ist "nur" 15MB groß. Obwohl es mittlerweile 500.000 Zeilen Quellcode umfasst. Liegt aber auch vieleicht daran, daß ich nur wenige Fremdkomponenten verwende. Wenn möglich schreibe ich Komponenten selber. Ist zwar erst mal mehr Auffwand. Doch dafür bin flexibel in der evtl. benötigten Erweiterung.

[DSCHUCH]

Zitat:

Zitat von Assarbad (Beitrag 1073596)

Zitat:

Zitat von DSCHUCH (Beitrag 1073593)

in einem großen netzwerk mit 50-100 AST

Ich bin ratlos. Kannst du mich aufklären was AST ist/sind?

arbeitsstationen. das deutsche wort für client. ;o)

[QuickAndDirty]

Zitat:

Zitat von bernau (Beitrag 1073610)

Zitat:

Zitat von QuickAndDirty (Beitrag 1073595)

Ohne BPL kann man Komponenten wohl nicht in die IDE integrieren...deswegen kommen die ständig zum Einsatz!

Habe Fremdkomponenten und eigene Komponenten in der IDE. Dennoch wird daraus eine EXE.

Sicher ! ich mache immer eine Vollständig alle Packages enthaltende exe...aber die IDE lädt die Packages zur Laufzeit und baut so die Komponenten-Toolbar auf.

Wie außer mit Packages würdest du das machen?
Ich würde es vermutlich über ne art ComServerBridge-Dll machen die dann die RTTI Informationen
ausliest und so den Objektinspektor füllt. Anhand der dortigen Informationen dann eben Dummy Objekte auf Dummy Formulare legt damit man etwas designen kann....evtl könnte man ja auch die Paint Operationen zur Designzeit durch COM tunneln.

Aber mit BPL geht es ja auch.

[bernau]

Zitat:

Zitat von QuickAndDirty (Beitrag 1073630)

Sicher ! ich mache immer eine Vollständig alle Packages enthaltende exe...aber die IDE lädt die Packages zur Laufzeit und baut so die Komponenten-Toolbar auf.

Wie außer mit Packages würdest du das machen?
Ich würde es vermutlich über ne art ComServerBridge-Dll machen die dann die RTTI Informationen
ausliest und so den Objektinspektor füllt. Anhand der dortigen Informationen dann eben Dummy Objekte auf Dummy Formulare legt damit man etwas designen kann....evtl könnte man ja auch die Paint Operationen zur Designzeit durch COM tunneln.

Aber mit BPL geht es ja auch.

Verstehe jetzt nicht worauf du hinaus willst. Meine Aussage ist doch nur, daß das Programm beim Enduser als eine EXE landet. In der IDE verwende ich die Packages, in der die Komponenten sind. Was hat das nun mit den BPLs beim Kunden zu tun?

[Assarbad]

Zitat:

Zitat von DSCHUCH (Beitrag 1073617)

arbeitsstationen. das deutsche wort für client. ;o)

Danke :thumb:

[QuickAndDirty]

Zitat:

Zitat von bernau (Beitrag 1073636)

Zitat:

Zitat von QuickAndDirty (Beitrag 1073630)

Sicher ! ich mache immer eine Vollständig alle Packages enthaltende exe...aber die IDE lädt die Packages zur Laufzeit und baut so die Komponenten-Toolbar auf.

Wie außer mit Packages würdest du das machen?
Ich würde es vermutlich über ne art ComServerBridge-Dll machen die dann die RTTI Informationen
ausliest und so den Objektinspektor füllt. Anhand der dortigen Informationen dann eben Dummy Objekte auf Dummy Formulare legt damit man etwas designen kann....evtl könnte man ja auch die Paint Operationen zur Designzeit durch COM tunneln.

Aber mit BPL geht es ja auch.

Verstehe jetzt nicht worauf du hinaus willst. Meine Aussage ist doch nur, daß das Programm beim Enduser als eine EXE landet. In der IDE verwende ich die Packages, in der die Komponenten sind. Was hat das nun mit den BPLs beim Kunden zu tun?

Oh. Ich habe das so wahrgenommen das hier BPLs und die bloße Existenz des Konzepts im allgemeinen schon als murks an gesehen werden. Und dem wollte ich nur entgegen halten das ich das recht praktisch finde um z.B. Komponenten auszuliefern....
Ich würde ne Anwendung auch nie mit BPL oder DLL ausliefern wenn ich alles zusammen kompilieren kann...ist doch irgendwie selbstverständlich.

[bernau]

Zitat:

Zitat von QuickAndDirty (Beitrag 1073647)

Oh. Ich habe das so wahrgenommen das hier BPLs und die bloße Existenz des Konzepts im allgemeinen schon als murks an gesehen werden. Und dem wollte ich nur entgegen halten das ich das recht praktisch finde um z.B. Komponenten auszuliefern....
Ich würde ne Anwendung auch nie mit BPL oder DLL ausliefern wenn ich alles zusammen kompilieren kann...ist doch irgendwie selbstverständlich.

Na dann sind wir ja einer Meinung ;-)

[Martin]

Zitat:

Zitat von QuickAndDirty (Beitrag 1073578)

Ich bin gespannt auf die Reaktion, nach dem die Existenz der Ankündigung aus Fachzeitschriften noch belegbar ist....

Hier auch: http://www.delphi-treff.de/news/news...s/article/403/ (vom 21.6.2007!)

Gruß, Martin

[vagtler]

Und wer noch einmal einen Blick auf die am selben Tag veröffentlichte Roadmap werfen möchte: http://web.archive.org/web/200710100.../article/36620

Wäre übrigens schön, wenn sich auch Matthias noch mal an diesem Thread beteiligen würde.

btw: In unserem Haus ist übrigens Ende letzten Jahres endgültig die Entscheidung gefallen, kein Update auf Delphi XE oder folgende Versionen mehr mitzumachen. Die zukünftigen Versionen unserer Kernprodukte werden jetzt in C# entwickelt - das bedeutet wieder 25 Lizenzen weniger für Embarcadero...

[pertzschc]

Zitat:

Zitat von vagtler (Beitrag 1073991)

Die zukünftigen Versionen unserer Kernprodukte werden jetzt in C# entwickelt - das bedeutet wieder 25 Lizenzen weniger für Embarcadero...

Wäre mal interessant, wie ihr die Migration auf C# durchführt - kannst Du berichten? Was sind die Hauptentscheidungsgründe gewesen?

Gruß,
Christoph

[BUG]

Zitat:

Zitat von pertzschc (Beitrag 1074016)

Wäre mal interessant, wie ihr die Migration auf C# durchführt - kannst Du berichten? Was sind die Hauptentscheidungsgründe gewesen?

Könnte mir vorstellen, das dass gut als eigenes Thema sinnvoll sein würde, à la "Erfahrungsbericht Migration Delphi auf C#".
In diesem Thema hier würde es sicher irgendwie untergehen.

[vagtler]

Zitat:

Zitat von pertzschc (Beitrag 1074016)

Wäre mal interessant, wie ihr die Migration auf C# durchführt - kannst Du berichten? Was sind die Hauptentscheidungsgründe gewesen? [...]

Migration wird es keine geben - es wird ein kompletter Rewrite werden. Wir werden von einer Fat-Client-Lösung komplett auf eine Web-Applikation wechseln.

Genau genommen arbeiten wir auch schon seit einigen Jahren in C#, so dass wir da auch schon einige Erfahrungen vorweisen können.

Entscheidungsgründe waren u.a.

• Investitionssicherheit, die bei dem sprunghaften Verhalten (und ja, dazu gehören auch nicht belastbare Roadmaps) seitens Embarcadero einfach nicht mehr gegeben ist
  
• Arbeitsmarkt - (gute) C#-Entwickler sind mittlerweile definitiv einfacher zu finden
  
• Produktivität - durch moderneres Framework und leistungsfähigere IDE kommen unsere C#-Entwickler schneller zu produktiv einsetzbaren Lösungen
  
• Qualität, Test- und Wartbarkeit - durch entsprechendes Tooling unterstützt erreichen unsere .NET-Produkte mittlerweile eine höhere quantifizierbare(!) Qualität als ihre Delphi-Pendants
  
• Weiterbildung - Dozenten für Mitarbeiterschulungen im .NET-Bereich gibt es wie Sand am Meer, von Literatur zu Selbststudienzwecken ganz zu schweigen
  
• ...und nicht zuletzt ist die Unterstützung durch die Community mittlerweile enorm - kaum ein Thema oder Problem im .NET.Bereich, zu dem es nicht mindestens einen Blog-Beitrag gibt

[Stevie]

Zitat:

Zitat von QuickAndDirty (Beitrag 1073647)

Ich würde ne Anwendung auch nie mit BPL oder DLL ausliefern wenn ich alles zusammen kompilieren kann...ist doch irgendwie selbstverständlich.

Genau, Windows besteht ja auch aus einer großen Datei... oh halt, es sind viele kleine Bibliotheken. Bei nem kleinen Tool gebe ich dir Recht, da isses irgendwie über, statt einer Exe Duzende von Dateien auszuliefern (die in der Summe wahrscheinlich sogar größer wären als eine exe). Aber bei einen großen komplexen Anwendung mit hunderten von Modulen, wo Austauschbarkeit einzelner Teile gewünscht ist, sind bpls/dlls unumgänglich.
Warum kann man auch in .Net wohl mit Assemblies arbeiten? Weil man alles in eine Exe packen will? Wohl kaum, gell?

Stichwort Migration: Viele stellen sich das so einfach vor, klar mal ebend nen Delphi Programm auf C# migrieren... wenn's sonst nix is :P Warum läuft wohl noch so viele Software auf Cobol und Co? Weil's ma ebend auf C# und Co migriert werden kann? ;)

[Question_mark]

Hallo,

Zitat:

Zitat von vagtler

Wäre übrigens schön, wenn sich auch Matthias noch mal an diesem Thread beteiligen würde.

Muss er nicht unbedingt, aber die eher abrupte Enthaltsamkeit von Matthias zu diesem Thema spricht doch ganze Bände ... Da sind wohl irgendwie die Argumente ausgegangen :zwinker:

Oder Mättes läuft jetzt mit einem Maulkorb von Embarcadingsbumms herum.

Um dann mal wieder zum Thema zurück zu kommen :

Delphi ist noch nicht am Ende, obwohl Emba aufgrund falschem und inkonsequentem Marketing fleissig am eigenen Untergang bastelt. Ich weiss nicht warum, vielleicht müssen auch erst die Leichen, die CodeGear hinterlassen hat, aus dem Keller geräumt werden.
Eigentlich werden doch hier im Forum alle Wünsche der Delphi-User an das Produkt klar und deutlich vorgetragen, warum wird das vom Produktmanagement völlig ignoriert ?

Und warum werden Aussagen aus Anno 2007/2008 von Emba zum 64-Bit Compiler heute verleugnet ?
Wobei ich gerade überlege, ob diese Aussage von CodeGear oder von Emba stammt ? Also vielleicht doch eine Leiche aus dem CodeGear Keller.

Ich persönlich hoffe, das es in Zukunft auch noch ein Delphi 2020 geben wird, aber das wird nur von Emba abhängen. Zum Beispiel fehlt eine Version Delphi Turbo Professional XE (analog zum ehemaligen Pendant zum Delphi 2006), da habe ich die Lizenzen wie warme Brötchen gekauft.

In diesem Sinne, schauen wir dann mal gebannt auf die die nächsten Entscheidungen der Marketingabteilung, der ich in Zukunft ein besseres Händchen bei Ihren Entscheidungen wünsche ...

Gruß

Question_mark

[Assarbad]

Zitat:

Zitat von Question_mark (Beitrag 1074064)

Und warum werden Aussagen aus Anno 2007/2008 von Emba zum 64-Bit Compiler heute verleugnet ?
Wobei ich gerade überlege, ob diese Aussage von CodeGear oder von Emba stammt ? Also vielleicht doch eine Leiche aus dem CodeGear Keller.

Siehe Link zum Internetarchiv oben. Stammt noch von Codegear.

[Question_mark]

Hallo,

Zitat:

Zitat von Assarbad

Stammt noch von Codegear.

Ich war mir nicht ganz sicher, aber das hatte ich mir schon gedacht...

Also mal einen Minuspunkt aus dem Emba Gedöns auslöschen, es ist nicht so einfach Leichen aus fremden Kellern zu entfernen ...

Gruß

Question_mark