WinAPI vs. .NET

[Spacelord]

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

[Marc++us]

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.

[Shade Of Mine]

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

[Jochen Kalmbach]

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.

[Amateur]

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...)

[Spacelord]

?????? 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

[rüdiger]

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.

[Gast]

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.

[Jochen Kalmbach]

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)

[Foxx90]

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

[Gast]

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ßerdem

Bekomm ich auch ohne .NET hin

[Foxx90]

@ =====????????? : 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 !!

[Jochen Kalmbach]

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: Avalon ist (war) der Codename für WPF

[Shade Of Mine]

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.

[Gast]

Jochen Kalmbach schrieb:

die WinAPI *ist* die Schnittstelle zu Windows. Es gibt nix anderes! Du kansnt nicht direkt einen Treiber ansprechen (zumindest nicht dokumentiert).

Ich kann sogar meinen eigenen Treiber in den Kernel laden und ansteuern. Jeder Kernelmode-Debugger macht das, jedes Spiel mit Kopierschutz macht das bei der Installation auch. Ja, es gibt ein API, um Treiber zu laden. Nachteil: Man braucht halt Admin-Rechte, um die Treiber-Schnittstelle des Kernels beliebig nutzen zu dürfen.

Deshalb lädt man Treiber beim Systemstart und stellt dann für Anwendungen ein API zur Verfügung und schafft so die nötige Indirektion. Ein Beispiel dafür ist das Win32 API. Ein weiteres Beispiel ist Kopierschutz-Software, die dann für ein Spiel ein API bereitstellt, um die CD zu prüfen oder das Executable zu entschlüsseln. Wird einmal mit dem Spiel installiert, und steht den Anwendungen dann zur Verfügung.

Du brauchst für ein .Net-basiertes API auch keinen in .Net geschriebenen Kernel. Du brauchst lediglich die Fähigkeit, bestimmte Schnittstellen zum Kernel-API einzuhalten, die Bytes hin, die Bytes her. Eigene Treiber müsste man für die BCL sowieso nicht mehr schreiben, nur noch selber implementieren, wie sie mit den Treibern redet. Aber der Gewinn wäre null und der Aufwand immens. Das Win32-API ist bereits fertig, also benutzt man einfach das (im Moment jedenfalls, die Implementierung ist beliebig austauschbar).

[Shade Of Mine]

Jochen Kalmbach schrieb:

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).

Dieser "nicht dokumentiert" Zusatz ist aber essentiell.
Denn nicht dokumentiert kann ich sehr wohl an der WinApi vorbei programmieren. Die NT Serie arbeitet intern mit der sogenannten "Native API" und verwendet die WinAPI als oeffentliche Schnittstelle.

[Jochen Kalmbach]

Shade Of Mine schrieb:

Dieser "nicht dokumentiert" Zusatz ist aber essentiell.
Denn nicht dokumentiert kann ich sehr wohl an der WinApi vorbei programmieren. Die NT Serie arbeitet intern mit der sogenannten "Native API" und verwendet die WinAPI als oeffentliche Schnittstelle.

Das macht aber vom Konzept her keinen Unterschied. Es ist ein Bruch zwischen .NET (CLR) und native OS vorhanden. Das .NET könnte logischerweise auch direkt auf das native OS zugreifen, müsste dann aber die WinAPI "nachbauen"... Ein "CreateFileW" Aufruf muss dann immer noch genauso über diverse "native-APIs" erfolgen, die man dann halt selber aufrufen muss. Die WinAPI ist somit nur eine "Vereinfachung" für den Zuigriff auf das OS.

@Optimizer: Nein, Du kannst keine .NET-Treiber in den Kernel laden. Oder redest Du etwa von native Code? Was hat das dann mit Deiner Argumentation zu tun? Und Du hast dich anscheindend noch nicht mit Vista-x64 beschäftigt...

Ich warte immer noch auf Singularity. Dann sind wir endlich da wo alle hinwollen...