expertenaustausch > microsoft.* > microsoft.german.entwickler.dotnet.vstudio

Michael Sabo (07.09.2006, 15:53)
Hallo,

durch die Diskussionen durch meinen vorherigen Thread ist mir nun ein
anderer Gedanke durch den Kopf.

Früher bis heute war/ist es ja so, dass die komplette Funktionalität von
Windows direkt per C/C++ Code (bzw. indirekt über COM) (kein managed Code!)
aufgerufen und verwendet werden konnte (also ohne installiertes Framework).

Nun in Zeiten von .NET wird das immer noch so sein?
Also ich meine .NET-Klassen sind bestimmt ja keine einfachen
"Wrapper"-Klassen mehr die irgendwo "unten" doch wieder
Standard-C-Funktionen benutzen. M. a. w. lassen sich z.B. neue Controls nur
über .NET verwenden?
Wird die API nur noch aus Kompatibilitätsgründen beibehalten oder kommen
noch Funktionen dazu?

Irgendjemand hier hat auch die Behauptung aufgestellt, dass spätestens mit
Vista der volle Funktionsumfang nur noch mit .NET ausgeschöpft werden kann.
Aber dann hätten ja die Hersteller von ext. Bibliotheken (z.B. wie Qt) ein
Problem, oder? Diese könnten dann ja die neuen Controls gar nicht mehr
ansprechen oder wie?

Weiss da jemand schon was näheres?
(denke das werden höchstens die MVPs wissen)

Michael
Herfried K. Wagner [MVP] (07.09.2006, 16:15)
Hallo Michael!

"Michael Sabo" <Michael.Sabo> schrieb:
> Früher bis heute war/ist es ja so, dass die komplette Funktionalität von
> Windows direkt per C/C++ Code (bzw. indirekt über COM) (kein managed
> Code!)
> aufgerufen und verwendet werden konnte (also ohne installiertes
> Framework).
> Nun in Zeiten von .NET wird das immer noch so sein?


Ich denke ja.

> Also ich meine .NET-Klassen sind bestimmt ja keine einfachen
> "Wrapper"-Klassen mehr die irgendwo "unten" doch wieder
> Standard-C-Funktionen benutzen. M. a. w. lassen sich z.B. neue Controls
> nur
> über .NET verwenden?


Die Windows Presentation Foundation (WPF) als Beispiel ist intern wohl in
C++ implementiert. Das, was als WPF bekannt ist, stellt lediglich eine Hülle
um eine unverwaltete Implementierung dar. Anscheinend wird nur eine
verwaltete Schnittstelle dafür bereitgestellt.

> Wird die API nur noch aus Kompatibilitätsgründen beibehalten oder kommen
> noch Funktionen dazu?


Es wird in Windows Vista zahlreiche neue unverwaltete API-Funktionen geben.

Ich nehme an, dass bei WPF das von Microsoft geschaffene C++/CLI zum Zuge
kommen wird, um bestehende, in C/C++ geschriebene Anwendungen mit einer
WPF-Benutzerschnittstelle zu verbinden. Dieser Weg ist auch explizit
vorgesehen:

Walkthrough: Hosting a Windows Presentation Foundation Page in a Win32
Application
<URL:http://windowssdk.msdn.microsoft.com/en-us/library/ms744829.aspx>

Ähnliches trifft auf andere neue Technologien aus dem .NET Framework 3.0 zu.
Die Integration von Win32 und .NET ist also nahtlos möglich, bestehender
Code muss nicht auf .NET umgestellt werden. Die einzig ärgerliche Sache ist,
dass der Migrationspfad für VB6-Anwendungen weiterhin fehlt.

> Irgendjemand hier hat auch die Behauptung aufgestellt, dass spätestens mit
> Vista der volle Funktionsumfang nur noch mit .NET ausgeschöpft werden
> kann.


Das mag zutreffen, ich halte dies aber nicht für weiter problematisch oder
aussergewöhnlich.

> Aber dann hätten ja die Hersteller von ext. Bibliotheken (z.B. wie Qt) ein
> Problem, oder? Diese könnten dann ja die neuen Controls gar nicht mehr
> ansprechen oder wie?


