WinAPI vs. .NET
-
die frage wurde bestimmt nur zu oft gestellt, aber ich will nicht die vor und nachteile wissen ,sondern will wissen, ob die WinAPIs zukunftsfähig sing?, oder denkt ihr das Microsoft voll auf die .NET Programmierung umsteigen wird(WINDOWS VISTA ect...)?
Ich mein ich programmiere jetzt gut sein einem jahr mit den WinAPIs, und langsam bekom ich den eindruck (vorallem durch internet berichte..) das es Microsoft am liebsten wäre, wenn jeder seine Programme (zumindest für Windows) mit dem .NET Framework schreibt ? kann sein das ich mich irre...aber...ich will nunmal wissen ob es sinn macht auf WINDOWS FORMS mit .NET umzu steigen? ich persönlich verachte die windows forms mit .NET etwas, weil es meiner meinung nach "zu einfach" ist...und man weniger machen kann damit...und man immer .NET Framework dafür benötigt
Das ist doch keine Verbessrung ...also was meint ihr dazu ?
mfg
-
Foxx90 schrieb:
die frage wurde bestimmt nur zu oft gestellt, aber ich will nicht die vor und nachteile wissen ,sondern will wissen, ob die WinAPIs zukunftsfähig sing?, oder denkt ihr das Microsoft voll auf die .NET Programmierung umsteigen wird(WINDOWS VISTA ect...)?
Nein. Die WinAPI ist Grundlegender Bestandteil eines jeden Windows-OS (ja, auch von Vista).
Das .NET-Framework ist (auch in Vista) nur ein Aufsatz auf die WinAPI.Foxx90 schrieb:
das es Microsoft am liebsten wäre, wenn jeder seine Programme (zumindest für Windows) mit dem .NET Framework schreibt ?
Ja. Den Eindruck habe ich auch. Das heisst aber noch lange nicht, dass es das andere nicht geben wird. Es geht eigentlich nur um eines: Sicherheit. .NET (oder besser gesagt die CLR) ist eine "sichere" Platform (oder besser gesagt: absicherbare Platform), was man von unmanaged code nicht gerade sagen kann.
Foxx90 schrieb:
ob es sinn macht auf WINDOWS FORMS mit .NET umzu steigen?
Kurzfristig mag dies sinn machen, aber mittelfristig wird dies ja auch durch Avalon abgelöst, deshalb ist nach heutiger sicht die einzig zuverlässige Platform MFC. Wenn sich der ganze .NET-Umbruch etwas beruhigt hat, kann man ja dann auf das umscwenken, was dann der Standard ist...
-
Foxx90 schrieb:
ich persönlich verachte die windows forms mit .NET etwas, weil es meiner meinung nach "zu einfach" ist
Interessanter Standpunkt
-
naja ich denk mal ihr wisst was ich meine mit "einfach" naklar .NET ist auch ziemlich umfangreich ...
aber...es ist auch viel mit dem "DESINGER MODUS" möglich...für mich persönlich nicht das richtige und @ Jochen Kalmbach :
was genau ist der unterschied von unmanaged und managed code? also ich mein was macht das eine sicherer als das andere ?
mfg
-
Ne tut mir leid,verstehe ich überhaupt nicht.Jede Arbeit die mir abgenommen wird ist eine gute Arbeit.
Jeder Windowsprogrammierer sollte imho mal was mit WinAPI gemacht haben,aber produktives Arbeiten sieht im Jahre 2006 sicherlich anders aus.Gruß Spacelord
-
Spacelord schrieb:
Jeder Windowsprogrammierer sollte imho mal was mit WinAPI gemacht haben,aber produktives Arbeiten sieht im Jahre 2006 sicherlich anders aus.
Sehe ich ähnlich. Wenn ich an die alptraumhaften Erfahrungen denke, die man macht, wenn man halbwegs nett aussehende Dialoge mit der WinAPI zaubern will, so kann man für .NET nur dankbar sein... für Frontends und Visualisierungen sehe ich das zur Zeit unter Windows als erste Wahl. Selbst die MFC ist eine Zumutung, man schaue sich das nur an, MS bringt mit jedem Office immer elegantere Features in die Oberflächen, wie soll man sowas auch nur halbwegs mit der MFC hinbekommen, ohne daß man sich alles mögliche zusammensucht oder selbst macht?
Ich sage mal, mit WinAPI-Programmierung kann man aufhören, sobald man das Funktionsprinzip von Handles, Threads und der Messagequeues verstanden hat.
-
Foxx90 schrieb:
naja ich denk mal ihr wisst was ich meine mit "einfach"
Ne, erklaer mal.
Also ich habe noch nicht soviel mit WinForms gemacht, aber es hat sich nicht schlecht angefuehlt. Hat alles gut geklappt, LayoutManager war ok. Naja, bin nie wirklich tief eingetaucht. Aber erklaer echt mal genauer.
was genau ist der unterschied von unmanaged und managed code? also ich mein was macht das eine sicherer als das andere ?
Managed Code machts schwerer dir den ganzen Fuss wegzuschiessen :p
Der Code wird nicht direkt in Maschinencode kompiliert sondern in einen ByteCode bei .NET
Dieser wird dann von der Runtime Environment ausgefuehrt - primitiv gesagt: interpretiert. Praktisch gesehen liegen welten zwischen interpretern und .NET/Java aber so kann man es sich leichter vorstellen.
Und dadurch bist du sicherer. Weil du einfach gewisse sachen nicht machen kannst bzw. immer alles ueberprueft wird. Was zB pointer manipulation, casts, etc. betrifft.
Grosses Buzzword ist hier Buffer Overflow Protection
-
PS: Ich habe nicht gesagt das MFC die beste Wahl ist... aber mit dem ganzen Umbruch, der gerade ständig in .NET stattfindet (ab Nov. ist dann die Empfehlung wohl WPF (Avalon v1), wird es Windows-Forms zwar noch geben, aber wohl eher zukünftig ein Schattendasein führen... die MFC wird AFAIK hingegen mit Orcas nochmals kräftig erweitert...
Die MFC ist vom Konzept her schlecht und ich würde auch niemandem Empfehlen neue Programme mit der MFC zu machen; wer aber heute schon MFC hat, der sollte jetzt nicht unüberlegt nach Windows-Forms wechseln...Mein persönliches Fazit:
- Für neue Programme WPF (Avalon v1)
- Für bestehende MFC-Programme: Vorerst mal bei MFC bleiben...PS: Ich habe seit 2001 ein relativ grosses Projekt mit Windows-Forms angefangen und auch 2003 ausgeliefert (und wird heute noch weiterentwicklent/gepflegt) und es was 100%ig die Richtige Entscheidung. Heute würde ich aber für neue Dinge Avalon verwenden.
-
Marc++us schrieb:
Sehe ich ähnlich. Wenn ich an die alptraumhaften Erfahrungen denke, die man macht, wenn man halbwegs nett aussehende Dialoge mit der WinAPI zaubern will, so kann man für .NET nur dankbar sein...
Wie sieht denn ein netter Dialog aus? Haben die nicht immer Text, Eingabefelder und Buttons? Die bekommt man doch auch einfach mit WINAPI hin.
-
ich hab auch überlegt ob ich .net oder winapi als erstes lerne.
was ich mich immernoch frage ist, ob es mit .net einfacher oder schwerer oder überhaupt möglich ist, auf directx oder opengl zuzugreifen.
wie sieht das ganze in dem fall aus? vielleicht hat da jemand erfahrungen mit.
würde mich mal interessieren ob directx oder opengl besser mit winapi oder .net programmiert wird oder ob das egal ist. (hab noch so gut wie nichts gemacht mit beiden grafikapis...)
-
?????? schrieb:
Wie sieht denn ein netter Dialog aus? Haben die nicht immer Text, Eingabefelder und Buttons?
Jaja,aber manchmal enthalten die auch DataGridViews etc.
?????? schrieb:
Die bekommt man doch auch einfach mit WINAPI hin.
Man bekommt alles mit WinApi hin.Die Frage ist nur wieviel Aufwand man dafür betreiben möchte.
Gruß Spacelord
-
DataGridView == Viele Textfelder und ComboBoxen nebeneinander
-
Amateur schrieb:
ich hab auch überlegt ob ich .net oder winapi als erstes lerne.
was ich mich immernoch frage ist, ob es mit .net einfacher oder schwerer oder überhaupt möglich ist, auf directx oder opengl zuzugreifen.
wie sieht das ganze in dem fall aus? vielleicht hat da jemand erfahrungen mit.
würde mich mal interessieren ob directx oder opengl besser mit winapi oder .net programmiert wird oder ob das egal ist. (hab noch so gut wie nichts gemacht mit beiden grafikapis...)Wenn ich WinAPI überhaupt lernen würde, dann würde ich an deiner Stelle erst mal mit was anderem Anfangen. Die WinAPI ist eben sehr komplex, umständlich und in einem grauenhaften Stil. Es bringt wohl nur etwas sich damit ausseinander zu setzen, wenn man die Details von Windows kennen will.
DirectX kannst du wohl mit .NET nutzen. Wie es mit OpenGL aussieht weiß ich nicht. Wobei es sich dann vermutlich eh eher lohnt was simples zu benutzen um OpenGL zu initialisieren. Zum Beispiel die SDL.
Aber im Grunde ist es wichtig ein solides Basis wissen zu schaffen, bevor man etwas in dem Bereich macht.
-
Jochen Kalmbach schrieb:
Die WinAPI ist Grundlegender Bestandteil eines jeden Windows-OS (ja, auch von Vista).
Das .NET-Framework ist (auch in Vista) nur ein Aufsatz auf die WinAPI.Ich finde, das kann man ruhig ein bisschen abstrakter betrachten. Das Win32 API und die Base Class Library des .Net Framework sind erstmal beides nur APIs. Es spielt gar keine Rolle, ob jetzt gerade das eine durch das andere implementiert wird oder nicht. Es ist auch möglich, das Win32 API durch die BCL zu implementieren. Das Win32 API wird in Zukunft nicht mehr weiterentwickelt, sondern nur weiterhin in neuen Betriebssystemen implementiert - irgendwann wird es vielleicht gar nicht mehr implementiert. Neue APIs wie die WPF bauen gar nicht mehr auf dem Win32 API auf.
So ein wichtiger Bestandteil ist das Win32 API also nicht. Es ist eine veraltete Schnittstelle zu den Betriebssystemfunktionen, let's face it.
-
Optimizer schrieb:
Jochen Kalmbach schrieb:
Die WinAPI ist Grundlegender Bestandteil eines jeden Windows-OS (ja, auch von Vista).
Das .NET-Framework ist (auch in Vista) nur ein Aufsatz auf die WinAPI.Ich finde, das kann man ruhig ein bisschen abstrakter betrachten. Das Win32 API und die Base Class Library des .Net Framework sind erstmal beides nur APIs. Es spielt gar keine Rolle, ob jetzt gerade das eine durch das andere implementiert wird oder nicht. Es ist auch möglich, das Win32 API durch die BCL zu implementieren. Das Win32 API wird in Zukunft nicht mehr weiterentwickelt, sondern nur weiterhin in neuen Betriebssystemen implementiert - irgendwann wird es vielleicht gar nicht mehr implementiert. Neue APIs wie die WPF bauen gar nicht mehr auf dem Win32 API auf.
Da irrst Du Dich aber gewaltig! Wie könnte denn Avalon funktionieren, wenn das OS es nicht unterstützen würde? Und das OS ist zu 100% native (also es wird die WinAPI benötigt).
Das wird sich erst ändern wenn wir ein OS bekommen, welches auf der CLR basiert... (z.B. Singularity)
-
hoho, meine frage löst häftige diskusionen aus
also @ Shade Of Mine :
Ich meine mit Einfach, dass es nicht sehr schwer ist z.B. einen voll funktions tüchtigen Browser zu schreiben mit .NET(natürlich ohne Plugins
)! Außerdem hab ich bei .NET das Gefühl, das nur die wichtigsten Funktionen enthalten sind (verbessert mich wenn nötig!)
Außerdem, nach ein Jahr WinAPI ist das auch garnich mehr sooo undurchsichtig...
Ok, also würde es demnach Sinn machen auf .NET um zusteigen ?@ Amatuer :
Es gibt für .NET basierende Programme, das managed DirectX, (hab ich ca 2 monaste mal benutzt, jetzt benutze ich aber wieder OpenGL, weil es vollkompatibel zu Linux ist, und nach einigen Meinungen, immernoch etwas schneller ist...außerdem braucht man für das Compilieren Das DIRECT-X-SDK...
@ Jochen KalmBACH:
Was ist Avalon ??? Hab ich noch nie gehört ? Hat das was mit C++ zu tun ?
mfg
-
Jochen Kalmbach schrieb:
Da irrst Du Dich aber gewaltig! Wie könnte denn Avalon funktionieren, wenn das OS es nicht unterstützen würde?
Wo ist das Problem? Was passiert denn, wenn du ein Windows-Fenster (<- lol) aufmachst? Es wird irgendwo in eine Liste im Fenstermanager eingetragen. Es wird festgestellt, wann es neu gezeichnet werden muss, es wird irgendeine Schnittstelle (z.B. Direct3D oder GDI) zum Grafikkarten-Treiber verwendet, um das Fenster schließlich zu zeichnen.
Ein noch einfacheres Beispiel wäre File I/O. Wie sieht der Zugriff auf eine Datei im Moment aus?
.Net-Anwendung
Base Class Library
Win32 API
Dateisystem-Treiber
Und es gibt keinen einzigen technischen Grund, warum die BCL nicht selber den Dateisystem-Treiber über seine standardisierte Schnittstelle ansprechen kann! Es wäre nur reichlich dämlich, die Arbeit 2mal zu machen, deshalb wrappt man lieber das Win32 API, weil es halt schon implementiert ist.
-
Foxx90 schrieb:
Ich meine mit Einfach, dass es nicht sehr schwer ist z.B. einen voll funktions tüchtigen Browser zu schreiben mit .NET(natürlich ohne Plugins
)! AußerdemBekomm ich auch ohne .NET hin
-
@ =====????????? : OMG, natürlich als Anfänger GRR,
ich kann auch mit den WinSockets unter WinAI nen Browser machen darum gehts nicht, man kann las Anfänger mit 2 Tagen übung, nen Browser machen, vlt keinen Schönen,aber man muss z.B. nicht wie bei WinAPI den ganzern Rest können , "wissen was messages sind, wie man sie benutzt, was dialoge sind (ok das muss man auch für .NET wissen), Man muss die WinClass verstehen um richtige Fenster (CHILD FENSTER) zu erstellen, ... und das ist auf jeden Fall um einiges schwerer als sowas mit .NET zu machen !!
-
Optimizer schrieb:
Ein noch einfacheres Beispiel wäre File I/O. Wie sieht der Zugriff auf eine Datei im Moment aus?
.Net-Anwendung
Base Class Library
Win32 API
Dateisystem-Treiber
Und es gibt keinen einzigen technischen Grund, warum die BCL nicht selber den Dateisystem-Treiber über seine standardisierte Schnittstelle ansprechen kann! Es wäre nur reichlich dämlich, die Arbeit 2mal zu machen, deshalb wrappt man lieber das Win32 API, weil es halt schon implementiert ist.
Du hast glaube ich das Konzept von Windows nicht so ganz verstanden... die WinAPI *ist* die Schnittstelle zu Windows. Es gibt nix anderes! Du kansnt nicht direkt einen Treiber ansprechen (zumindest nicht dokumentiert).
Fazit: Die WinAPI ist die einzige Schnittstelle zu Windows und somit muss jeder diese verwenden. Sei es nun .NET oder sonstige Dinge...
-
Foxx90 schrieb:
Ich meine mit Einfach, dass es nicht sehr schwer ist z.B. einen voll funktions tüchtigen Browser zu schreiben mit .NET(natürlich ohne Plugins
)!und das ist schlecht weil... ?
Außerdem hab ich bei .NET das Gefühl, das nur die wichtigsten Funktionen enthalten sind (verbessert mich wenn nötig!)
naja, ist doch gut wenn keine unwichtigen funktionen da sind, oder?
ne, .NET ist ziemlich umfangreich, ich wuesste jetzt so spontan nicht was mir da fehlt...
Ok, also würde es demnach Sinn machen auf .NET um zusteigen ?
definitiv.
winapi ist nur da um windows besser kennenzulernen. wirklich damit entwickeln ist horror.