Delphi XE3?

[mjustin]

Zitat von Robotiker:

Scheint als gibt es da noch ein paar unerzählte Teile der Geschichte.

Allen Bauer gab im zitierten Thread auch dieses Fazit:

Zitat:

Until we can get past that, targeting WinRT isn't actually possible from a deliverable product sense.
We are able to build WinRT applications with Delphi that work with a developer certificate, however they all fail the application qualification checks because of the aforementioned (an other) APIs.

• Für (natives) WinRT kann man, solange diese technischen Hürden bestehen, kein Produkt liefern
• Mit einem Entwicklerzertifikat kann man zwar eine WinRT Anwendung erstellen, die lokal mit einem Entwicklerzertifikat arbeitet, aber die WinRT App besteht nicht den Aufnahmetest für den Windows Store

Der zweite Punkt bedeutet auch: im Intranet (ohne Windows Store) ist die Verteilung einer mit Delphi erstellten WinRT Anwendung nur möglich, wenn auf jedem Computer ein Entwicklerzertifikat installiert ist.

Diese Möglichkeit wurde im September 2011 auf Stackoverflow bereits beschrieben:

How to Distribute Compiled Windows 8 Metro Applications without Windows Store?

Zitat:

Each machine that wants to install the application will need a developer license.

Also:
Jeder Computer, auf dem die App installiert werden soll, benötigt eine Entwicklerlizenz.

[MEissing]

Zitat von greenmile:

Ohoh das wird teuer.

Selbst ich kenne die Preise noch nicht....

....aber schön, dass man schon FUD lesen kann. Besonders einfallsreich ist der aber nicht

[Darlo]

Zitat von MEissing:

Zitat von greenmile:

Ohoh das wird teuer.

Selbst ich kenne die Preise noch nicht....

....aber schön, dass man schon FUD lesen kann. Besonders einfallsreich ist der aber nicht

Ich gehe ebenfalls davon aus dass es teurer wird (ist ja einfach ein Produkt mehr dass man lizenzieren muss). Wenn die angedeuteten Funktion kommen bin ich jedoch echt " " auf das Mobile Studio

[himitsu]

Es ist ja nicht so, daß ich die LiveBindings schlecht finde ... die sind bestimmt ganz praktisch und die graphischen sind mit Sicherheit auch noch übersichtlicher (falls man nicht zuviel auf einer Form drauf hat).

Aber in so alteingesessenen und über jahrzehnte gewachsenen Projekten ist ein bissl Logic jetzt schon in der GUI (also in den EventHandlern), dann gammelt welche in ein paar Klassen rum (hoffentlich auch logisch zusammenhängend), Einiges befindet sich in irgendwelchen Datenbankfunktionen, Unzähliges verteilt sich wirre in unüberschaubaren Triggern (auch schonmal mehrere Trigger, welche auf das Selbe reagieren) und das was mehrfach an sowas wie AfterScoll, AfterInsert, AfterPost, BeforPost und seinen Freunden hängt, will ich lieber nicht denken.
Da sieht man doch jetzt schon kaum noch wer durch.

Und nun gibt es eine neue Stelle, wo man nach weiteren Funktionen und Abhängigkeiten suchen muß.

[Robotiker]

Zitat von mjustin:

Allen Bauer gab im zitierten Thread auch dieses Fazit:

In einem anderen Thread hat er übrigens noch gesagt

Zitat:

I never said they are actively blocking access to third-parties. I don't think they are maliciously excluding third-parties. "Do not attribute malice to that which can be described by mere ignorance or incompetence."

Es scheint technisch auch mehr ein Problem der Zertifizierung von Apps für den Shop zu sein, keine Sonderbehandlung der VC++ RTL durch das Betriebssystem.


Bei den andere technischen Schwierigkeiten mit der API, die Allen Bauer da beschreibt, frage ich mich allerdings, warum man das erst jetzt offen diskutiert. Ich kann mich noch erinnern, dass ich letztes Jahr mit FireMonkey im C++ Builder gespielt habe und wenig später die Videos von der Build-Konferenz über WinRT gesehen habe. Mein erster Eindruck war "Das passt von der Architektur nicht wirklich gut zusammen", kann sein, dass ich das damals hier sogar schon mal geschrieben habe, als über FireMonkey diskutiert wurde.

