WinAPI-Ersatz in Windows Longhorn
-
.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...
-
Ich will dir nur sagen, dass du dich nicht einfach so naiv festlegen sollst. Arbeite mit vielen breitgefächerten Dingen, dass bringt dir viel mehr.
Wobei es natürlich absolut zu empfehlen ist, die WinAPI nicht zu benutzen, gerade als Anfänger.
-
naja, anfänger bin ich nicht mehr, hab auch schon einiges mit der WinAPI gemacht
(siehe meine Homepage: www.mscoder.de.tt ). Aber nicht dass das mit .NET nur so eine Phase ist und man das gar nicht braucht, wenn man die WinAPI kennt...
Warum sollte man die WinAPI nicht benutzen?
-
MasterCounter schrieb:
Aber nicht dass das mit .NET nur so eine Phase ist und man das gar nicht braucht, wenn man die WinAPI kennt...
Wer sagt das denn? Man sollte sich halt nicht _nur_ auf .NET fixieren.
MasterCounter schrieb:
Warum sollte man die WinAPI nicht benutzen?
Weil sie überholt ist und über kurz oder lang von der Bildfläche verschwinden wird.
-
wie stehts dann mit den MFC ?