Warum nicht? Sie können es genau so, wie es Entwickler von C/C++-Anwendungen
mit C++/CLI auch können.
Harald M. Genauck (07.09.2006, 16:44)
Hallo Michael,

[..]
> über .NET verwenden?
> Wird die API nur noch aus Kompatibilitätsgründen beibehalten oder kommen
> noch Funktionen dazu?


Im Grundsatz ist das .NET-Framwork ein Framework zur Entwicklung von
Anwendungen. Das Ziel ist, Anwendungen soweit wie möglich von binären
Gegebenheiten abzukoppeln, sowohl um ggfs. beliebige Layer transparent
zwischen Anwendung und Plattform (OS) einschieben zu können, als auch um
verschiede Plattformen an sich darunterlegen zu können. Bei letzterem ist
sicher weniger an Plattformen verschiedener Welten gedacht, als an
verschieden umfangreiche bzw. fortgeschrittene Windows-Versionen - etwa an
die normalen Desktop-Windows, Server-Windows, Compact-Windows, 32-Bit- oder
64-Bit-Windows. Das Funktionsangebot ist zwar auf den verschiedenen dieser
Plattformen nicht identisch, aber zumindest die jeweils identischen
Teilmengen sind weitestgehend Code-kompatibel und bezüglich der binären
Ebene transparent. Ein besonderer Aspekt ist dazu der Punkt "Sicherheit" -
sowohl in Bezug auf Implementierungssicherheit als auch auf
Zugriffssicherheit.

(Aus diesem Blickwinkel gesehen relativiert sich übrigens auch der vielfach
zu hörende Vorwurf, dass in Vista Microsoft selber das Framework nicht bzw.
bei weitem nicht überall nutzt. Vista ist eben ein spezifisches
Betriebssystem, und keine Anwendung.)

Der allgemeine Tenor lautet daher: Anwendungen sollten auf dem
..NET-Framework aufsetzen und sich möglichst nicht auf Gegebenheiten einer
API-Ebene verlassen. Sicher ist das ein langfristiges Ziel, und mit dem
aktuellen .NET-Stand sicher auch noch nicht konsequent durchhaltbar.

Zumindest ist nicht garantiert, dass für alle Neuerungen und neueren
Windows-Versionen und -Varianten alle APIs in binärer Form offengelegt
werden. Dagegen ist die Wahrscheinlichkeit ziemlich groß, dass alles Neue
konsequent für .NET verfügbar sein wird. In diesem Punkt ist die
Wahrscheinlichkeit auch groß, dass so manches Neue auch bereits selbst in
..NET geschrieben sein wird, es also gar kein binäres API dazu mehr
existieren wird.

> Irgendjemand hier hat auch die Behauptung aufgestellt, dass spätestens
> mit
> Vista der volle Funktionsumfang nur noch mit .NET ausgeschöpft werden
> kann.
> Aber dann hätten ja die Hersteller von ext. Bibliotheken (z.B. wie Qt)
> ein
> Problem, oder? Diese könnten dann ja die neuen Controls gar nicht mehr
> ansprechen oder wie?


Dazu vielleicht auch:


Möglicherweise könnten solche Bibliothekenhersteller Probleme bekommen. Sie
könnten aber auch das XAML-Modell übernehmen und eigene Render-Engines
darunter legen - so, wie es etwa bezüglich HTML ja schon "ewig" ist. Ich
könnte mir auch vorstellen, dass sich das Mono-Projekt leichter damit tun
könnte, XAML zu adaptieren, als das klassische Windows-Forms-Modell eher
krampfhaft komplett umsetzen zu wollen.

> Weiss da jemand schon was näheres?
> (denke das werden höchstens die MVPs wissen)


MVPs haben vielleicht die eine oder andere Information eher im Blick und
zur Hand - was sicher auch ein Grund dafür ist, dass sie MVPs geworden
sind. Aber was MVPs wissen, was nicht auch andere aus offenen Quellen
ersehen können, dürfen sie gar nicht öffentlich erzählen...
;-)

