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.

[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

[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.

[Uwe Raabe]

Zitat von Insider2004:

WinRT, MobileStudio, etc. sind mal wieder richtig schöne restriktive Technologien, die total verrammelt sind.

Woher hast du dein Wissen über MobileStudio, aus dem du diese Schlussfolgerung ziehen kannst? Ich kann zur Zeit noch nicht einmal nachvollziehen, wie man MobileStudio als Technologie bezeichnen kann.

[mkinzler]

MobileStudio ist ja eine IDE inkl. (ARM)Compiler und die jeweiliegen FM2 Versionen für iOS und Android. Wenn Restriktionen bestehen liegen sie nicht an Mobile Studio, sondern an der Zielpplatfoem; genauso wie an WinRT.