WinAPI vs. .NET
-
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.
-
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).
-
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.
-
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...
-
Jochen Kalmbach schrieb:
@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?
Ich rede nicht von in .Net geschriebenen Treibern. Ich rede davon, dass auch .Net-Anwendungen alle Freiheiten haben, über das Kernel-API (das durchaus dokumentiert ist) direkt mit Treibern (und anderen) zu kommunizieren und damit die BCL "direkt" zu implementieren. Es ist eine Frage der Berechtigungen, nichts weiter. Kein normales Anwendungsprogramm darf direkt mit dem Dateisystemtreiber reden, aber das ist kein technisches Problem. Wenn etwas installiert ist, um in einem weniger eingeschränkten Sicherheitsring zu laufen, ist alles weitere kein Problem. Und dieses etwas ist das Win32 API und könnte auch das .Net API sein.
Und du hast es ja jetzt anscheinend selber schon so gesehen:
Das .NET könnte logischerweise auch direkt auf das native OS zugreifen, müsste dann aber die WinAPI "nachbauen"...
Und schließlich geht es um nichts anderes, als das Windows API nachzubauen, mit einer schöneren Schnittstelle nach außen halt.
Ich warte immer noch auf Singularity. Dann sind wir endlich da wo alle hinwollen...
Kommt wahrscheinlich in hundert Jahren, aber begeistern würde es mich auch.
-
ähmm, ok also demnach ist es sinnvoll .NET zu lernen , aber man kann demnach immernoch für die nächsten jachre mit den WinAPI programmieren ?
mfg
-
Jochen Kalmbach schrieb:
Die WinAPI ist somit nur eine "Vereinfachung" für den Zuigriff auf das OS.
exakt.
nur beisst sich das doch irgendwie mit
Fazit: Die WinAPI ist die einzige Schnittstelle zu Windows und somit muss jeder diese verwenden. Sei es nun .NET oder sonstige Dinge...
warum kann die BCL nicht ebenfalls eine "Vereinfachung" fuer den Zugriff auf das OS sein? Rein theoretisch gesprochen. Wie die BCL tatsaechlich implementiert ist weiss ich nicht.
Aber theoretisch koennte sie genau wie die WinAPI direkt auf der Native API aufsetzen.
Ob es Sinn macht sei dahin gestellt. Aber die WinAPI ist nur ein Layer der ueber der Native API liegt. NT ist so konzipiert dass es verschiedene System APIs anbieten kann. Die WinAPI ist eine davon. Und die BCL koennte ebenfalls so ein Layer sein der auf der selben Ebene wie die WinAPI liegt.
Und Microsoft war klug beim Designen der API, so dass im Prinzip nichts dagegen spricht irgendwann mal bei Windows 2010 oder so die WinAPI ueber die BCL zu implementieren.
-
Foxx90 schrieb:
ähmm, ok also demnach ist es sinnvoll .NET zu lernen , aber man kann demnach immernoch für die nächsten jachre mit den WinAPI programmieren ?
Microsoft wird vermutlich nie den Bruch machen und sagen "ab jetzt geht WinAPI nicht mehr". Denn der riesen Vorteil von Windows ist einfach der: du hast ein Programm und das laeuft einfach. Wenn es auf Win95 laeuft, dann laeuft es genauso auf Windows Vista. Diese Kompatibilitaet hat Microsoft sehr viel gekostet - wuerde mich stark wundern wenn sie es aufgeben wuerden.
Was dir aber passieren kann ist, dass die WinAPI nciht mehr weiterentwickelt wird. Du also zB neue Funktionen des OS nicht mehr ansprechen kannst.
-
Soso, kennt jemand gute Tutorials für VC# ??
-
Foxx90 schrieb:
Soso, kennt jemand gute Tutorials für VC# ??
C#?
willst du jetzt ne neue Sprache lernen weil du das Toolkit wechselst?
Kannst auch weiter C++ programmieren... Nennt sich dann C++/CLI
-
nene ich will schon auf der WinAPI schiene bleiben, aber trotzdem will ich mich da mal kurze zeit einarbeiten um mitreden zu können
DAs was ich damals gemacht hatte mit VC# begrentzte sich auf grafik programmeirung...mit managed DirectX...aber nichst in bezug auf steuer elemente oder ähnlichemmfg
-
nochmal:
du kannst auch mit C++ .NET anwendungen schreiben