WinFX wird zu .net 3.0 - laufen jetzt alle Vista-Apps in der CLR?

[Benedikt]

Hi Leute,

dadurch, dass WinFX jetzt zum .net-Framework 3.0 "umbenannt" wurde (http://blogs.msdn.com/somasegar/archive/2006/06/09/624300.aspx), tauchen bei mir zwei Fragen auf:


Wird es immer noch möglich sein, Anwendungen im Vista-Look beispielsweise als gewöhnliche (und effiziente) C-/C++-Anwendungen zu schreiben, oder ist man als Programmierer jetzt zwingend angehalten, Managed Code zu schreiben bzw. CLR-Anwendungen zu erzeugen?
Und außerdem: Erhalten eigentlich für XP kompilierte Anwendungen mit Luna-Optik (bzw. Manifestdatei) automatisch den Vistalook, wenn sie unter Windows Vista ausgeführt werden? Oder ist zwingend ein Neukompilieren bzw. Verwendung von Avalon (oder wie das Zeug heißt) notwendig?
Danke schon mal für die Beantwortung meiner Fragen! ;)

MFG,
Benedikt

[Demirug]

Die Glass Effekte bekommt jede Applikation automatisch, solange sie nichts tut was den neuen Desktopmanager gleich ganz deaktiviert. Zusätzlich kann man mit einem Trick den ich jetzt gerade nicht im Kopf habe auch weitere Bereich mit diesem Milchglas Effekt versehen. Dafür ist dann aber IIRC etwas code erforderlich.

Will man allerdings das neue Vektor basierende UI System nutzen (WPF; Windows Präsentation Framework) so muss das zwingend eine CLR Anwendung sein. Das war aber schon immer so und ist ja auch nicht auf Vista beschränkt.

Zudem werden immer mehr neuen APIs beginnend mit Vista nur noch als .Net Version erscheinen.

Bisher gibt es AFAIK keine Vorgaben von Microsoft was nun zu bevorzugen ist und native Programme werden weiterhin auf dem gleichen Level unterstützt wie bei XP. Allerdings geht der Trend ganz klar in Richtung managed.

[Gast]

Demirug[/POST]']Will man allerdings das neue Vektor basierende UI System nutzen (WPF; Windows Präsentation Framework) so muss das zwingend eine CLR Anwendung sein. Das war aber schon immer so und ist ja auch nicht auf Vista beschränkt.


Man kann aber durchaus native Anwendungen über Interop mit WPF austatten. Du kannst ja auch schon heute in einer MFC Anwendung Windows Forms Controls verwenden. Solche Interoperabilitätsmöglichkeiten wird es auch mit WPF geben. Natürlich laufen dann diese Controls aber unter der CLR, wie schon von dir erwähnt.

[Demirug]

So war das auch gemeint:

CLR Anwendung = Benötigt das .Net Framework.

[Expandable]

Da das Net Framework 3.0 ja auch für WinXP veröffentlicht wird und da dann auch Vistas XAML unterstützt wird, frage ich mich nun, inwiefern die XP-Version gegenüber der Vista-Funktion eingeschränkt ist (weil unter XP wird das wohl kaum über D3D laufen, oder)? Zumindest in der WinFX-Beta ist alles unter XP etwas unscharf... vielleicht aber auch ein Treiberbug...

[Benedikt]

Demirug[/POST]']Die Glass Effekte bekommt jede Applikation automatisch, solange sie nichts tut was den neuen Desktopmanager gleich ganz deaktiviert. Zusätzlich kann man mit einem Trick den ich jetzt gerade nicht im Kopf habe auch weitere Bereich mit diesem Milchglas Effekt versehen. Dafür ist dann aber IIRC etwas code erforderlich.

Hm, dieser Milchglaseffekt wirkt aber nur auf die Bereiche, die sowieso vom Windowmanager verwaltet werden, oder? Also vereinfacht gesprochen die Fensterumrahmung, die Titelleiste usw.?
Demirug[/POST]']
Will man allerdings das neue Vektor basierende UI System nutzen (WPF; Windows Präsentation Framework) so muss das zwingend eine CLR Anwendung sein. Das war aber schon immer so und ist ja auch nicht auf Vista beschränkt.

Zudem werden immer mehr neuen APIs beginnend mit Vista nur noch als .Net Version erscheinen.

Bisher gibt es AFAIK keine Vorgaben von Microsoft was nun zu bevorzugen ist und native Programme werden weiterhin auf dem gleichen Level unterstützt wie bei XP. Allerdings geht der Trend ganz klar in Richtung managed.
Der letzte Absatz, ich weiß nicht ob ich den jetzt ganz verstanden habe: Also prinzipiell ist WPF/Avalon nur mit managed Anwendungen möglich?
Was ist mit den performancekritischen Bereichen von Vista, diese sind aber, nehme ich mal, an noch immer "unmanaged", oder?

