3. WinAPI vs. .NET

WinAPI vs. .NET

  • J

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

    0
  • ?

    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.

    0
  • F

    ä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

    0
  • S

    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.

    0
  • S

    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.

    0
  • F

    Soso, kennt jemand gute Tutorials für VC# ??

    0
  • S

    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

    0
  • F

    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 ähnlichem 😉

    mfg

    0
  • S

    nochmal:

    du kannst auch mit C++ .NET anwendungen schreiben

    0
  • J

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

    0
  • ?

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

    0
  • J

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

    0
  • F

    @ 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

    0
  • S

    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.

    0
  • F

    hi, reichen für die Programmierung mit .NET die VS 2005 EXPRESS versionen, oder muss man sich die standart versionen kaufen ?

    mfg

    0
  • J

    Für .NET reicht die EE aus. Hier würde ich aber eher zu C# raten als zu C++/CLI (ausser Du machst viel Interop).

    0
  • M

    Hi,

    @Jochen Kalmbach: Soweit ich das mitbekommen habe, wird die WinAPI nicht mehr weiterentwickelt, allerdings weiter unterstützt. Wie man an der Tatsache sehen kann, dass selbst 16-Bit Anwendungen noch in den allermeisten Fällen unter heutigen Microsoft Betriebssystem lauffähig sind, bemüht sich Microsoft sehr um Abwärtskompatibilität. Somit wird die WinAPI vermutlich noch in zehn Jahren Teil der Windows Betriebssysteme sein, aber dass du mittels dieser Schnittstelle dann noch auf die neuesten Betriebssystemfunktionalitäten zugreifen kannst, das bezweifle ich. Man möge mich korrigieren sofern ich mich irre.

    Ferner sind die WinAPI und .NET überhaupt nicht vergleichbar.
    .NET ist ein modernes Unternehmensframework, und die WinAPI bietet eben die rohen Schnittstellen. Genausowenig wie die Systeme kann man die Entwicklung darin vergleichen:
    Das .NET Framework ist extrem umfangreich, mit sicheren Konzepten zur Windows- und Webentwicklung. Vollständige Internationalisierungskonzepte, eine hohe Datenabstraktion, automatisiertes Data Binding sind nur ein paar der Features, die .NET in meinen Augen so wertvoll macht.
    Wie bereits gesagt wurde wäre es nicht sinnvoll, in der heutigen Zeit mit der WinAPI effektiv größere Geschäftslösungen programmieren zu wollen.

    @Foxx90: .NET ist optimiert auf die Entwicklung von Geschäftslösungen und gängigen Desktopanwendungen sowie Webanwendungen. Wenn du in einem dieser Bereiche weiterkommen willst, wäre die WinAPI zumindest als primäre Entwicklungsplattform die falsche Wahl. Allerdings wäre es für dich vllt. recht interessant, die interne Struktur von Windows durch die WinAPI besser kennenzulernen.
    Falls du eher schnelle Echtzeitanwendungen die auf Hochleistungsgrafik setzen entwickeln willst, würde ich an deiner Stelle die WinAPI verwenden in Kombination mit OpenGL bzw. DirectX.
    Wobei ich um ehrlich zu sein keine Erfahrung mit Managed DirectX habe was Performance angeht.

    0
  • J

    marco.b schrieb:

    @Jochen Kalmbach: Soweit ich das mitbekommen habe, wird die WinAPI nicht mehr weiterentwickelt, allerdings weiter unterstützt.

    Woher hast Du das mitbekommen? Es gibt keinerlei Quellen dazu, ausser das kommende Vista und dort wurde sie selbstverständlich weiterentwickelt, was Du ja auch selber sehen kannst wenn Du Vista installeirst...

    marco.b schrieb:

    Man möge mich korrigieren sofern ich mich irre.

    In Zeiten wie "10 Jahre" will ich gar nie reden.

    marco.b schrieb:

    Ferner sind die WinAPI und .NET überhaupt nicht vergleichbar.

    Was glaubst Du was .NET-Fenster sind? Genau: Win32-Fenster. Mit der Glass-Oberfläche bleiben es auch Win32-Fenster, obwohl sie durch DirectX gerendert werden...

    marco.b schrieb:

    .NET ist ein modernes Unternehmensframework, und die WinAPI bietet eben die rohen Schnittstellen.

    Endlich mal 100% richtig!

    marco.b schrieb:

    Wie bereits gesagt wurde wäre es nicht sinnvoll, in der heutigen Zeit mit der WinAPI effektiv größere Geschäftslösungen programmieren zu wollen.

    Full ack!

    0
  • M

    Woher hast Du das mitbekommen? Es gibt keinerlei Quellen dazu, ausser das kommende Vista und dort wurde sie selbstverständlich weiterentwickelt, was Du ja auch selber sehen kannst wenn Du Vista installeirst...

    Ich glaube es war eine Seite wie heise oder Golem. Ich bin mir nicht zu 100% sicher, aber ich google mal danach, falsche Tatsachen will ich auch nicht in den Raum stellen. Ich bin mir aber wie gesagt ziemlich sicher.

    Was glaubst Du was .NET-Fenster sind? Genau: Win32-Fenster. Mit der Glass-Oberfläche bleiben es auch Win32-Fenster, obwohl sie durch DirectX gerendert werden...

    Was haben denn Win32-Fenster mit der jetzigen WinAPI zu tun?
    Es könnte genauso gut eine modernere Lowlevelschnittstelle implementiert werden die ebenso Win32 Fenster darstellen kann. Das wäre dann ebenso eine Entwicklerschnittstelle, aber wir sprechen ja von der jetzigen WinAPI wie sie mit aktuellen Betriebssystemen ausgeliefert wird.
    Tatsache ist dass es keinen Grund der Welt gibt der Microsoft daran hindern würde die jetzige WinAPI über Board zu kicken. Ob dies letztendlich getan wird steht auf einem anderen Blatt.

    Endlich mal 100% richtig!

    🙄

    0
  • Z

    Windows Vista contains over 4000 new Win32 style APIs so it's safe to assume that Microsoft will continue to support and possibly expand Win32 for years to come.

    Lori Pearce

    Windows SDK Team

    Ich glaub die bisherige NT-Windowssysteme werden immer Win32-API haben, erst wenn Microsoft experiementelles OS erfolgsversprechend wird, dann kann Microsoft sich überlegen Win32-Api in den Grab zu tragen. Aber zur Zeit sieht es eher so aus, dass Microsoft lieber native System-Subsysteme über WinAPI32 anspricht und zu den Anwendungsentwickler prädigt, entwicklert auf .NET da ist eine schöne ManagedWelt und die Performance ist super,(wahrscheinlich weil .NET win32api anspricht).

    0
Anmelden zum Antworten