Delphi XE2 Update ist erschienen

[Bernhard Geyer]

Zitat von Insider2004:

Das kann ich nur bestätigen. Letztendlich ruft der IA den MSI auf. Und der ist vom Niveau her auf der Höhe vom DocExplorer.

Wäre es nicht sinnsvoll wenn Embar-Dingsbums auf Inno Setup umstellen würde? MSI ist ja nicht mehr nötig für den "Designed for" Aufkleber und man hätte (wenn man den Entwickler hilft) auch eine 64-Installer "aus eigenem Haus".

[jaenicke]

Bei InnoSetup muss man aber sehr viel selbst machen was MSI schon direkt kann. Nachladen von Dateien geht nur per Plugin, transaktionsbasierte Installationen existieren nicht, Patches gibt es auch nicht, registrieren von Systemkomponenten gehen nur per normalem Ausführungsbefehl ohne Fehlerbehandlung, ...

Für kleinere Programme oder Programme, die nicht großartig im System registriert werden müssen, nutze ich InnoSetup auch gerne, aber für die Installation von Delphi halte ich es für in keinster Weise geeignet...

[Bernhard Geyer]

Zitat von jaenicke:

... transaktionsbasierte Installationen existieren nicht ...

AFAIK hat man das doch mit IA aufgegeben um von den 2-3 Stunden der IS-Installationsdauer auf < 10 Minuten runter zu kommen.
Und wenn man die IDE irgendwann mal wieder .NET-Frei und auch ohne abhängigkeiten zu C#/J# hinbekommt (ist den J# in der SDK-Version noch nötig?) würde die Installation auch eigentlich ziemlich einfach werden. Systemkompos liefert die Delphi-IDE eh nicht, Direkte Uploads könnte ja Emba-Dingsbums mitentwicklen und eine Diff-Updater sollte auch nicht zu kompliziert sein.

[Insider2004]

Zitat von Bernhard Geyer:

Und wenn man die IDE irgendwann mal wieder .NET-Frei und auch ohne abhängigkeiten zu C#/J# hinbekommt (ist den J# in der SDK-Version noch nötig?) würde die Installation auch eigentlich ziemlich einfach werden.

Leider ist die IDE immer noch .net/j# verseucht. Ein Unding in Zeiten von Cross-Platform-Programmierung!

[mkinzler]

Zitat:

Ein Unding in Zeiten von Cross-Platform-Programmierung!

Die IDE ist windows-only und wird es vorerst wohl auch bleiben.
Der .Net-Teil ist auch nicht die IDE selber sondern die Together-Integration ( eigentlich ja in Java geschrieben)

[Insider2004]

Zitat von mkinzler:

Zitat:

Ein Unding in Zeiten von Cross-Platform-Programmierung!

Die IDE ist windows-only und wird es vorerst wohl auch bleiben.
Der .Net-Teil ist auch nicht die IDE selber sondern die Together-Integration ( eigentlich ja in Java geschrieben)

Ja weils anders auch gar nicht geht. siehe zitat oben.
Nicht nur together brauch j#/.net. Auch andere Teile sind voll abhängig (project-verwaltung, build-system). Da hat sich EMB ganz schön in die Scheisse geritten. Jetzt kommen sie auf Jahre nicht weg. Es wird somit ewig keine IDE für Mac und Linux geben.

[mkinzler]

Man müsste nur statt J# auf IKVM setzen. Dies gibt es auch für Mono und wäre damit portabel. Aber die IDE setzt nunmal auf die VCL, die nunmal mit der Zeit so sehr mit der klassischen WinAPI verwoben ist, dass sie praktisch nicht portierbar ist ( höchstens man verwendet einen Ansatz wie bei Kylix und emuliert diese per WineLib)

[himitsu]

OK, abgesehn vom Debugger könnte man die IDE bestimmt auch in WINE laufen lassen. (jedenfalls ohne diese ganzen j#- und .net-Abhängigkeiten)

[Bernhard Geyer]

Zitat von mkinzler:

Der .Net-Teil ist auch nicht die IDE selber sondern die Together-Integration ( eigentlich ja in Java geschrieben)

Da J# als SDK-Element von MS abgekündigt ist sollte Embaracadero folgen und das auch rausschmeißen. Wenn die Firma die Borland gekauft hat das nicht auf moderne Fuße stellen kann (.NET 4 und neuer lassen grüßen) hat das in einer IDE nix mehr zu suchen. Hier sollte Embaracadero mittels Delphi.Prism-Technik doch wohl eine zukunftsfähigere Integration hin bekommen.

[jbg]

Zitat von Bernhard Geyer:

Hier sollte Embaracadero mittels Delphi.Prism-Technik doch wohl eine zukunftsfähigere Integration hin bekommen.

Und wer sollte den ganzen Together Java-Gurscht übersetzen? Das haben sie doch schon beim Umstellen auf .NET nicht nach C# umgeschrieben und deswegen auf J# gesetzt.