[Demirug]

Expandable[/POST]']Da das Net Framework 3.0 ja auch für WinXP veröffentlicht wird und da dann auch Vistas XAML unterstützt wird, frage ich mich nun, inwiefern die XP-Version gegenüber der Vista-Funktion eingeschränkt ist (weil unter XP wird das wohl kaum über D3D laufen, oder)? Zumindest in der WinFX-Beta ist alles unter XP etwas unscharf... vielleicht aber auch ein Treiberbug...

Es läuft auch unter XP über D3D9. Kann es sein das du im Panel das AA aktiviert hast?

[Demirug]

Benedikt[/POST]']Hm, dieser Milchglaseffekt wirkt aber nur auf die Bereiche, die sowieso vom Windowmanager verwaltet werden, oder? Also vereinfacht gesprochen die Fensterumrahmung, die Titelleiste usw.?

Es gibt wie gesagt einen Trick den Effekt auch in den Clientbereich zu bekommen.

Benedikt[/POST]']Der letzte Absatz, ich weiß nicht ob ich den jetzt ganz verstanden habe: Also prinzipiell ist WPF/Avalon nur mit managed Anwendungen möglich?
Was ist mit den performancekritischen Bereichen von Vista, diese sind aber, nehme ich mal, an noch immer "unmanaged", oder?

Avalon/WPF braucht grundsätzlich die CLR.

Ich weiss zwar jetzt nicht was du als performancekritisch ansiehst aber in diesem Punkt hast du scheinbar eine falsche Vorstellung über das Laufzeit verhalten von managed Code. Allerdings sind die meisten Teile von Vista selbst noch unmanaged. Das ist allerdings eine Folge davon das es einfach nicht möglich war Teile des Betreibssystems schon auf WinFX umzuschreiben bevor WinFX überhaupt fertig ist. Man hat dieses Betas über Betas bauen versucht und am Ende ist alles zugebrochen und hat diese riesigen Verzögerungen bei Vista verursacht.

[Benedikt]

Demirug[/POST]']
Avalon/WPF braucht grundsätzlich die CLR.

Hm, okay. Also die "beigelegten" Anwendungen im Vistalook (Calendar, Windows Mail, dieses Videoschnittprogramm, Mediaplayer 11), sind demnach, weil sie ja offenbar Avalon verwenden CLR-Anwendungen...?
Demirug[/POST]']
Ich weiss zwar jetzt nicht was du als performancekritisch ansiehst aber in diesem Punkt hast du scheinbar eine falsche Vorstellung über das Laufzeit verhalten von managed Code. Allerdings sind die meisten Teile von Vista selbst noch unmanaged. Das ist allerdings eine Folge davon das es einfach nicht möglich war Teile des Betreibssystems schon auf WinFX umzuschreiben bevor WinFX überhaupt fertig ist. Man hat dieses Betas über Betas bauen versucht und am Ende ist alles zugebrochen und hat diese riesigen Verzögerungen bei Vista verursacht.
Hm, dein letzter Satz interessiert mich jetzt aber: Man hat versucht, Vista grundlegend "managed" umzuschreiben, und ist daran gescheitert (oder hat dies zumindest vorgehabt)?
Welche Beta-Werkzeuge meinst du - das zum damaligen Zeitpunkt noch nicht fertiggestellte WinFX-SDK hat zu Verzögerungen geführt?
Kurzum: Weiß nicht recht was du meinst, bitte mehr dazu...

[Trap]

Benedikt[/POST]']Hm, okay. Also die "beigelegten" Anwendungen im Vistalook (Calendar, Windows Mail, dieses Videoschnittprogramm, Mediaplayer 11), sind demnach, weil sie ja offenbar Avalon verwenden CLR-Anwendungen...?
Das hängt daven ab wie du "sind" und "CLR-Anwendungen" definierst. Man kann aus beliebigem Code per interop .NET Zeug benutzen. Zum Beispiel kann man in Lisp, Assembler oder Java Anwendungen schreiben die .NET-Klassen für die GUI benutzen. Die brauchen dann natürlich die CLR zum laufen, laufen aber nicht innerhalb der CLR. Sind das für dich CLR-Anwendungen?

Ob die beigelegten Anwendungen in managed Code geschrieben sind oder die GUI per interop erzeugen weiß ich nicht, ich würde das erstere vermuten.

[Demirug]

Benedikt[/POST]']Hm, okay. Also die "beigelegten" Anwendungen im Vistalook (Calendar, Windows Mail, dieses Videoschnittprogramm, Mediaplayer 11), sind demnach, weil sie ja offenbar Avalon verwenden CLR-Anwendungen...?

Dieser Vistalook hat nichts mit WPF zu tun. Wenn überhaupt werden nur wenige der mitgelierferten Programme WPF nutzen.

