WinAPI-Ersatz in Windows Longhorn
-
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 ?
-
MasterCounter schrieb:
wie stehts dann mit den MFC ?
Ebenso. Wenn man sie beruflich noch einsetzen muss, OK. Lernen würde ich die MFC _jetzt_ aber nicht mehr.
-
Walli schrieb:
MasterCounter schrieb:
wie stehts dann mit den MFC ?
Ebenso. Wenn man sie beruflich noch einsetzen muss, OK. Lernen würde ich die MFC _jetzt_ aber nicht mehr.
Ja, das muss ich sogar als MFC-Mod zugeben. Ich würde heutzutage keinem mehr empfehlen MFC zu lernen, obwohl ich der Überzeugung bin, dass es im Geschäftsbereich noch über viele Jahre eingesetzt wird, da viele Anwendungen sie benutzen und vermutlich die wenigsten ihren Code auf .NET portieren. Außer die Firma hat zu viele freie Resourcen.
-
also dann, auf zu .NET! kennt da jemand ne site auf der man sich mal ausgiebig darüber informieren kann, nach Möglichkeiut auf deutsch? Und was ist das mit c# braucht man das für .NET oder geht das auch noch mit c/c++?