Für Interessierte hier mal eine aktuelle Beschreibung, wie native WinRT Apps gebaut werden. In der Xaml-Variante, nicht in der DirectX-Variante, die FireMonkey wohl benutzen würde:
http://blogs.msdn.com/b/vcblog/archi.../10343401.aspx

[greenmile]

Zitat von MEissing:

Zitat von greenmile:

Ohoh das wird teuer.

Selbst ich kenne die Preise noch nicht....

....aber schön, dass man schon FUD lesen kann. Besonders einfallsreich ist der aber nicht

Was ist FUD?

[MEissing]

Zitat von greenmile:

Was ist FUD?

Das, was du geschrieben hast....

[mjustin]

Zitat von Robotiker:

Es scheint technisch auch mehr ein Problem der Zertifizierung von Apps für den Shop zu sein, keine Sonderbehandlung der VC++ RTL durch das Betriebssystem.

Ja, das ist aktuell ein etwas sumpfiges Gebiet.

Es gibt eine (technische) Sonderstellung für Internet Explorer, Microsoft Office, das .NET Framework und für die VisualC++ Runtime (native Anwendungen).

Zum Beispiel kann ausser Internet Explorer keine WinRT / ARM Anwendung JIT (Just In Time) Kompilierung implementieren (da dazu vom Store Validator nicht akzeptierte API Funktionen benötigt werden), was schon zu Protesten von Browserherstellern geführt hat:

http://www.freelists.org/post/luajit...dows-8-for-ARM

http://www.extremetech.com/computing...windows-on-arm

http://news.cnet.com/8301-1001_3-574...wser-concerns/

Im Detail wird in diesem Stack Overflow Artikel gezeigt, dass die Sandbox der Windows 8 UI Anwendungen nicht alle Anwendungen gleich behandelt:

http://stackoverflow.com/questions/1...winrt-possible

Hier kann man nachlesen, dass die VC++ Runtime besondere Rechte hat:

Zitat von Allen Bauer:

Right now the VC++ RTL DLL is given special dispensation since that is
the library that makes the calls to those forbidden APIs and not directly from the user’s app.

Für Delphi Entwickler bleibt natürlich immer noch die Möglichkeit, eine WinRT Oberfläche mit einer webbasierten Serveranwendung zu verbinden, die man nativ programmiert.

[Robotiker]

Danke für die Links.

Mal sehen, inwieweit sich das noch bessert, wenn Win8 (und seine Nachfolger) richtig in die Gänge kommt.

Was die Programmierung von XAML-Apps angeht, stellt es sich für mich allerdings so dar, dass der Unterschied zwischen der Programmierung von managed Apps in Prism oder C# und der von nativen Apps in C++, kaum größer ist, als der zwischen Desktop Anwendungen in Delphi und dem C++ Builder. Jeweils gleiche IDE, Tools und Anwendungsstruktur, nur eine andere Sprache und teilweise andere Bibliotheksfunktionen (C++ Standardlib und z.B. Boost, statt .net BCL bzw. VCL/Delphi RTL).

Delphi macht da wohl nur Sinn, wenn man möglichst viele Plattformen mit FireMonkey abdecken will. Man entfernt sich mit der IDE und der Anwendungsstruktur recht weit von den anderen Sprachen.

[Insider2004]

WinRT, MobileStudio, etc. sind mal wieder richtig schöne restriktive Technologien, die total verrammelt sind. Jeder will Geld und Lizenzgebühren kassieren. Ich wette, fast alle Entwickler werden diese Techniken meiden. Das wird sicher ein toller Durchbruch werden. Vor allem, wenn man bedenkt, dass WinRT nur ein zusätzlicher Layer auf der Win32 API ist. Im Prinzip ist .Net=WinRT.