Benedikt[/POST]']Hm, dein letzter Satz interessiert mich jetzt aber: Man hat versucht, Vista grundlegend "managed" umzuschreiben, und ist daran gescheitert (oder hat dies zumindest vorgehabt)?
Welche Beta-Werkzeuge meinst du - das zum damaligen Zeitpunkt noch nicht fertiggestellte WinFX-SDK hat zu Verzögerungen geführt?
Kurzum: Weiß nicht recht was du meinst, bitte mehr dazu...

Mircrosoft wollte im User bereich des Systems (nicht im Kernel) wirklich einen großen Rundumschlag machen. Während nun ein Teil der Teams an WinFX gearbeitet hat sollten die anderen bereits Anwendungen schreiben. Dummerweiße haben dann natürlich die regelmässigen Änderungen an WinFX dazu geführt das die Anwendungsentwickler wegen den ständigen Anpassungen nicht mehr vorwärts kammen. Deswegen wurde dann beides voneinader getrennt.

Es war also kein technisches Problem sondern ein Organisatorisches.

[Expandable]

Demirug[/POST]']Es läuft auch unter XP über D3D9. Kann es sein das du im Panel das AA aktiviert hast?

Also im nHancer ist AA auf App-gesteuert gestellt. Im Visual Studio Designer habe ich ein Property (RenderOptions.EdgeMode) gefunden, wo man "unspecified/aliased" einstellen kann. Aber das hat keine Auswirkungen... hier mal ein Bild... man beachte, wieviel schärfer und besser die Schrift in VS ist als in der WinFX-Testapp.

Bild (http://img152.imageshack.us/img152/2541/winfx0lb.jpg)

Und das läuft in XP wirklich auch über D3D9? Sind dann unter XP auch ein Großteil der Vista-Effekte möglich?

[Demirug]

Expandable[/POST]']Also im nHancer ist AA auf App-gesteuert gestellt. Im Visual Studio Designer habe ich ein Property (RenderOptions.EdgeMode) gefunden, wo man "unspecified/aliased" einstellen kann. Aber das hat keine Auswirkungen... hier mal ein Bild... man beachte, wieviel schärfer und besser die Schrift in VS ist als in der WinFX-Testapp.

Bild (http://img152.imageshack.us/img152/2541/winfx0lb.jpg)

Am Font System wird IIRC noch gearbeitet. Könnte sein das es da noch Abstimmungprobleme zwischen Anwendung und Treiber gibt.

Expandable[/POST]']Und das läuft in XP wirklich auch über D3D9? Sind dann unter XP auch ein Großteil der Vista-Effekte möglich?

Innerhalb deiner eigenen Anwendung ja. Aber damit das ganze auf dem Desktop funktioniert ist mehr als nur WPF notwendig.

[Benedikt]

Demirug[/POST]']
Mircrosoft wollte im User bereich des Systems (nicht im Kernel) wirklich einen großen Rundumschlag machen. Während nun ein Teil der Teams an WinFX gearbeitet hat sollten die anderen bereits Anwendungen schreiben. Dummerweiße haben dann natürlich die regelmässigen Änderungen an WinFX dazu geführt das die Anwendungsentwickler wegen den ständigen Anpassungen nicht mehr vorwärts kammen. Deswegen wurde dann beides voneinader getrennt.

Es war also kein technisches Problem sondern ein Organisatorisches.
Danke für die Erklärung!

Demirug[/POST]']
Dieser Vistalook hat nichts mit WPF zu tun. Wenn überhaupt werden nur wenige der mitgelierferten Programme WPF nutzen.
*kopfkratz*
Aha. Woran erkenne ich denn dann am "look and feel", ob eine Anwendung WPF nun verwendet oder nicht - was verändert sich? Also Calendar und diese Bildansicht sehen für mich schon verdammt "vista-isiert" aus. Hast du ein Beispiel für eine Vista-Anwendung, die wirklich WPF nutzt?

[Benedikt]

Dieser Vistalook hat nichts mit WPF zu tun. Wenn überhaupt werden nur wenige der mitgelierferten Programme WPF nutzen.

Mittlerweile hab ich auch Vista getestet, und ich glaube dass die einzigen (beiliegenden) Anwendungen, die WPF nutzen, die Spiele sind. Warum? Stufenloses skalieren des Fensters ist möglich (die UI skaliert frei mit), und die Apps brauchen massiv Speicher.
Alles, was sonst noch beiliegt, scheint nicht in Avalon/WinFX programmiert zu sein...

[Kabelsalat]

Es gibt wie gesagt einen Trick den Effekt auch in den Clientbereich zu bekommen.

In der DotNetPro 10/2006 (www.dotnetpro.de) ist erklärt wie es funktioniert.