Viele Grüße

Harald M. Genauck

ABOUT Visual Basic - das Webmagazin -
"visual studio one" -
Michael Sabo (07.09.2006, 16:44)
> Warum nicht? Sie können es genau so, wie es Entwickler von C/C++-Anwendungen
> mit C++/CLI auch können.


Das heißt ja dann wieder, dass doch ein .NET-Framework installiert sein
muss.
Dachte immer das .NET-Framwork soll die Programmierung nur vereinfachen und
die Entwicklungszeit verkürzen, man muss es aber nicht zwingend benutzen.
Also gleichbedeutend wie früher MFC. Man konnte es benutzen, man musste es
aber nicht und man konnte trotzdem "dieselbe" Applikation erstellen (wenn
auch mühsamer wenn nur direkt die Win32-API benutzt wurde - aber es geht ja
nur um die Theorie)

Michael
Thomas Scheidegger [MVP] (07.09.2006, 16:46)
Hallo Michael

> Nun in Zeiten von .NET wird das immer noch so sein?
> Also ich meine .NET-Klassen sind bestimmt ja keine einfachen
> "Wrapper"-Klassen mehr die irgendwo "unten" doch wieder
> Standard-C-Funktionen benutzen.


doch, die aktuelle Microsoft Windows .NET-Implementation baut schlussendlich auch
auf der C/C++ Runtime, Win32 und teils noch etwas COM (siehe auch SSCLI).
Aber dies ist nur eine 'Implementation', muss nicht so sein/bleiben.
Die CLI-Norm lässt viele techn. Varianten der Implementation zu,
was je nach Ziel-OS auch der Fall ist.

> Wird die API nur noch aus Kompatibilitätsgründen beibehalten oder kommen
> noch Funktionen dazu?


Win32 wird nicht so schnell verschwinden.
Aber ich vermute schon, dass laufend eher weniger neue Features dazukommen.

..NET / managed Code wird IMHO nach und nach immer üblicher,
so selbstverständlich wie seinerzeit der Wechsel Assembler -> C -> C++ (DOS, Win32)

Als ein mögliches Szenario sehe ich persönlich auch,
dass das heutige unmanaged-Win32 (für Kompatib.) ganz in einer VM isoliert wird,
das OS (mind. User-Mode / Shell) aber neu ausschliesslich auf managed Code aufgebaut wird.
Die IT-Welt würde dadurch massiv sicherer und SW generell stabiler.

> M. a. w. lassen sich z.B. neue Controls nur über .NET verwenden?


was für 'neue' Controls? WPF?
Auch dazu sind weiterhin noch immer native-APIs verfügbar,
..NET 3.0 bietet aber einiges an zusätzlichem 'Komfort' und Funktionalität.

> Irgendjemand hier hat auch die Behauptung aufgestellt, dass spätestens mit
> Vista der volle Funktionsumfang nur noch mit .NET ausgeschöpft werden kann.


....teils, teils.

> Aber dann hätten ja die Hersteller von ext. Bibliotheken (z.B. wie Qt) ein
> Problem, oder? Diese könnten dann ja die neuen Controls gar nicht mehr
> ansprechen oder wie?


WPF ist AFAIK genug 'offen' dokumentiert,
so dass Dritthersteller einen guten Teil der Features nutzen könnten.

Nur, .NET ist ganz klar eine neue Generation und umfassende, strategische Plattform,
gerade mit WPF werden viele andere Lösungen IMHO bald recht alt aussehen.

Solange Windows weiterhin mit Abstand das führende Desktop-OS ist,
wird Microsoft die GUI-Technologien massgebend bestimmen.
Andere haben sich wohl danach zu richten.

> denke das werden höchstens die MVPs wissen


