WinAPI vs. .NET
-
@ =====????????? : 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
-
Shade Of Mine schrieb:
Was dir aber passieren kann ist, dass die WinAPI nciht mehr weiterentwickelt wird. Du also zB neue Funktionen des OS nicht mehr ansprechen kannst.
Mir ist noch keine Funktion bekannt die nur via CLR und nicht via WinAPi erreichbar wäre... bitte mal Beispiele!
@Foxx90: Wenn Du rein .NET machst, rate ich Dir zu C#
C++/CLI kann ich nur empfehlen, wenn Du Dich schon *gut* mit C++ auskennst, sonst wirst Du sehr schnell frustriert, weil Du die Unterschiede nicht kennst und Dich nur darüber aufregst, warum ein "String" kein "string" ist...
-
Mir ist noch keine Funktion bekannt die nur via CLR und nicht via WinAPi erreichbar wäre... bitte mal Beispiele!
Lies dir einfach den Satz noch ein paar Mal durch, denn vielleicht fällt dir dann ja auf, warum du gerade, bzw. dass du gerade Blödsinn geschrieben hast. Als kleine Hilfestellung: Achte auf die Zeit.
-
PS: Das lässt sich aktuell ganz einfach nachweisen, dass weder .NET 1.0 / 1.1 / 2.0 noch 3.0 irgend eine native API direkt verwendet: die mscroee.dll hat keine Referenz auf ntdll.dll...
-
@ Shade Of Mine:
Schon klar das man damit auch Anwendungen in C++ schreiben kann...Und was ist (wenn man einen job findet) am häufigsten vertreten ? WinAPI oder doch schon die .NET Bibliothek, oder dann doch Avalon?
mfg
-
Jochen Kalmbach schrieb:
Shade Of Mine schrieb:
Was dir aber passieren kann ist, dass die WinAPI nciht mehr weiterentwickelt wird. Du also zB neue Funktionen des OS nicht mehr ansprechen kannst.
Mir ist noch keine Funktion bekannt die nur via CLR und nicht via WinAPi erreichbar wäre... bitte mal Beispiele!
Noch gibt es sowas nicht. Aber je nachdem welche Strategie Microsoft verfolgt werden die vielleicht nicht 2 oder mehr System APIs konstant erweitern wollen und die WinAPI irgendwann einfrieren.
Deshalb ja auch "was dir passieren kann" - moeglich aber auch dass das nicht passiert. Ich wuerde dennoch langfristig nicht auf WinAPI setzen.
@Foxx90:
nochmal:
die WinAPI ist zum lernen und besser kennenlernen von Windows da. Effektiv programmiert wird fast nirgends. Deshalb wirst du eher einen Job als .NET Entwickler finden als als WinAPI programmierer. Aber du wirst des oefteren WinAPI kenntnisse noetig haben um mit anderen Tools Windows Programme zu schreiben - oder zumindest helfen sie.
-
hi, reichen für die Programmierung mit .NET die VS 2005 EXPRESS versionen, oder muss man sich die standart versionen kaufen ?
mfg