WinAPI-Ersatz in Windows Longhorn
-
Hallo Leute,
mit Windows Longhorn wird ja die normale WinAPI verschwinden und eine neue an dessen Stelle treten. Habe mal versucht etwas über diese neue API rauszufinden, aber hat nciht so richtig geklappt. Deswegen frage ich jetzt hier.
Was ich durch meine Recherchen herausgefunden habe, ist, dass diese neue API WinFX heißen wird. Ist das korrekt? Oder hab ich da was falsch verstanden?
Die neue API scheint eine .NET-API zu sein, also einfach .NET-Klassen, die man in seinen Programmen verwenden kann. Ist das korrekt?
Hat mir jemand nen netten Link zu diesem Thema?
-
Also verschwinden wird sie nicht von heute auf morgen, aber Microsoft pusht mit gutem Grund .NET und im Vergleich zur WinApi ist .Net wirklich ein Segen.
Damit wäre die Frage an sich auch schon beantwortet was nach der WinApi kommt und das ist das .Net Framework!
Win Fx beinhaltet Technologien wie Aero und Avalon, welches mehr oder weniger für die Präsentation von Daten in Longhorn verantwortlich ist, sprich, nur ein Teilstück vom ganzen.
Und ja, du kannst dann einfach programmieren wie schon heute mit dem .Net Framework. Das .Net Framework bietet sich ja heute schon als Alternative zur WinApi an.
-
Talla schrieb:
Win Fx beinhaltet Technologien wie Aero und Avalon, welches mehr oder weniger für die Präsentation von Daten in Longhorn verantwortlich ist, sprich, nur ein Teilstück vom ganzen.
Avalon habe ich heute schon getestet, finde es allerdings ziemlich seltsam:
Ich habe in meinem Avalon-Projekt xaml- und cs-Dateien. Die xaml-Dateien sind für die GUI zuständig, die cs-Dateien für die Eventbehandlung und die Dinge, die das Programm eben tut.
Das komische ist nur: die xaml-Dateien werden von einem "Präprozessor" in ganz normale cs-Dateien übersetzt, die dann mit den bereits vorhandenen kompiliert werden. Welchen Vorteil hat man davon, das Layout seiner Anwendung jetzt nicht mehr mit dem Formsdesigner zusammenzuklicken sondern per xaml in eine Textdatei zu hacken?Talla schrieb:
Das .Net Framework bietet sich ja heute schon als Alternative zur WinApi an.
Naja, nicht wirklich. Es gibt noch genug Fälle in denen man per dllimport auf WinAPI-Funktionen zurückgreifen muss.
-
Das XAML Dateien einfach von einer Art Präprozessor in C# Dateien übersetzt werden glaub ich net. XAML dient dazu die GUI in XML Form zu definieren und das geht wirklich schneller als auf normalen Weg. Es gibt auf der Webseite dazu ein paar beeindruckende Beispiele, wie ruck zuck umfangreiche GUI's zusammengestellt werden, die viel weniger Schreibarbeit benötigen als klassisches C#. Und dazu wirds dann auch einen Designer geben, im Moment ists wirklich noch ein wenig umständlich, obwohl Intellisense ja auch schon viel schafft wenn man die Tags net kennt. Und man kann auch Anwendungen komplett in XAML schreiben und einfaches Verhalten zufügen, ohne Code in C# zu schreiben.
Zu WinApi: Klar muss man noch oft importieren, aber immerhin liegt das .Net Framework auch in Version 1.1 vor! Mit 2.0 wird sich ja schon einiges ändern(auch in C#) und auch erste Ideen für 3.0 gibt es ja. Comega ist z.b. ne Sprache die C# erweitert und von Microsoft Research entwickelt wird und XML noch stärker einbindet(sehr gute Ideen meiner Meinung nach) - und einige Konzepte sollen halt auch in die übernächste Version von C#/.Net einfließen.
Was ich damit sagen will, ist eigentlich das es nicht geht von heute auf Morgen auf Winapi zu verzichten, sondern das sich alles langsam entwickelt und irgendwann wird der Zeitpunkt kommen wo sich Leute fragen wie man so "primitiv" mit der WinApi programmieren konnte
XML kommt immer mehr in Mode und wird überall stark genutzt. Es läuft vieles auf deklaratives(beschreibendes) Programmieren hinaus. Es wird nicht nur die Oberfläche beschrieben in XML, sondern auch bald das Verhalten und Datenstrukturen ja eh.
-
Die WinAPI wird nicht verschwinden, warum auch? Es gibt keinen plausiblen Grund. Nur weil sie unschön ist? Ist ja blödsinnig!
Aber heißt die neue API nicht WinFX? .NET ist doch keine API sondern ein Framework das eine VM benötigt. Sind doch zwei verschiedene paar Schuhe.
-
Talla schrieb:
Das XAML Dateien einfach von einer Art Präprozessor in C# Dateien übersetzt werden glaub ich net.
Is aber so
Talla schrieb:
XAML dient dazu die GUI in XML Form zu definieren und das geht wirklich schneller als auf normalen Weg.
Naja... IMHO geht es schneller ein Layout mit dem Designer zu basteln. Da seh ich immer sofort, wie es später mal aussehen wird und muss zum Testen nicht erst kompilieren.
Aber du hast schon recht, manchmal ist es einfacher, allerdings konnte ich dem Designen von Layouts in HTML noch nie was abgewinnen und mit XAML ist es ja doch recht ähnlich.Talla schrieb:
Es gibt auf der Webseite dazu ein paar beeindruckende Beispiele, wie ruck zuck umfangreiche GUI's zusammengestellt werden, die viel weniger Schreibarbeit benötigen als klassisches C#.
Hm, bei C# benötigt man dank Designer doch garkeine Schreibarbeit
Talla schrieb:
Und dazu wirds dann auch einen Designer geben, im Moment ists wirklich noch ein wenig umständlich
Dann versteh ich's garnicht mehr, welchen Sinn das haben soll.
-
Artchi schrieb:
.NET ist doch keine API sondern ein Framework das eine VM benötigt.
Eine VM? Hast du schon mal mit .Net programmiert? Wenn ja solltest du eigentlich wissen, dass da keine VM (=Virtuelle Maschiene) existiert, da alles sonst zu lahm würde, um das die Hälfte von Longhorn zu implementieren. Am Ende wird alles direkt auf dem Prozessor ausgeführt, weshalb mir eine VM gestohlen bleiben kann
.
-
Artchi schrieb:
Die WinAPI wird nicht verschwinden, warum auch? Es gibt keinen plausiblen Grund. Nur weil sie unschön ist? Ist ja blödsinnig!
Die WinAPI in ihrer jetzigen Form wird definitiv verschwinden.
Artchi schrieb:
Aber heißt die neue API nicht WinFX? .NET ist doch keine API sondern ein Framework das eine VM benötigt. Sind doch zwei verschiedene paar Schuhe.
Und was ist WinFX dann?
-
Die WinAPI in ihrer jetzigen Form wird definitiv verschwinden.
Sie wird aber noch sehr lange erhalten bleiben. Nur wird sie nicht mehr so oft benutzt.
-
winapi. schrieb:
Die WinAPI in ihrer jetzigen Form wird definitiv verschwinden.
Sie wird aber noch sehr lange erhalten bleiben. Nur wird sie nicht mehr so oft benutzt.
Es hiess doch mal, dass sie erhalten bleibt, aber nur als Kompatibilitätsschicht zu alten Versionen. Diese Schicht baut aber auf .Net auf. Soweit ich weiss gibt es so etwas bereits für den LCC - *omg* eine WinAPI, welche auf .Net basiert, welches im Moment noch aug WinAPI basiert
.
-
dEUs schrieb:
Naja... IMHO geht es schneller ein Layout mit dem Designer zu basteln. Da seh ich immer sofort, wie es später mal aussehen wird und muss zum Testen nicht erst kompilieren.
Disclaimer: Ich nehme das nur als Aufhänger und das geht nicht gegen dich persönlich.
Diese ganzen Designer-Leute gehen mir langsam ein bisschen auf die Nerven. Nicht, dass ich was gegen gute GUI-Designer hätte wie bei Netbeans. Aber ich kann keine fixed-size Dialoge mehr sehen, wo man sich null Gedanken darüber gemacht hat, wie das mit einer anderen Schrift oder sonst was aussieht.
Und leider sind 99% der Dialoge so, auch die von Microsoft selber. Wirklich sehr faszinierend, dass ich bei meinem 17" TFT mit 1280 nativer Auflösung nicht die Schrift um ein Viertel größer stellen darf ohne dass es genug Dialoge gibt, wo dann die Hälfte fehlt.
Die meisten GUI-Designer, insbesondere die von VS kennen sowas wie Layout-Manager fast gar nicht und die Leute klicken sich schnell was zusammen, was bei _ihrer_ Auflösung und _ihrer_ Schriftart gut aussieht und machen sich keine Gedanken. Solche schlechten Designer fördern das einfach.User_t schrieb:
Eine VM? Hast du schon mal mit .Net programmiert? Wenn ja solltest du eigentlich wissen, dass da keine VM (=Virtuelle Maschiene) existiert, da alles sonst zu lahm würde, um das die Hälfte von Longhorn zu implementieren. Am Ende wird alles direkt auf dem Prozessor ausgeführt, weshalb mir eine VM gestohlen bleiben kann
.Was redest du eigentlich für einen Schwachsinn? Bitte lesen. Danke.
-
.NET übersetzt sämtliche verwendete Klassen beim ersten Laden in Maschinencode
Widerspricht das meiner Aussage?
-
Optimizer schrieb:
Diese ganzen Designer-Leute gehen mir langsam ein bisschen auf die Nerven. Nicht, dass ich was gegen gute GUI-Designer hätte wie bei Netbeans. Aber ich kann keine fixed-size Dialoge mehr sehen, wo man sich null Gedanken darüber gemacht hat, wie das mit einer anderen Schrift oder sonst was aussieht.
Und leider sind 99% der Dialoge so, auch die von Microsoft selber. Wirklich sehr faszinierend, dass ich bei meinem 17" TFT mit 1280 nativer Auflösung nicht die Schrift um ein Viertel größer stellen darf ohne dass es genug Dialoge gibt, wo dann die Hälfte fehlt.
Die meisten GUI-Designer, insbesondere die von VS kennen sowas wie Layout-Manager fast gar nicht und die Leute klicken sich schnell was zusammen, was bei _ihrer_ Auflösung und _ihrer_ Schriftart gut aussieht und machen sich keine Gedanken. Solche schlechten Designer fördern das einfach.
Hast recht. Das aergert mich auch immer.
Dabei waere es so einfach: Man schreibt ein paar gute Layout-Manager-Klassen, und macht den GUI-Designer so, dass er Elemente nicht absolut positioniert, sondern Elemente z.B. in Gruppen zusammenfasst, und dann laesst man Elemente einfach in die entsprechende Gruppe fallen. Oder man nimmt irgendein Koordinatensystem und skaliert dann entsprechend. Prinzipiell wuerde das also schon gehen.
Aber es nervt schon, dass Dialoge unter Windows prinzipiell nicht in der Groesse geaendert werden koennen. Ein grober Designfehler.
Eigentlich koennte man GUI-Designer heutzutage auf XHTML basierend entwickeln, in dem XML-Tags fuer Spezialcontrols und Code verwendet werden. Den Code koennte man ueber SCRIPT-Tags einbinden (mit einem entsprechenden Type-Attribut). DOM muss man ja nicht unbedingt verwenden, da es ja nur eingeschraenkte Moeglichkeiten bietet. CSS als Layoutunterstuetzung waere aber praktikabel. Oder man nimmt (wie Microsoft anscheinend) einen spezialisierten XML-Dialekt.
Weder der Win32 API, noch die MFC, noch OLE/COM, COM+ oder DCOM, noch ATL sind in der Vergangenheit hinreichend gut benutzt oder ausgereizt worden, auch von Microsoft selber nicht. Die vielen undokumentierten Type Libraries fuer COM, die mit Windows XP mitgeliefert werden, sprechen Baende. Es waere frueher schon moeglich gewesen, viel maechtigere Anwendungen zu erstellen, haette Microsoft diese dokumentiert. Auch ein weniger vergurktes Konzept fuer MFC haette den Entwicklern sehr helfen koennen.
Anscheinend schafft es Microsoft erst jetzt, mittels .NET, den Entwicklern eine bessere Entwicklungsumgebung zur Verfuegung zu stellen (und das auch nur wegen der Konkurrenz durch Sun's Java).
Uebrigens: Der Maschinencode, den der Loader der CLR erzeugt, kann nicht besonders gut sein, da CLR-Code (wie Java) stackbasiert ist und sich daher schlecht optimieren laesst (siehe Aho / Sethi / Ullman's Buch "Compilers").
Die Idee eines Loaders, der auf den vom Benutzer verwendeten Prozessor hin optimiert, ist an sich aber eine gute Idee.
-
Gut, wobei die Firefox-Dialoge auch mal ziemlich doof aussehen, wenn die Buttons plötzlich 2 km breit werden...
-
dEUs schrieb:
Das komische ist nur: die xaml-Dateien werden von einem "Präprozessor" in ganz normale cs-Dateien übersetzt, die dann mit den bereits vorhandenen kompiliert werden.
Ich dachte MS hat einen dynamischen Ansatz gewählt, so wie bei GTK die libglade(mm)Archi schrieb:
Die WinAPI wird nicht verschwinden, warum auch? Es gibt keinen plausiblen Grund. Nur weil sie unschön ist? Ist ja blödsinnig!
Die WinAPI ist überladen und kaum wartbar. Sie ist veraltet und entspricht nicht mehr den Interessen von Microsoft. Das sind genug Gründe, warum sie in den nächsten Jahren verschwinden oder an Bedeutung verlieren wird. Windows hat ja auch kein DOS Support oder 16Bit System mehr.
dEUs schrieb:
Dann versteh ich's garnicht mehr, welchen Sinn das haben soll.
Eigentlich dachte ich, dass der Vorteil ist, dass Layout und Code komplett getrennt werden. So das man zum Beispiel die GUI einfach anpassen kann ohne das Programm neu zu kompilieren oder das man die gleiche GUI nehmen kann und den Code in einer anderen Sprache schreibt. So wie das mit Glade/Libglade bei GTK abläuft. Qt hat glaube ich auch so etwas. Oder das was Mozilla da benutzt.
Nur das mit dem Preproc verwirrt micht jetzt.User_t schrieb:
Soweit ich weiss gibt es so etwas bereits für den LCC - *omg* eine WinAPI, welche auf .Net basiert, welches im Moment noch aug WinAPI basiert
.@Optimizer
ja, fixed-Position nerven. Aber das hat ja nichts mit dem GUI Designer zu tun, da viele GUI Designer ja auch das Container Model unterstützen, nur die meisten Coder (!) verstehen das Prinzip wohl nicht.@Power Off
Was du meinst ist doch genau das worauf XAML abzielt.
-
User_t schrieb:
.NET übersetzt sämtliche verwendete Klassen beim ersten Laden in Maschinencode
Widerspricht das meiner Aussage?
Genau das was Java macht. Nennt sich JIT
Verwendet Java deswegen keine VM?
-
Artchi schrieb:
Die WinAPI wird nicht verschwinden, warum auch? Es gibt keinen plausiblen Grund. Nur weil sie unschön ist? Ist ja blödsinnig!
Hang zum Sadomasochismus?
-
Ihr solltet euch mal überlegen überwelchen Zeitraum wir hier sprechen.
Die WINAPI wird sicher noch in LONGHORN drin sein. Bzw. Werden Programme auf Longhorn laufen welche mit WINAPI programmiert wurden.
Sonst würde ja kein Programm mehr funktionieren.
Die Winapi ist Bestandteil jeden Programmes unter Windows.Bis zum Nachfolger von Longhorn bin ich sowieso in Pension.
-
Natürlich wird die WIN-API noch in Longhorn vorhanden sein. Aber sie wird nur noch ein Kompatibilitätslayer sein. Die wirkliche API wird die .NET sein.
-
Unix-Tom: Das ist doch auch nicht mehr so lang. Hab leider den Termin von Blackcomb nicht mehr im Gedächtnis.