WinAPI-Ersatz in Windows Longhorn
-
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.
-
2011 oder 2012 IIRC
-
User_t schrieb:
.NET übersetzt sämtliche verwendete Klassen beim ersten Laden in Maschinencode
Widerspricht das meiner Aussage?
Selbstverständlich. Die CLR von .Net ist genau das selbe wie eine JVM und sogar der Bytecode, den beide einlesen, hat starke Ähnlichkeiten, zumindest bei einfacheren Code. Du hast also völligen Unsinn geredet, genau das Gegenteil der Realität, wenn du so willst.
-
Sorry, wenn das jetzt nicht so passt...
Aber lohnt es sich für mich als Hobby-Coder jetzt schon auf .NET etc. umzusteigen? Ich will später vielleicht auch mal Informatik studieren und da sollte man ja dann immer auf dem neuesten Stand sein
-
MasterCounter schrieb:
Aber lohnt es sich für mich als Hobby-Coder jetzt schon auf .NET etc. umzusteigen? Ich will später vielleicht auch mal Informatik studieren und da sollte man ja dann immer auf dem neuesten Stand sein
dann sollteste dir .NET mal ansehen. zur zeit ist es sehr beliebt. kann zwar sein, dass in 5 jahren keiner mehr was von wissen will aber das ist ja eine ewigkeit im schnellebigen it-bereich
-
kennst du darüber ne gute seite, wo man was darüber erfährt
tutorials, was das überhaupt genau ist, ...
-
@MasterCounter
Es gibt mehr als .NET und sich dogmatisch auf irgend etwas festzulegen ist naiv und dumm. Es gibt nicht _das_ System oder _die_ Programmiersprache.
-
ich will mich ja nicht festlegen, ich will meinen horizont erweitern im MOment programmiere ich nämlich nur mit der WinAPI was WIndows betrifft und finde dass man mit der schon ziemlich weit kommen kann...
Mach ja mein ABI erst in drei Jahren...