Microsoft's weitere Pläne (über Vista/WPF hinaus)
sind momentan wohl auch intern eher nur wenigen Leuten bekannt...
Karsten Heimer (07.09.2006, 16:48)
"Michael Sabo" <Michael.Sabo> schrieb im Newsbeitrag
news:6d93
> Nun in Zeiten von .NET wird das immer noch so sein?
> Also ich meine .NET-Klassen sind bestimmt ja keine einfachen
> "Wrapper"-Klassen mehr die irgendwo "unten" doch wieder
> Standard-C-Funktionen benutzen. M. a. w. lassen sich z.B. neue
> Controls nur
> über .NET verwenden?
> Wird die API nur noch aus Kompatibilitätsgründen beibehalten oder
> kommen
> noch Funktionen dazu?


Leider Gottes ist das .NET tatsächlich an manchen Stellen nicht mehr an
als ein Hülle um den Windows-Kern drum herum. So ist es zwar extrem
einfach, eine Webseite in ein eigenes Programm zu integrieren, aber die
leidet unter den gleiche Sicherheitsproblemen wie der "große"
Internet-Explorer, d.h. es werden die gleichen Funktionen benutzt. Aber
im Prinzip ist das ja kein Problem und auch nicht so schlecht. Immerhin
liegt ja der Reiz von .NET auch darin, dass die sämtliche Funktionalität
des Rechners über eine saubere umfangreiche Klassenstruktur verfügbar
gemacht wird. Ob die API kompatibel ist oder nicht, wäre dann egal, wenn
man ausschliesslich über das .NET geht. Das bleibt auf jeden Fall
kompatibel.

Gruß, Karsten.
Arne Janning (07.09.2006, 17:05)
Hallo Thomas,

"Thomas Scheidegger [MVP]" wrote

> Microsoft's weitere Pläne (über Vista/WPF hinaus)
> sind momentan wohl auch intern eher nur wenigen Leuten bekannt...


Aus einem Gespräch, das ich heute mit einem Microsoft-Mitarbeiter hatte:
"Wir planen nicht länger als 24 Monate im Voraus..."

;-)

Liebe Grüße

Arne Janning
Thomas Scheidegger [MVP] (07.09.2006, 18:26)
> Das heißt ja dann wieder, dass doch ein .NET-Framework installiert sein muss.
> Dachte immer das .NET-Framwork soll die Programmierung nur vereinfachen und
> die Entwicklungszeit verkürzen, man muss es aber nicht zwingend benutzen.
> Also gleichbedeutend wie früher MFC. Man konnte es benutzen, man musste es aber nicht


managed Code, JITer, GC, Metadata/Reflection, CLR usw
setzen eine umfangreichere _Infrastruktur_ voraus,
ist keinesfalls mehr mit einer simplen Zusatzbibliothek wie der MFC vergleichbar.
Harald M. Genauck (07.09.2006, 18:48)
> > Das heißt ja dann wieder, dass doch ein .NET-Framework installiert
> sein muss.
> vereinfachen und
> benutzen.
> musste es aber nicht


> managed Code, JITer, GC, Metadata/Reflection, CLR usw
> setzen eine umfangreichere _Infrastruktur_ voraus,
> ist keinesfalls mehr mit einer simplen Zusatzbibliothek wie der MFC
> vergleichbar.


Von "Gewicht" und Bedeutung her könnte man .NET als Aufsatz zum
herkömmlichen Windows durchaus mit Windows als Aufsatz zum früheren DOS
vergleichen. Auch da hat es einige Generation gedauert, bis schließlich
alle nativen DOS-APIs durch echte, Windows-eigene APIs ersetzt wurden.

Viele Grüße

Harald M. Genauck

ABOUT Visual Basic - das Webmagazin -
"visual studio one" -
Herfried K. Wagner [MVP] (07.09.2006, 23:44)
Hallo Michael!

"Michael Sabo" <Michael.Sabo> schrieb:
>> Warum nicht? Sie können es genau so, wie es Entwickler von

> C/C++-Anwendungen
>> mit C++/CLI auch können.

> Das heißt ja dann wieder, dass doch ein .NET-Framework installiert sein
> muss.


Na, wenn mit Windows Vista das .NET Framework ohnehin im Betriebssystempaket
enthalten ist, sollte das doch kein Problem darstellen -- man nutzt es, wie
jede andere Bibliothek auch.

