|
Was ist .NET?
Hallo,
ein Frage, bei der die meisten von Euch sicher tierisch ablachen werden: Was genau ist .NET eigentlich? Ist das eine neue Programmiersprache wie C++, Java oder Delphi? Oder nur eine Entwicklungsumgebung (IDE) für einen Haufen von Programmiersprachen? Oder ein neuer Standard und Windows, wie Programme in Zukunft untereinander kommunizieren? Gibt es dazu irgendwo mal eine halbe Seite oder ein kurzes "Tutorial" zum Thema? Habt vielen Dank |
Was ist .NET :?:
Es gibt dazu wohl schon eine Menge Infos. Letztenendes ist es die Ablösung für die Win32 API, aber das wäre ein wenig zu simpel. .NET ist die komplett neue Welt für Windows - oder so. MS verfolgt mit .NET viele Ziele. Unter anderem soll das lästige DLL (Versions-)Problem endgültig beseitigt werden, die Ansteuerung der APIs soll sprachunabhängig werden, die Sicherheit soll besser :roll: werden, und, und, und. Für .NET ist ein kompletter Satz neuer Programmiersprachen nötig, da die alten Win32-System nicht der .NET Welt entsprechen, diese werden jedoch auch weiterhin, zumindest eine Weile, noch unterstützt. .NET verspricht viel. Einige Links  http://dotnet.borland.comhttp://www.microsoft.com/net |
Hallo,
was für uns Programmierer besonders interessant ist ist folgendes: Ein .NET Compiler erzeugt einen Maschienenabhängigen Code mehr. Wie JAVA wird ein zwischencode erzeugt, der dann auf den Zielplatformen zur aufrufzeit Compiliert oder Interpretiert wird (bin mir nicht sicher wie da genau vorgegangen wird). Desweiteren können Programme die Teile anderer Programme die in diesem zwischencode vorliegen verwenden. So kann z.B. ein Programm erstellt werden bei dem ein Programmierer in VB.NET, ein anderer in Delphi.NET und ein dritter in C# arbeitet. Welche auswirkungen das auf Delphi haben wird kannst du hier nachlesen.Gruß Klabautermann |
Zitat:
Es wird ein Zwischencode erstellt, welcher vor dem ersten Aufruf auf einem Rechner kompiliert wird, und so an die lokale Umgebung bestmöglich angepasst wird. Anschliessend liegt das Kompilat im Cache zur sofortigen und schnellen Wiederverwendung vor. ...:cat:... |
Zitat:
Greetz, Ben :hi: |
:dancer2:
Ich wollte auch gerade Fragen was dieses .NET eigentlich bedeutet ! :mrgreen: |
was mir nicht ganz klar is: Können dann ältere Programme die in Delphi geproggt wurden noch verwendet werden?
|
Zitat:
|
Moin Zusammen,
Zitat:
Nicht umsonst wird wohl der neue Server von .NET auf 2003 umbenannt worden sein. |
2 Klassengesellschaft dank .NET?
Wenn .NET so wie java wird mit Zwischencode dann geht erstmal die Plattformunabhängigkeit auf Kosten der Systemleistung. Hab mir letztens nochmal Programme angeschaut, die in Assembler geproggt sind und die auf die API direkt zugreifen. diese Programme sind etwa 20 mal schneller als das plattformunabhängige Java und vorallem sehr systemnah und sehr sehr klein.
Mein Kommentar zum Thema Plattformunabhängigkeit: Also es gibt auf beiden Seiten (Plattformunabhängigkeit und Systemnähe) Vor- und Nachteile. Die wesentlichen Leistungskriterien sind wohl Geschwindigkeit beim Ausführen des Codes und Sicherheit für das System. Ich bin der Meinung, wenn sich die .NET-Schiene durchsetzt und die normalen Api-Sachen nicht mehr unterstützt werden, dann wird microsoft quasi einen Riegel vor die Systemfunktionen von Windows schieben. .NET ist sicher ein Schritt in Richtung Palladium, TCPA und co. indem dem Anwender nach und nach jeglicher direkter Zugriff auf das Betriebssystem untersagt wird und das ganze unter dem Vorwand der Sicherheit läuft. So ist es für Microsoft viel einfacher Programmen den Einblick in bestimmte Systembereiche völlig zu untersagen und damit z.B. Backdoors und Schwachstellen zu schaffen, die sich Geheimdienste oder Hacker zu Nutze machen können. Ich persönlich halte es für keine gute Idee Plattformunabhängigkeit einzuführen und Systemnähe abzuschaffen. Aber ich denke, NET ist eine sehr gut durchdachte Marktstrategie Microsofts und der übrigen Firmen. Zum Einen wird der Programmierer zum Willenlosen Subjekt der großen Firmen gemacht, weil er keine Rechte mehr auf dem System hat und zum anderen brauchen die PC's dank Plattformunabhängigkeit mehr Performance und das wiederum heizt die Entwicklung von neuen CPU's und schnelleren Systemen an. Demnach werden die Absatzzahlen von PC's gesichert sein, die momentan sicher stark stagnieren, weil die vorhandenen Systeme für Spiele und CPU's einfach schnell genug sind. Es war klar, dass die Sache mit .NET unter dem Faktor "Sicherheit" verkauft wird. Logisch ist, dass dann Viren keinen Einfluss mehr aufs System haben ähnlich bei JAVA (ist es möglich in Java Viren zu schreiben? NEIN oder NICHT so einfach). Allerdings führen Microsoft und die großen Firmen dann eine 2 Klassengesellfschaft im Programmieren ein. Die eine Schiene ist .NET und vergleichbar mit der 2. Klasse, da der Programmierer keinen direkten Zugriff mehr aufs System hat (dies erreicht er nur über die vorgefertigten .NET-Funktionen). Die erste Klasse ist vergleichbar mit der Microsoft Systemschiene, die nun nach und nach geschirmt wird. Ich schätze, die bisherigen Entwicklersysteme werden nicht umhin kommen, die Win-API auch weitere Jahre zu unterstützen, es sei den alle Entwicklerfirmen machen bei .NET mit. Dann haben die Programmierer keine Wahl auf dieses System umzusteigen und damit in die 2. Klasse des Programmierens degradiert zu werden. Soweit mein Kommentar zum Thema Plattformunabhängigkeit. Ich muss sagen, dass ich den Kommentar sehr pessimistisch verfasst habe, aber meine Argumente (vielleicht nicht alle) für zutreffend halte. Falls ihr nicht mit einverstanden seid, könnt ihr ja konstruktive Kritik anbringen, die bitte frei von Emotionen ist. |
Naja Shadow, Du bist schon ein wenig ein Schwarzmaler :)
Ich selber finde .NET in Hinblick auf die 'Plattformunabhängigkeit' aber eher einen schwachen Witz. - Mit "Platform" meint Microsoft schliesslich nicht Dos / Win / Novell / Unices, sondern einfach Win98, WinMe, Win2k, WinXP und Windows Server 2003 - sprich alles in fester Microsoft - Hand. Es gibt zwar im openSource-Bereich bereits versuche, daß zur Ausführung des Zwischencodes notwenidge .NET - Framework auch unter POSIX zur Verfügung zu stellen, die Versuche sind aber bisher noch nicht allzu weit gediehen. Wenn jemand also unter Plattformunabhängigkeit von .NET meint, er könne ein und dieselbe Software unter Win und Linux verwenden, hat er sich also leider ganz gewaltig geschnitten. :( Ich selber code also weiterhin in "normalem" Delphi mit der CLX. Damit bin ich dann hinterher wenigstens auch auf Linux lauffähig. Schade nur, daß Borland die VCL und nicht die CLX in einen .NET - Namespace portiert. Im anderen Falle hätten wir mit einer .NET - CLX tatsächlich einmal best of both worlds in unseren Händen. - So müssen wir uns nun unterscheiden: tatsächlich Plattform_un_abhängig mit Delphi und Kylix und der CLX oder eben .NET mit der VCL nur innerhalb der .NET - Sprachen. Wobei ich da sagen muss.... C# ist schon schick... - Ist schliesslich ja auch von einem Ur-Delphianer entwickelt :)) |
Hmm, wenn ich das jetzt richtig verstanden hab wird der Zwischencode doch nur beim ersten Starten ausgeführt, danach liegt dann doch ein "echtes" x86 (oder sonstwas) - Programm vor, dass dann auch sich von wegen Prozessorlast und ähnlichem in Grenzen halten wird.
Nichtsdestotrotz hat Shadow irgendwo schon recht, da wird schon wieder mehr weggekapselt :roll: |
Moin ShadowCaster,
was bringt Dich denn auf die Idee, man könne in .NET Programmen keine API Funktionen mehr benutzen? Du solltest eigentlich jede Funktion einer beliebigen DLL importieren können, wie Du es jetzt schon mit den API Funktionen in Delphi machen musst (bzw. wie Borland es für viele Funktionen schon getan und mitgeliefert hat). Das die Art und Weise wie man das tun kann neu ist liegt natürlich in der Natur der Sache, aber es ist machbar. Für eine kleine Übung in C#, einen RegistryViewer, musste ich auch einige Funktionen importieren. |
@Freak:
Bei plattformunabhängigen System, von mir jetzt mal Interpretersysteme genannt, gibt es einige Nachteile bei der Ausführung des Codes. Im Prinzip geht alles über den Interpreter. Wer die VM für den IE installiert hat, weiß wie groß sie ist. Wenn nach dem Compilieren der Java-code in X86-Code vorliegen würde, dann wär die VM in der Basisversion nicht über 4 MB groß. Leider ist es beim Ausführen eines vorcompilierten codes so, dass immer noch ein Programm zwischen Code und Kernel steht. Die Kommunikation zwischen vorkompilierten Code und Kernel sieht dann sehr vereinfacht so aus (man beachte dass ich die Javalibraries mal weggelassen habe, die Kommunikation mit den Libraries die auch interpretiert und erstmal entpackt werden müssen, kostet wohl zusätzlich noch 3 mal soviel Zeit wie folgendes Beispiel zeigt): Plattformunabhängiger Code: 1. Interpreter öffnet code 2. Interpreter liest Befehl, um eine Datei zu laden (aus Programmcode gelesen) 3. Interpreter sendet den Befehl an den Kernel 4. Kernel lädt die Datei 5. Kernel liefert Speicheradresse an Interpreter 6. Interpreter stellt Adresse dem Programm zur Verfügung Das ganze mal im direkten plattformabhängigen Code: 1. Kernel öffnet code 2. Kernel liest Befehl, eine Datei zu laden 3. Kernel lädt Datei 4. Kernel stellt Speicheradresse dem Programm zur Verfügung Das ist nur ein Beispiel (auch wenns vom Aufbau nicht ganz stimmt, der Ansatz zeigt zumindest, wie das auf Kosten der Performance geht) Ein weiteres Beispiel in dem Microsoft die Kontrolle hat könnte so aussehen: 1. Interpreter öffnet Code 2. Interpreter findet Code um einen Film zu laden, dessen Signatur nicht verifiziert ist 3. Interpreter verweigert weitere Ausführung des Programms 4. Programm wird mit Fehlermeldung beendet Ob das jetzt Schwarzmalen ist oder nicht. so einfach wäre es dann für MS, die Kontrolle zu behalten. @Christian Seehase: Zitat:
Zitat:
|
Achja, nochwas: Wieso sollte Microsoft eine PLattform zwischen Win98, NT4, ME, 2000 und XP erstellen, wenn laut Microsoft sowieso nurnoch auf der XP-Schiene bzw. 2000-Schiene gefahren werden soll. Der Aufwand würd sich aus der Sicht nicht lohnen da heute in Firmen fast ausschließlich nurnoch 2000 eingesetzt wird. XP setzt sich nicht so gescheit durch und NT4-Rechner gibt es auch immer weniger.
|
Moin ShadowCaster,
da das Ganze eigentlich dazu gedacht war plattformunabhängig zu funktionieren (nicht zwischen verschiedenen Windowsversionen ;-) ), war es unumgänglich sich vom direkten Win 32 API Zugriff zu lösen. Solange MS Betriebssysteme mit Win 16/32/64 API liefert, wird die auch für eigene Programme zugänglich sein, und sei es, wie zumindest in C#, auf Umwegen. Sollte es mal ein .NET Framework auf einem anderen Betriebssystem geben, so wird man wohl auch dort Möglichkeiten haben auf dort gewohnte Systemfunktionen zuzugreifen. Ein Windows ohne die übliche API (und sei sie emuliert) kann ich mir allerdings in absehbarer Zeit nicht so recht vorstellen, denn das hiesse für alle Anwender dass sie ihre vorhandenen Software wegwerfen könnten, und das durchzusetzen, dürfte selbst für MS ein nicht so leicht zu bewältigender Brocken sein. Immerhin laufen ja selbst echte DOS Programme in vielen Fällen noch, und das auch auf nicht DOS basierten Windows Versionen. |
Zitat:
Bei NT schaut das anders aus. Es gibt u.A. auch größere Unternehmen, die aus Kostengründen noch NT4 einsetzen. - Bei der aktuellen Marktsituation bei uns und bei der Preispolitik von MS ist sogar davon auszugehen, daß das noch eine ganze Weile so weitergehen wird. Was die Platformen inkl. 98 und ME angeht.. naja, vielleicht basiert das .NET Framework ja selber nur auf der Win32 - API. ;-) |
Zitat:
|
Ich teile ShadowCasters Bedenken vor allem bezüglich Performance.
Ein "Kompilat" im Cache ist spätestens nach dem nächsten Reboot futsch, oder soll es da einen persistenten Cache geben ? Dann wäre aber das Problem mit einer noch konsistenten Systemumgebung gewaltig. Und die Vorstellung, mein .NET-Programm wird auf dem einen System anders "endgültig" kompiliert als auf dem anderen ("bestmögliche Anpassung an die Umgebung"), finde ich eine ziemlich beunruhigende Vorstellung. Wie soll man da noch Fehler "draußen" nachvollziehen ? Roderich |
Moin Roderich,
Zitat:
Zitat:
Soweit ich informiert bin, geben die Programme im Zwischencode an, welche Voraussetzungen (Module) erforderlich sind, damit sie korrekt laufen, und das bis hin zur Version. Das kannst Du mit bisherigen Mitteln nur erreichen, wenn Du jede benötigte DLL selber auf die korrekte Version prüfst. Leider hast Du insofern wohl recht, als dass es sich um die Theorie handelt, die ja oft ein ganzes Stück von der Praxis entfernt ist. |
Zitat:
1.) Du schreibst ein Assembly in einer ersten Version (1.0) - also sozusagen eine DLL im .NET - Zwischencode, die weiterverwendet werden kann. 2.) Du schreibst eine andere Software, die diese Version benötigt. 3.) Du entwickelst Dein Assembly weiter (Version 2.0), und fügst hierbei zum Beispiel inkompatible Änderungen zu 1.0 ein. 4.) Jemand anderes verwendet Version 2.0 Deines Assemblys und liefert seine Software aus. Ein Zielsystem, auf dem Die Software aus 2 und 4 laufen müsste, wäre ohne .NET jetzt ziemlich aufgeschmissen. Zwei Versionen einer DLL - dazu noch inkompatibel zueinander - mag Windows nicht wirklich. Das .NET Framework hat hierbei den Vorteil, daß es sich die letztendlichen Kompilate beider Assemblys cached, und den Zugriff selber verwaltet. Somit können beide Versionen nebeneinander Existieren und bei Bedarf angesprochen werden. |
Etwas OT ;-)
Moin Sebastian,
Zitat:
Einfach eine Datei (kann auch leer sein, der Name ist wichtig) mit dem Namen <Name der Exe inclusive Extension>.local im Programmverzeichnis ablegen, und schon werden als erstes mal die im Programmverzeichnis befindlichen DLLs benutzt. Da dies betriebssystem- und nicht programmabhängig ist funktioniert es mit jedem Programm. |
Also ich find eure Antworten bisher sehr gut und konstruktiv. Einige Dinge muss ich wohl nochmal überdenken, wenn das stimmt, das der vorcompilierte Code tatsächlich zu einer z.B. Exe auf dem System compiliert würde. ;)
Allerdings beschäftige ich mich jetzt schon einige Wochen mit dem PE-Exe, bzw. Dll-Format. Das PE-Format ist seid Windows95 ins Rollen gekommen und stellt einen großen Schritt zur Plattformunabhänigkeit auf der microsoftschiene dar. Das heißt, Anwendungen im PE-Format (auch Dll's) sollen laut Microsoft sogar auf OS2-Systemen laufen. Die Struktur des PE-Formats find ich von Microsoft ziemlich gut durchdacht und auch sehr logisch. Ich denke nicht, dass dieses Format .NET dieses Format völlig verdrängen wird. Schließlich müssen die .NET-Interpreter oder Compiler ja auch irgendwie laufen und auf ihrer eigenen Struktur können sie das sicher nicht. Das wäre ja so als wenn sich der Compiler selbst interpretieren würde, was nicht geht, wenn der compiler vorcompiliert ist. Das normale PE-Exe-format wird sicher in absehbarer Zeit nicht abschaffbar sein, wenn man das aus der Sichtweise betrachtet. Derzeit lerne ich übrigens (ja, glaubt es ruhit) so Stück für Stück Assembler und ich bin froh, dass ich mich auch mal mit dieser Systemebene auseinander gesetzt habe. Da lernt man sehr viel, wie das System aufgebaut ist, wie der Kernel ausführbare Programme abarbeitet. Wenn .NET also so arbeitet und ich es richtig verstanden habe, könnte man das ja ohne Probleme auch mit Delphi emulieren ;) Man müsste nur hergehen und einen Delphicompiler und ein Batchfile beim Anwender installieren. Dann gibt man ihm die DCU's und das Batchfile und diese Datei ruft den Compiler auf, dieser compiliert die vorcompilierten DCU's zu Exe-Dateien und führt sie aus. Wenn ich es so betrachte. Also rein auf der Microsoftschiene läuft das sicher ohne Probleme, da Delphi auch auf jeder Windowsversion ab 95 oder 98 laufen sollte. Wenn .NET von Microsoft da also greifen soll, wo es gar nichts zu greifen gibt dann muss das einen anderen Grund haben. Und da denke ich kann es nur einen für geben. Jede Windowsversion, ob nun NT oder XP, hat unterschiedliche API-Befehle die neun hinzugekommen sind. Wird der Code jetzt auf Windows95 ausgeführt, der für WindowsXP gedacht war, kann es Probleme geben, sofern er Api-befehle ausführt die für XP gedacht waren. :freak: Das wäre ein Argument für .NET auch auf der Windows-Schiene. Falls noch jemand was verstanden hat :mrgreen: ... der Text da oben sollte nur aussagen, dass es auch Argumente für Plattformunabhänigkeit und damit auch .NET auf der Windowsschiene gibt. Ich werd noch was :coder: , bis dann. |
Bezüglich dem PE-Format: So wie ich das verstanden hab, kann das PE-Format ruhig weiterverwendet werden. Nur erzeugt ein Delphi.NET- oder C#-Compiler dann keine Datei mehr im PE-Format, sondern das wird dann von der Laufzeitumgebung, dem .NET-Framework, bewerkstelligt.
|
ja das stimmt, das PE-Format wäre dann auch gar nicht mehr nötig, weil die ganzen Verweise auf Sektionen und API-Funktionen entfallen. Im Prinzip wäre dann nur eine Sektion nötig (back to the roots) :mrgreen: Können wir ja gleich die alten Dos-Exes von 16 auf 32 Bit portieren, dann haben wir .NET von der Seite aus gesehen, da die alten Dos32 Exe-Files keinen PE-Header und keine Sektionen wie im heutigen PE-Header hatten.
|
Zitat:
Tatsächlich hatten IBM und Microsoft damals gemeinsam ein OS entwickeln wollen. Aus Sicherheitsgründen hat IBM dann aber angefangen, den OS-Kern (der eben mit NT identisch ist) mit einer eigenen Shell möglichst Dicht abzukapseln. Hauptaugenmerk lag hierbei auf Sicherheit (deswegen wird OS/2 Warp auch bei vielen Banken noch eingesetzt). Die meisten API-Calls kommen bei OS/2 also gar nicht bis zum System runter. Wie das genau bei PE nun läuft weiss ich nicht, aber ich denke, da der Kern der gleiche ist, liegt das wahrscheinlich dann an der OS/2 Shell, die den DLL's bzw. Anwendungen nur den Zugriff auf den Kern erlauben muss, damit diese laufen. |
| Alle Zeitangaben in WEZ +1. Es ist jetzt 14:37 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz