Allgemeine Fragen



  • Ich hab mich heute mal ein wenig mit .NET bzw C# befasst (d.h. Artikel darueber gelesen) und nun stellen sich mir einige grundlegende Fragen:
    (vieles davon mag schon oefters diskutiert sein, ich frag trotzdem direkt 🙄 )

    1. Verbindung zwischen .NET und C#
    Oft scheint es so, dass .NET und C# zusammen gehoeren. Offensichtlich wurde C# speziell fuer die .NET-Umgebung entwickelt, es wird allerdings mehrfach erwaehnt dass C# nicht die einzige Sprachalternative fuer NET ist. So kann auch mit VB.NET, J# und was weiss ich allem .NET-Code erzeugt werden. Was ich nicht rausgefunden habe ist ob mit C# nicht-NET-Code erzeugt kann, also ob es irgendeine andere Anwendung der Sprache gibt, als Microsofts Laufzeitumgebung.. bzw. ob C# ueberhaupt in Maschinencode kompiliert werden kann.

    2. Sicherheitsfeatures:
    Im Wikipedia-Artikel wird ein "Sicherheitskonzept" angesprochen. Jetzt bin ich mir unsicher ob damit Sicherheit im Sinne der Spracheigenschaften gemeint ist (so ist ein private-Zugriff auf Membervariablen ein "Sicherheitsfeature") oder ob beim Kompilieren zusaetzliche Daten in mein Programm geschrieben werden. Da auch von "AuthenzitÀt" gesprochen wird, geh ich mal vom 2. aus (*)

    3. Verbunden mit 2.: Sicherheit:
    Was mir auch nicht klar ist, ist die Sicherheit in Hinblick auf Reverse Engineering. Also eine Dekompilierung des Programms. Java, als Vorbild fuer eine in Bytecode kompilierte, unter einer Laufzeitumgebung ausgefuehrte Sprache macht da enorme Abstriche. Man kann jede class-Datei problemlos in eine .java-Datei dekompilieren, inklusieve aller Variablen- und Funktionsnamen. Ist das bei .NET auch der Fall? ? Und wenn nicht: Wie regelt .NET diese "Sicherheitsluecke" (die natuerlich nur als solche anzusehen ist wenn man auf propritÀren Quellcode besteht)

    4. Mangaged-C++ und C++/CLI
    Der naechste Stichpunkt der mir aus meiner Crashkurs-Literatur in Erinnerung geblieben ist lautet Managed-C++. "Managed" beschreibt einfach die Eigenschaft der (vom System) verwalteten Speicherfreigabe. So weit so gut. C++/CLI wird dann als eine Schnittstelle zur .NET-Umgebung beschreiben. Jetzt frag ich mich erneut: Kann man C++/CLI auch direkt, also ohne eine Anbindung an diese Umgebung benutzen und trotzdem den Komfort einer Speicherverwaltung geniessen, oder kann der C++/CLI-Code nur in Byte-Code fuer die Laufzeitumgebung kompiliert werden ?
    Weiterhin frag ich mich, ob Managed-C++ und C++/CLI nicht ziemlich identisch sind und sich nur syntaktisch unterscheiden.
    Entsprechend stellt sich dann auch die Frage: Wenn C++/CLI eine "Verbesserung" von Managed-C++ ist, ist C# nicht wiederrum als eine Verbesserung von C++/CLI's anzusehen ? WO genau liegen da die Unterschiede ?

    5. "Rechte" und Zukunft der Programmierung
    Wovon ich auch gelesen habe ist eine Rechteverwaltung. Programme sollen nicht ohne weiteres Zeiger verwenden koennen, ein .NET-Programm hat eingeschraenkte Zugriffsrechte. Wovon genau diese Rechte abhaengen ist mir unklar, ich nehme an vom Benutzer.
    Ich bin mir nicht sicher, glaube aber mich zu erinnern dass die Java-VM von Microsoft sowas in der Art macht: Will ein Java-Programm einen Schreibzugriff auf der Festplatte vornehmen erscheint ein Dialogfenster das den Benutzer fragt ob dies dem Programm gestattet werden soll. Mal ganz davon abgesehen dass das ein ziemlich dreister Schritt von Microsoft war, wuerde mich sowas beim Programmieren enorm stoeren. Ein Programm soll doch volle Kontrolle ueber den Rechner haben, wenn schon nicht ueber den Speicher dann doch wenigstens ueber die Hardware.
    Ich frage mich wo das alles hinfuehren soll, es kommt mir wie eine langfristige "Entmachtung der Programmierer" vor. Vielleicht wird Maschinencode irgendwann komplett abgeloest. Dann wuerde man nurnoch auf Schnittstellen des Betriebssystems zugreifen koennen und unterliegt quasi dessen Bestimmungen. Das sagt mir ueberhauptnicht zu. Das ist doch *mein* Rechner, daher moechte ich auch auf den Prozessor zugreifen koennen wie es mir passt und mir von einem Betriebssystem nichts vorschreiben lassen 🙂
    Nun ja, das ist ne Menge Spekulation, aber die Richtung die in letzter Zeit eingeschlagen wird gefaellt mir ganz und garnicht.

    (*) von diesem Konzept halte ich uebrigends nicht viel, um es mal harmlos auszudruecken. Die Entwicklung geht leider dahin, dass zunehmend mehr Daten in allen moeglichen Dateien eingelagert werden. Das geht von digitaler Rechteverwaltung bis hin zu komplizierter Verschluesselung des Inhalts. Irgendwann wird mal jede Musikdatei, jedes Bild und jedes Programm Informationen ueber den Hersteller, der Benutzer und die Lizenzen enthalten. Dann wird man auf die Zeiten, in denen eine Bilddatei einfach nur das Bild selbst beinhaltet zurueckblicken und sich ueber die Fesseln die einem vom Betriebssystem angelegt werden aergern!



  • Zu 1.

    C# als Sprache kann auch ohne das .Net Framework(oder besser gesagt die CLI) implementiert werden, wenn bestimmte GrundfunktionalitĂ€t gegeben ist die vom Standard gefordert wird. Durch diese Forderungen macht es aber wenig Sinn C# fĂŒr eine nicht CLI konforme Umgebung zu implementieren(Gibt es meines wissens auch nur eine). Und nein C# kann nicht in Maschienencode compiliert werden - jedenfalls nicht mit der Microsoft/Mono Implementation die auf die CLI setzten und den C# Code in IL Code ĂŒbersetzt.

    Zu 2/5.

    Du hast eine falsche Vorstellung der Sicherheit in .Net...
    Das hat nichts mit DRM zu tun.
    Ich empfehle dir einfach mal nen einfĂŒhrenden Artikel in der MSDN Library

    Zu 3.

    Wo soll das eine SicherheitslĂŒcke sein? Der Code ist leicht wiederherstellbar aus dem IL Code, aber es genug Möglichkeiten das zu verhindern, am beliebtesten sind wohl Obfuscatoren.

    Zu 4.

    In der .Net Terminologie bedeutet managed nicht nur automatisches Speichermanagement, sondern allgemein die Beutzung der CLR, die macht noch einiges mehr als automatisches Speichermanagement. C++/CLI ist praktisch C++ welches durch Erweiterungen auch die CLI nutzen und so von den allgemeinen .Net Vorteilen profitieren kann. Sobald du auch nur eine .Net Funktion benutzt, wird auch die CLR als Target genommen und nicht mehr unverwalteter Code. Im Grunde genommen macht die Frage gar kein Sinn, weil C++/CLI ohne .Net(Sprich ohne CLI) ist ganz normales C++. Managed C++ war der erste Versuch C++ fĂŒr die .Net Benutzung zu erweitern aber wurde nicht akzeptiert und somit hat man aus Fehlern gelernt und C++/CLI entworfen das wohl um LĂ€ngen besser ist(in Hinsicht auf Akzeptanz). Wieso C# ne Verbesserung zu C++/CLI sein soll ist mir nicht klar. Das sind einfach 2 verschiedenen Sprachen die aufs .Net Framework zielen. IMO ist C# die bessere .Net Sprache da weniger alter Ballast etc. aber es gibt auch genug Szenarien wo C++/CLI die bessere Wahl ist und das ist ja genau der Sinn von .Net. Man benutzt die Sprache die man will.



  • Danke fuer die Antworten!
    Der MSDN-Artikel behandelt hauptsaechlich die Verwendung der internen Benutzerverwaltung von Windows zur Einschraenkung der Software entsprechend der Benutzerrechte. Also die Sicherheitsaspekte um die man sich als Entwickler selbst kuemmert. Aber unter "Codesicherheit" kann ich mir immernoch reichlich wenig vorstellen. Es wird auch von Zugriffsprivilegien etc. gesprochen, z.B.:

    Ein Administrator kann eine Richtlinie fĂŒr die Codezugriffssicherheit konfigurieren, um einzuschrĂ€nken, auf welche Ressourcentypen der Code zugreifen und welche anderen privilegierten VorgĂ€nge er ausfĂŒhren kann.

    Mit andern Worten kann man ein .NET-Programm so einschraenken, dass es keine IO-Zugriffe durchfuehren kann, oder?

    Dann waere da noch der konkrete Unterschied zwischen C# und C++/CLI: Wenn ich mir die Sprachbeschreibung von C# auf Wikipedia angucke, kommt mir C# wie ein etwas schlankeres C++ vor. Vielleicht wurde auch ein bisschen von Java abgekupfert. Klar, man spart sich so laestige Arbeit wie das Schreiben von Headern, aber im Grunde macht es doch kaum einen Unterschied ob ich jetzt mit C++/CLI oder mit C# in .NET arbeite..



  • Zusammen mit der Codeauthentifizierung(sprich ich kann genau feststellen ob der Code von einer vertrauenswĂŒrdigen Quelle stammt oder nicht) ist das doch genau die Codesicherheit. Und ja, du kannst mit Hilfe der Code Access Security ganz genau bestimmen welcher User welchen Code ausfĂŒhren kann.

    Zu C++/CLI vs. C#:
    Genau das ist doch der Witz dabei 🙂 Beide Sprachen benutzen das .Net Framework, also macht es technisch keinen großen Unterschied. Anders sieht es jetzt aus was die Vorlieben der Entwickler angeht. Da mag einer lieber wie gewohnt C++ und andere lieber C# das einfach schlanker und an .Net angepasster ist.



  • Was sagt ihr denn zu (meiner Spekulation von) der Abschaffung von Maschinencode? Aus Sicht eines Betriebssystems ist das doch ganz klar die groesste "Schwachstelle". Ich glaub nicht das man den Code nichtmehr ausfuehren kann, es kommt halt einfach ein Emulator fuer die 'alten' EXE-Dateien her und Virtuelle Maschinen werden Standard. Ohne jetzt speziell auf Sprachen einzugehen scheint das doch eher die Zukunft zu sein..



  • Wie willst du ohne Maschienencode Programme ausfĂŒhren auf einem Computer? Richtig, geht nicht, denn der versteht nur Maschienencode. Alles, aber auch wirklich alles wird auf nem Compurter letzten Endes in Maschienencode umgewandelt, auch .Net und Java Programme. Von daher wird Machienencode nie aussterben. Klar mag sich an dem Maschienencode in Zukunft was Ă€ndern(tut sich SSE usw. reinkommen), es ist aber immer Maschienencode nötig.



  • Nein, in meiner Horrervision (:)) ist Maschinencode dem Betriebssystem vorbehalten! Programme kommunizieren nur noch mit Windows, und dieses uebersetzt den Programmcode dann in Maschinensprache. Werte direkt in ein Prozessorregister zu schreiben, den Arbeitsspeicher veraendern oder gar Zugriff auf die Festplatte bekommen wird nicht mehr moeglich sein.



  • Und warum sollte ich nicht auch C Funktionen (implizit Maschinencode) verbieten können, auf Festplatte zugreifen zu können? Es muß nur in die Win32-API (meinetwegen auch POSIX, egal!) implementiert werden. Jedes Maschinencode-Programm (unmanaged Win32) lĂ€uft doch bisher auch in einem SpeichergeschĂŒtztenbereich ab, der von der CPU eingegerenzt wird. Wir haben dieses Szenario seit vielen Jahren. Das OS muß eigentlich nur mit weiteren Features gefĂŒttert werden, was man dummerweise in .NET oder Java implementiert.

    Die gesamten Sicherheitskonzepte wie VM werden sogar in den nĂ€chsten Intel- und AMD-CPUs direkt vorhanden sein. Dann brauch ich nicht mal mehr VirtualPC oder Xen, bzw. diese mĂŒssen nicht mehr viel erledigen.


Log in to reply