> Dachte immer das .NET-Framwork soll die Programmierung nur vereinfachen
> und
> die Entwicklungszeit verkürzen, man muss es aber nicht zwingend benutzen.
> Also gleichbedeutend wie früher MFC. Man konnte es benutzen, man musste es
> aber nicht und man konnte trotzdem "dieselbe" Applikation erstellen (wenn
> auch mühsamer wenn nur direkt die Win32-API benutzt wurde - aber es geht
> ja
> nur um die Theorie)


Letztendlich kommst du nicht umhin, Bibliotheken zu benutzen. Die DLLs des
..NET Frameworks stellen eine neue Sammlung an Bibliotheken dar.
Jochen Kalmbach [MVP] (08.09.2006, 08:02)
Hallo Harald!

> Zumindest ist nicht garantiert, dass für alle Neuerungen und neueren
> Windows-Versionen und -Varianten alle APIs in binärer Form offengelegt
> werden. Dagegen ist die Wahrscheinlichkeit ziemlich groß, dass alles
> Neue konsequent für .NET verfügbar sein wird.


Na, das mag ja für Betriebssysteme nach Vista gelten, nicht aber für Vista.
Vista ist ein *reines* native OS (zumindest was der Kernel anbelangt),
deshalb ist die eigentliche Schnittstelle eine "native" Schnittstelle.

Auch ist z.B. eine Erweiterung von Windows-Forms (die ja aktuell in V2
vorliegt) für Vista nicht geplant (oder hab ich da was verpasst!?).
Deshalb wird es für sehr viele Features *nur* native Schnittstellen
geben, die man dann via P/Invoke aufrufen muss (wie es ja heute auch
scho ist; wird für Vista nur wesentlich mehr werden, da ja sehr viele
neue "Flags" hinzugekommen sind).

Das .NET Framework 3 hat eigentlich nur im Bereich Indigo (WCF) Dinge zu
bieten, die man zwar in native Code auch machen kann (Indigo verwendet
auch nur das (native) OS), aber sich doch in managed Code einfacher
realisieren lassen (oder eben jetzt schon vorgefertigt von MS kommen).

Greetings
Jochen
Harald M. Genauck (08.09.2006, 10:39)
Hallo Jochen,

>> Zumindest ist nicht garantiert, dass für alle Neuerungen und neueren
>> Windows-Versionen und -Varianten alle APIs in binärer Form offengelegt
>> werden. Dagegen ist die Wahrscheinlichkeit ziemlich groß, dass alles
>> Neue konsequent für .NET verfügbar sein wird.


> Na, das mag ja für Betriebssysteme nach Vista gelten, nicht aber für
> Vista.
> Vista ist ein *reines* native OS (zumindest was der Kernel anbelangt),
> deshalb ist die eigentliche Schnittstelle eine "native" Schnittstelle.
> Auch ist z.B. eine Erweiterung von Windows-Forms (die ja aktuell in V2
> vorliegt) für Vista nicht geplant (oder hab ich da was verpasst!?).


Ich weiß auch von nichts...

> Deshalb wird es für sehr viele Features *nur* native Schnittstellen
> geben, die man dann via P/Invoke aufrufen muss (wie es ja heute auch scho
> ist; wird für Vista nur wesentlich mehr werden, da ja sehr viele neue
> "Flags" hinzugekommen sind).


Vielleicht stehen ja die 2D-Winforms auf lange Sicht auf der Abschussliste?

> Das .NET Framework 3 hat eigentlich nur im Bereich Indigo (WCF) Dinge zu
> bieten, die man zwar in native Code auch machen kann (Indigo verwendet
> auch nur das (native) OS), aber sich doch in managed Code einfacher
> realisieren lassen (oder eben jetzt schon vorgefertigt von MS kommen).


Die Workflow Foundation und den CardSpace wird man sicher auch selber bauen
können, nativ oder managed...

Viele Grüße

Harald M. Genauck

ABOUT Visual Basic - das Webmagazin -
"visual studio one" -
Ähnliche Themen