Liebe Forumsmitglieder, ich arbeit gerade an einem Referat für den Informatikunterricht an meiner Schule über .NET und Java. Die technischen Dinge lassen sich relativ einfach recherchieren, wenn ich auch nicht alles komplett verstehe. Dabei bin ich nun auf eine (eigentlich nichttechnische) Frage gestoßen, die ich nicht beantworten kann: Beides sind Frameworks, die zwischen der Applikation und dem Betriebssystem angesiedelt sind. Das Ziel von Java ist dadurch eine Unabhängigkeit vom Betriebssystem und der Zielhardware zu schaffen. Dadurch hat es sich ein breites Anwendungsspektrum erschlossen. Bei .NET sehe ich dieses Ziel eigentlich nicht. Es läuft praktisch nur auf Windows (abgesehen von MONO, das scheint mir aber nicht sehr relevant zu sein). Ein großer Vorteil ist natürlich die gemeinsame Klassenbibliothek für alle Sprachen, das ist aber auch nur im Microsoft-Umfeld relevant. Was also bezweckt MS eigentlich mit dem .NET Framework. Neue Geschäftsfelder zu erschließen scheint es nicht zu sein. Einfach nur ein Ersatz für die MFC-Klassenbibliothek?
Die (oder zumindest eine) Hoffnung hinter .net war, einen Ersatz für die native Win32 API zu schaffen. Win32 datiert aus den Anfängen der 90'er und basiert auf dem 16 Bit API, das sich seit 1985 nicht wesentlich verändert hat. Diese Programmierschnittstelle ist die Basis, auf der alle Windows-Programme aufbauen. Einige Designentscheidungen waren nun nicht gerade glücklich und führten später zu gravierenden Sicherheitsproblemen im Internet-Zeitalter. Außerdem ist Win32 eine prozedurale, für C entwickelte Schnittstelle. .net versprach Abhilfe. Man war nicht an seine Altlasten gebunden, konnte komplett von vorne anfangen, alles schön objektorientiert aufbauen, die Softwareentwicklung vereinfachen etc. pp. Das Ergebnis ist bekannt. fchk
Marc schrieb: > Was also bezweckt MS eigentlich mit dem .NET Framework. Die Frage stellst du nun 13 Jahre nach Einführung von .NET?
Marc schrieb: > Beides sind Frameworks, die zwischen der Applikation und dem > Betriebssystem angesiedelt sind. Naja, einen ganz wichtigen Punkt hast Du übersehen. Java & .net führen die Programme auf virtuellen CPUs aus. Das heisst, der Compiler übersetzt nicht mehr direkt für die Hardware-CPU, sondern für eine virtuelle Maschine. Die "Assembleranweisungen" der virtuellen Maschine werden dann zur Laufzeit auf der "echten" Hardware ausgeführt. Der Vorteil liegt auf der Hand: Ausser dem kleinen Stück Code, dass die virtuelle Maschine auf der Ziel-CPU ausführt ist der gesamte .NET/Java Code komplett unabhängig von der darunterliegenden CPU. Bei SUN (dem ursprünglichen Entwickler von Java) war (angeblich) der Hintergrund, dass man damals schon daran dachte Haushaltsgeräte besser miteinander kommunizieren zu lassen. Bei MS (auch angeblich) der Wunsch sich etwas von Intel abzukoppeln, ohne alle Applikationen zu verlieren. Jede Software hätte ja mindestens neu kompiliert werden müssen, die entsprechenden Firmen hätten also den passenden Compiler gebraucht, sowie evtl. Zusatzlibs wie z.B. DB-Engines. Das mögen Die aber leider gar nicht ;-) Da ist eine VM praktischer. HtH & gn8 Andreas
Andreas H. schrieb: > Java & .net führen die Programme auf virtuellen CPUs aus. Das heisst, > der Compiler übersetzt nicht mehr direkt für die Hardware-CPU, sondern > für eine virtuelle Maschine. > Die "Assembleranweisungen" der virtuellen Maschine werden dann zur > Laufzeit auf der "echten" Hardware ausgeführt. > > Der Vorteil liegt auf der Hand: Ausser dem kleinen Stück Code, dass die > virtuelle Maschine auf der Ziel-CPU ausführt ist der gesamte .NET/Java > Code komplett unabhängig von der darunterliegenden CPU. Das bedeutet also, dass beide Ansätze prinzipiell das gleiche Ziel hatten. Aber warum ist Java dann heute überall präsent und .NET nur auf Windows? Hat MS dieses Ziel irgendwann aufgegeben oder einfach nur die Vermarktung verschlafen?
Marc schrieb: > Aber warum ist Java dann heute überall präsent und .NET nur auf > Windows? Weil MS bis vor kurzem alles bekämpft hat, was nicht Windows war - ich erinnere nur an den unseligen Browser-Krieg. Man scheint aber langsam zur Vernunft zu kommen: .net ist mittlerweile in Open Source entlassen worden.
Marc schrieb: > Aber warum ist Java dann heute überall präsent und .NET nur auf > Windows? Was heißt denn hier "präsent"? Java ist von sich aus im Gegensatz zu .NET erst mal auf keinem halbwegs aktuellen Windows Rechner "präsent". Wer installiert sich denn ohne dass es dafür einen besonderen Grund oder Zwang gibt eine JAVA JRE auf seinem Rechner? .NET ist präsent auf MS BS. Java ist es nicht.
alt geworden schrieb: > Was heißt denn hier "präsent"? Java ist von sich aus im Gegensatz zu > .NET erst mal auf keinem halbwegs aktuellen Windows Rechner "präsent". Als neues Geschäftsfeld meinte ich nicht PCs, sondern die ganze Embedded Welt.
Uhu Uhuhu schrieb: > Weil MS bis vor kurzem alles bekämpft hat, was nicht Windows war Bis vor kurzem ???
Als Java bei Sun auf den Plan trat, da war die Hypezeit von SPARK. Alle gehörten zu einer Familie, aber jede CPU hatte Eigenheiten, die der Compiler zu berücksichtigen hatte. Das war eine wichtige Komponete von RISC, wesentlich für die Performance ist der Compiler und dessen Kenntnis der Maschine, z.B. deren Registerfilegröße. X86 seit PentiumPro haben diesen letzten Optimierungschritt in Hardware. Nur für den (ASM-)Programmierer fühlt sich die Kiste wie x86 an, im Innern passiert jeweils die neuste Idee der Hardware-Buben (und Mädels). Java bewirkt das Gleiche in Software. VM/JiT-Compiler übersetzen Bytecode in MaschinenCode für die aktuelle HW, und könne (machen's aber nicht zwangsläufig) alle HW-Features nutzen. .Net ist genau das selbe von MS. Es entstand aus Lizenz-Gründen, da Java-Lizenznehmer keine Erweiterungen an Java durchführen dürfen. Was MS sehr schwer viel. Auch .Net ist HW-unabhängig, aber anders als zu NT-Start-Zeiten, wo man diverse Platformen unterstützte, wurde .Net nur eingeschränkt dazu genutzt. Obwohl es eigentlich besser ist als Java, denn es übersetzt Codefragment vor dem Start einmalig, während JiT-Compiler meist von erst zur (Bytecode-)Laufzeit mit dem Optimieren anfangen. Das ist OK fun Server-Applikationen, die man am liebsten nie durchstartet, aber blöd für typische PC-Applikationen, wo die gewonnenen Laufzeit-Erkenntnisse haben Beenden des Programms verloren gehen. .Net als OpenSource könnte auch damit zu tun haben, daß der aktuelle Java-Besitzer mißliebige Java-Nutzer gerne mal auf Milliarden verklagt.
alt geworden schrieb: > Was heißt denn hier "präsent"? Java ist von sich aus im Gegensatz zu > .NET erst mal auf keinem halbwegs aktuellen Windows Rechner "präsent". > Wer installiert sich denn ohne dass es dafür einen besonderen Grund oder > Zwang gibt eine JAVA JRE auf seinem Rechner? > > .NET ist präsent auf MS BS. Java ist es nicht. Dann bist Du in der Tat alt geworden. Java ist praktisch Omnipräsent, auf jedem BS.
Rene H. schrieb: > Dann bist Du in der Tat alt geworden. Java ist praktisch Omnipräsent, > auf jedem BS. Hast du richtig gelesen was ich schrieb? Nein, auf meinem BS ist JAVA (bewusst) nicht (mehr) präsent. Eine potentielle Sicherheitslücke weniger. Ich wüsste übrigens auch nicht, dass übliche Rechner für Jedermann aus dem Geiz-ist-so-verbreitet-Markt mit Windows (7), 8 (oder bald Windows 10) von Haus aus ohne zusätzliche Installation JAVA Bytecode Software ausführen. Wozu auch! Es gibt genügend (gute) Software, die keine JRE benötigen. Demgegenüber läuft dies hier z.B. http://www.chip.de/downloads/Paint.NET_13015268.html nach dem Runterladen auf Anhieb.
Lange Geschichte, sehr kurze Version: Der ursprüngliche Zweck von .NET war pures, reines Marketing. MS hat den Begriff zuerst in die Welt gesetzt ohne selber genau zu wissen was das ist. Da gab es von MS Broschüren und Zeitungsanzeigen, die waren so nichtssagend, die hätten auch komplett unbedruckt sein können. Es war einfach ein "Ding" von Microsoft, das "irgendwie gut" ist und "alles" kann. Weder MS, noch Programmierer, noch Kunden wussten am Anfang was .NET wirklich ist, bzw. sein sollte. Erfunden wurde das "Ding", weil MS auf dem Desktop die Felle davon schwammen. MS wollte "irgendwas" haben, was die Zukunft darstellte. Man war zu spät mit dem Internet dran, im Browserkrieg sah es nach schweren Strafen aus und Java kam daher. Java war damals (heute schon lange nicht mehr), eine Bedrohung für MS. Platformübergreifend - das war der Horror für MS. Betriebssysteme wie Windows waren plötzlich zweitrangig. MS tat dann sehr viel, um nicht zu sagen alles, um Java zu bekämpfen. Darunter gab es den Versuch eine spezielle Java-Version zu machen, mit der man wieder an Windows gebunden war (Microsoft hat dafür später $1,95 Milliarden USD als Strafe an Sun zahlen dürfen). Java, und der Kampf gegen Java, gaben dann den Ausschlag, was MS zuerst unter dem Marketing-Begriff .NET implementierte. Im Prinzip ihr eigenes Java. Eine eigene virtuelle Maschine, ein eigenes Framework, eine eigenen Sprache (C#). Alles so ein bisschen wie Java, aber so gemacht, dass es faktisch nur auf Windows lief (theoretisch bruchstückhaft auch anderswo). Zusätzlich wurden die vorhandenen Sprachen für Windows auf .NET angepasst. Was so einige altgediente VB-Programmierer zum kotzen fanden. Das war es dann auch schon mit .NET. Nachdem MS unter dem Begriff ihren eigenen Java-Ersatz geschaffen hatte blieb es dabei. Mehr wurde von diesem "Superding" nie implementiert, es blieb beim .NET Framework. Mehr musste MS auch nicht machen, denn Java auf dem Desktop war inzwischen, dank Microsoft und der Dummheit Suns, nicht mehr relevant. Mehr konnte Microsoft auch nicht machen. Kein grundsätzlich neues Betriebssystem, besonders kein Networking-OS, kein neues Konzept wie man in Zukunft Software macht. Gerade hatte man über Jahre hinweg angekündigte Features von Longhorn immer wieder zusammenstreichen müssen, weil man sie nicht zum Laufen oder fertig bekam (Longhorn wurde dann der Scheißhaufen bekannt als Windows Vista), da blieb keine Luft für den großen .NET-Wurf.
:
Bearbeitet durch User
Ja, das war reinstes Marketing, es gab so ein paar Ideen die so halbwegs konkret waren. Zum Beispiel wollte Microsoft so eine Art "zentrale Authentifikation" für das Internet bauen. Der Java-Ersatz ist so ziemlich das einzige was übrig blieb, und in den Wahrnehmungsblasen einiger Leute ist das auch so richtig erfolgreich. Microsoft hatte übrigens viele solcher Projekte. Die wurden alle nach wenigen Jahren, in der Regel kurz bevor die was Brauchbares hervorgebracht haben, eingestellt. Typische Beispiele sind: Windows for Pen Computing (eine Erweiterung für Windows 3.1 und 95 um Formulare mit Stiften ausfüllen zu können) Objektorientierte Dateisysteme (das sollte immer in der nächsten oder übernächsten Version kommen... das letzte System für die die das angekündigt haben war Vista, ein paar Reste davon sollen sich noch in Office finden) Personas in Windows NT (Windows NT sollte eigentlich in der Lage sein direkt Unix, OS/2 und Mac Programme auszuführen, die Technik dafür ist sogar drin, die entsprechenden Erweiterungen werden aber längst nicht mehr gepflegt) OLE (Damit Du Objekte von einem Programm in ein anderes Programm einfügen kannst, das war der heiße geile Scheiß in den 1990gern und manche machen das auch heute noch. Corel Draw war damals als das Programm bekannt, das immer wegen OLE abstürzte. Heute verwendet man das noch gelegentlich in Microsoft Office, aber eigentlich sollte das mal ganz groß werden) Wie bei jeder neuen Microsofttechnik haben sich halt einige Leute gleich drauf gestürzt, während andere das halt ignoriert haben. Durch Lerneffekte ist die Skepsis gegenüber solchen Dingen halt gestiegen, und der letzte Rest von .net den wir heute haben schlägt halt genau in die Kerbe eines ebenfalls relativ unsinnigen Projektes von Sun.
Andreas H. schrieb: > Naja, einen ganz wichtigen Punkt hast Du übersehen. > > Java & .net führen die Programme auf virtuellen CPUs aus. Das heisst, > der Compiler übersetzt nicht mehr direkt für die Hardware-CPU, sondern > für eine virtuelle Maschine. > Die "Assembleranweisungen" der virtuellen Maschine werden dann zur > Laufzeit auf der "echten" Hardware ausgeführt. Oh oh, das ist komplett falsch :-) Die Programme werden nativ kompiliert. Nix virtuelle Maschine und so... Andreas H. schrieb: > Uhu Uhuhu schrieb: >> Weil MS bis vor kurzem alles bekämpft hat, was nicht Windows war > > Bis vor kurzem ??? Momentan portiert Microsoft .NET auch für OS X und Linux.
:
Bearbeitet durch User
Christian Berger schrieb: > und > der letzte Rest von .net den wir heute haben schlägt halt genau in die > Kerbe eines ebenfalls relativ unsinnigen Projektes von Sun Dir ist aber (hoffentlich) schon klar, dass bei .NET heute nicht von einem "Rest" geredet werden kann, angesichts des massiven Ausbaus seit den Anfängen hier: http://www.heise.de/newsticker/meldung/NET-ist-da-46394.html
alt geworden schrieb: > Christian Berger schrieb: > Dir ist aber (hoffentlich) schon klar, dass bei .NET heute nicht von > einem "Rest" geredet werden kann, angesichts des massiven Ausbaus seit > den Anfängen hier: Naja, was das ist ist eine Runtime und die Entwicklungswerkzeuge dafür. Das sollte nur ein kleiner Teil der .net Strategie sein. Eigentlich sollte sich .net viel mehr im Internet abspielen, dort ist .net absolut irrelevant. Das Microsoft dieses Problem in über 100 Megabytes löst spricht jetzt nicht wirklich für Microsoft. Und so oder so lösen die genau das Problem, das Java verspricht zu lösen, nur halt schlechter weil die Programme weniger portabler als native Win32 Programme sind. Aber um zum OP zurück zu kommen, ursprünglich wollte Microsoft mit .net das Internet erobern, inzwischen ist es nur noch ein Framework.
:
Bearbeitet durch User
Christian Berger schrieb: > Eigentlich > sollte sich .net viel mehr im Internet abspielen, dort ist .net absolut > irrelevant. ^^ schon mal von ASP.NET gehört?
Ich weiß es ist etwas OT, aber nur mal so als Realitätsabgleich, wie es außerhalb der .net Welt aussieht: Da schreibt man Programme zum Beispiel gegen POSIX. Diese Programme kompilieren dann, wenn man aufpasst, auf so ziemlich jeder Plattform ohne Anpassungen. Und wenn man doch mal Dinge braucht die unterschiedlich implementiert sind, zum Beispiel für Optimierungen, so nimmt man #ifdef Anweisungen für bedingte Kompilierung. Oder man nimmt so was wie Lazarus. Da schreibt man seine GUI-Anwendung einmal. Formulare kann man bequem zusammenklicken oder in Code erstellen oder jede beliebige Mischung daraus. Kompilieren tut das dann ohne Änderungen mindestens auf Linux, MacOSX und Windows. Die Windowsversion läuft dann häufig sogar noch auf Windows 9x. Und in allen Fällen kommt halt eine Binärdatei mit 1-2 Megabytes raus, die man einfach ausführt. Keine Installation kein gar nichts. Auch keine besonderen Frameworks die man braucht. Das ist inzwischen realer Stand der Technik bezüglich Plattformunabhängigkeit.
Boris P. schrieb: > Oh oh, das ist komplett falsch :-) > Die Programme werden nativ kompiliert. Nix virtuelle Maschine und so... Mir scheint es ein Bisschen von beidem zu sein. Das Prinzip der Frameworks ist ähnlich dem von Java, mit Übersetzung der CLR (common language runtime) zur Laufzeit in den Maschinencode. Um aber die hässlichen Nebeneffekte davon zu vermeiden wird gerne auch bei Installation vorkompiliert. Merkt man auf langsamen Rechnern, wenn der dafür zuständige mscorsvw.exe aka "CLR Optimization Service" noch lange nach dem Update eines Framworks an der CPU knabbert.
:
Bearbeitet durch User
Christian Berger schrieb: > Eigentlich > sollte sich .net viel mehr im Internet abspielen, dort ist .net absolut > irrelevant. Wohl eher umgekehrt. Bereits damals war genug Interesse an .net vorhanden, lies http://www.heise.de/newsticker/meldung/Java-und-NET-gleich-beliebt-67273.html Die Stichworte fürs Internet nennen sich "Web Services" und ASP.NET http://de.wikipedia.org/wiki/ASP.NET Zitat "ASP.NET kommt auf ca. 17,2 % aller Websites als serverseitige Programmiersprache zum Einsatz und liegt damit nach PHP (82 %) und vor dem drittplatzierten Java (2,8 %) auf dem zweiten Platz der am häufigsten serverseitig verwendeten Sprachen zum Erstellen von Webseiten" Soviel zum Thema "irrelevant".
A. K. schrieb: > Mir scheint es ein Bisschen von beidem zu sein. Das Prinzip der > Frameworks ist ähnlich dem von Java, mit Übersetzung der CLR (common > language runtime) zur Laufzeit in den Maschinencode. Jo, so ist es. Der Code wird eben erst zur Laufzeit, und nicht schon vorab kompiliert. Das hat aber doch nichts mit virtuellen Cores oder Maschinen zu tun. Mittlerweile der Code aber immer häufiger schon vorkompiliert (Android ART, NGEN etc.). Christian Berger schrieb: > Oder man nimmt so was wie Lazarus. Da schreibt man seine GUI-Anwendung > einmal. Formulare kann man bequem zusammenklicken oder in Code erstellen > oder jede beliebige Mischung daraus. Kompilieren tut das dann ohne > Änderungen mindestens auf Linux, MacOSX und Windows. Das geht mit .NET auch. Ich entwickle am Mac, kopiere die .exe auf meinen Raspberry Pi und lasse sie dort laufen. Kein problem. Ich kann sogar vieles von meinem Code auf nem Arduino Clon laufen lassen :-)
:
Bearbeitet durch User
Christian Berger schrieb: > Oder man nimmt so was wie Lazarus. Da schreibt man seine GUI-Anwendung > einmal. Formulare kann man bequem zusammenklicken oder in Code erstellen > oder jede beliebige Mischung daraus. Kompilieren tut das dann ohne > Änderungen mindestens auf Linux, MacOSX und Windows. Für Linux wurde und wird MONO entwickelt. Das erfüllt den gleichen Zweck.
Boris P. schrieb: > Andreas H. schrieb: >> Naja, einen ganz wichtigen Punkt hast Du übersehen. >> >> Java & .net führen die Programme auf virtuellen CPUs aus. Das heisst, >> der Compiler übersetzt nicht mehr direkt für die Hardware-CPU, sondern >> für eine virtuelle Maschine. >> Die "Assembleranweisungen" der virtuellen Maschine werden dann zur >> Laufzeit auf der "echten" Hardware ausgeführt. > > Oh oh, das ist komplett falsch :-) > Die Programme werden nativ kompiliert. Nix virtuelle Maschine und so... Interessant.. warum kann ich dann eine mit C# auf windows (x86) erstellte .exe mit Mono Runtime auf auf dem RPi(ARMv6) ausführen, wenn alles nativ kompiliert ist? Und wozu braucht man dann den JIT-Compiler?
Guest schrieb: > Interessant.. warum kann ich dann eine mit C# auf windows (x86) > erstellte .exe mit Mono Runtime auf auf dem RPi(ARMv6) ausführen, wenn > alles nativ kompiliert ist? Und wozu braucht man dann den JIT-Compiler? Weil die Exe eines C# Compilats nun mal nicht der native Code zu diesem Zeitpunkt ist. Lies http://www.guidetocsharp.de/Introduction.aspx#WhatIsDotNet Zitat "Erst zur Ausführungszeit werden die MSIL-Anweisungen in Maschinensprache umgesetzt, die dann auf die jeweils ausführende Hardwareplattform optimiert werden kann. Dies geschieht durch einen Compiler, der "just in time" arbeitet, also erst auf Anforderung und nur das jeweils Notwendige übersetzt, und daher auch als JIT-Compiler bezeichnet wird."
>Die (oder zumindest eine) Hoffnung hinter .net war, einen Ersatz für die >native Win32 API zu schaffen. mit dem Kuriosen Ergebnis, dass IMMER die Nativ API vorher kommt (kommen muss) und die .NET Programmierer warten mussten/müssen.. (z.b. die ganzen Erweiterungen für die Taskleiste, wie die Progressbar, Vorschaubild, "Aufgaben" usw.)
Boris P. schrieb: > Jo, so ist es. Der Code wird eben erst zur Laufzeit, und nicht schon > vorab kompiliert. Das hat aber doch nichts mit virtuellen Cores oder > Maschinen zu tun. Die Rolle des Zwischencodes in .NET entspricht ungefähr der des Java Bytecodes. Insofern ist das schon vergleichbar. Man kann mscorsvw.exe m.W. auch komplett entfernen. Dann ist der strukturelle Unterschied zu Java eher gering.
alt geworden schrieb: > Für Linux wurde und wird MONO entwickelt. Das erfüllt den gleichen > Zweck. Es erfüllt gar nichts. Es ist unvollständig, unzuverlässig und von Patentforderungen bedroht. Die kürzlich erfolgte Codespende von Microsoft ändert daran auch nichts.
Jay schrieb: > Es erfüllt gar nichts. Es ist unvollständig, unzuverlässig Dann hilf halt mit es zu verbessern, anstatt hier herumzumeckern.
>Dann hilf halt mit es zu verbessern, anstatt hier herumzumeckern.
DAS Tonschlagargument für OpenSource...
Robert L. schrieb: > DAS Tonschlagargument für OpenSource... Ebenso wie das ewige Gesabbel (nun seit .net 1.0 oder 13 Jahre!!) über angebliche Patentklagen.
Frank K. schrieb: > Die (oder zumindest eine) Hoffnung hinter .net war, einen Ersatz für die > native Win32 API zu schaffen. Technisch ist dieser Ersatz ein auf der Win32-API aufsetzender Layer, d.h. alles, was in .Net veranstaltet wird, wird von der .Net-Runtime in Win32-API-Aufrufe umgesetzt. Das Betriebssystemkonzept von Windows NT sieht zwar die Existenz verschiedener Subsysteme vor, die mit dem Betriebssystemkern kommunizieren, aber reale Umsetzungen davon war neben dem eher akademischen Posix-Subsystem eine Zeitlang noch ein OS/2-Subsystem -- und natürlich das nach wie vor existierende und jetzt einzige Win32-Subsystem. .Net hingegen ist kein neues Subsystem, sondern nur eine Klassenbibliothek/Laufzeitumgebung, die im Win32-Subsystem läuft.
alt geworden schrieb: > Jay schrieb: >> Es erfüllt gar nichts. Es ist unvollständig, unzuverlässig > > Dann hilf halt mit es zu verbessern, anstatt hier herumzumeckern. Man muss kein Chefkoch sein und sich in die Küche drängeln um zu erkennen dass das Essen angebrannt ist. Man kann einfach ins nächste Restaurant (zur nächsten Programmiersprache) gehen und das verbrannte Essen hinter sich lassen.
Boris P. schrieb: > Andreas H. schrieb: >> Naja, einen ganz wichtigen Punkt hast Du übersehen. >> >> Java & .net führen die Programme auf virtuellen CPUs aus. Das heisst, >> der Compiler übersetzt nicht mehr direkt für die Hardware-CPU, sondern >> für eine virtuelle Maschine. >> Die "Assembleranweisungen" der virtuellen Maschine werden dann zur >> Laufzeit auf der "echten" Hardware ausgeführt. > > Oh oh, das ist komplett falsch :-) > Die Programme werden nativ kompiliert. Nix virtuelle Maschine und so... > Eigentlich schon. Bei Java erzeugt der Compiler Bytecode für die JVM, bei .NET halt CIL-Bytecode. Natürlich kann man das auch gleich weiterverarbeiten, indem man dann auf die Hardware-CPU-Befehle geht (was aber wirklich ein eigener Schritt ist - sonst müsste man ja genau die "Ekelstellen" des Compilers ab ICode neu implementieren). Dann geht aber die Portabilität flöten (was aber oft auch egal ist). Das Prinzip ist insgesamt aber schon steinalt. Denke mal an UCSD-Pascal oder die WAM. >> Uhu Uhuhu schrieb: >>> Weil MS bis vor kurzem alles bekämpft hat, was nicht Windows war >> >> Bis vor kurzem ??? > > Momentan portiert Microsoft .NET auch für OS X und Linux. Strategic marketing ist nicht Deines, oder ? ;-) /regards Andreas
Andreas H. schrieb: > Eigentlich schon. Bei Java erzeugt der Compiler Bytecode für die JVM, > bei .NET halt CIL-Bytecode. Was genau willst du damit sagen? Vesrtehe nicht so ganz, worauf du damit hinauswillst... Andreas H. schrieb: > Strategic marketing ist nicht Deines, oder ? ;-) Hä? ^^
alt geworden schrieb: > Für Linux wurde und wird MONO entwickelt. Das erfüllt den gleichen > Zweck. Schön wärs. Der ganze GUI-Krempel von .net läuft auf Mono nicht.
Uhu Uhuhu schrieb: > Schön wärs. Der ganze GUI-Krempel von .net läuft auf Mono nicht. Support for Windows Forms 2.0 is complete WPF läuft (noch) nicht.
Andreas H. schrieb: >>> Uhu Uhuhu schrieb: >>>> Weil MS bis vor kurzem alles bekämpft hat, was nicht Windows war >>> >>> Bis vor kurzem ??? >> >> Momentan portiert Microsoft .NET auch für OS X und Linux. > Strategic marketing ist nicht Deines, oder ? ;-) > > /regards > Andreas Wenn du schon zitierst, dann bitte so, dass auch die Urheber der Zitate korrekt angegeben sind. Das Zitat stammt nicht von mir.
Uhu Uhuhu schrieb: > Wenn du schon zitierst, dann bitte so, dass auch die Urheber der Zitate > korrekt angegeben sind. > > Das Zitat stammt nicht von mir. Sorry, my fault. Da ist die Zeile ">Andreas H. schrieb:" am Anfang verlorengegangen. War keine pöse Absicht :/ Grüße Andreas
Boris P. schrieb: > Andreas H. schrieb: >> Eigentlich schon. Bei Java erzeugt der Compiler Bytecode für die JVM, >> bei .NET halt CIL-Bytecode. > > Was genau willst du damit sagen? Vesrtehe nicht so ganz, worauf du damit > hinauswillst... Java & .NET arbeiten nicht nach dem "klassischen" Prinzip "Src-->AST-->ICode-->Asm-->Executable". Asm wäre hier schon Code (assembler), der auf der Zielhardware ausgeführt ausgeführt würde. (Der letzte Schritt ist hier das Linken). Stattdessen compiliert man für eine nichtreale (virtuelle) Maschine, also "Src-->AST-->ICode-->VAsm". Der Loader (also das was das Programm nachher in den Speicher lädt) führt dann erst zur Laufzeit den Schritt VAsm-->Executable durch. Vorteil: Das Compilat (also bis incl. VAsm & Libs) ist CPU-Typ unabhängig. Eine "Vereinfachung" dazu ist, dass man "VAsm-->Executable" direkt beim Compile anhängt (das ist dass, was Du beschreibst). Vorteil: Bessere Startzeit des Programms aber trotzdem nur ein Compileraufbau (bis VAsm), also wenig "Nervware", die bei neuer Zielhardware implementiert werden muss. Nur die "Low-level" Optimierungen (die heute nicht mehr trivial sind^^) muss man neu schreiben. Natürlich ist das in der Praxis etwas verworrener. Ich habe hier z.B. das Linken komplett aussen vor gelassen. Aber ich hoffe, die Idee ist klar geworden. /regards Andreas
Christian Berger schrieb: > Ja, das war reinstes Marketing, es gab so ein paar Ideen die so halbwegs > konkret waren. Zum Beispiel wollte Microsoft so eine Art "zentrale > Authentifikation" für das Internet bauen. Wieso wollte? Siehe Passport heute Microsoft Account > Der Java-Ersatz ist so ziemlich das einzige was übrig blieb, Wenn es nur ein Java-Ersatz wäre, wäre es schon längst von der Bildfläche verschwunden. > und in den Wahrnehmungsblasen einiger Leute ist das auch so richtig > erfolgreich. Die Wahrnehmungsblasen sind meist in der Umgebung der Kritiker... Fast die gesamten Features von NGWS sind implementiert worden und bis heute im Einsatz... Von Passport heute Microsoft Account bis UI-Frameworks (damals Avalon, dann WPF und heute XAML Framework). http://news.microsoft.com/2000/06/22/microsoft-unveils-vision-for-next-generation-internet/ > Typische Beispiele sind: > > Windows for Pen Computing (eine Erweiterung für Windows 3.1 und 95 um > Formulare mit Stiften ausfüllen zu können) Das war brauchbar, eingestellt wurde es auch nicht. Kam danach für Windows 95, dann als XP Tablet Edition und ist seit Vista Bestandteil des OS > Objektorientierte Dateisysteme Aka WinFS. Teile sind u.a. in MSSQL, ADO(.NET) gewandert. Objektorientiert war es eher nicht en.wikipedia.org/wiki/WinFS > Personas in Windows NT Das Unix-Subsystem gibt's immer noch, auch als SDK für Server 2012 und W8... http://www.microsoft.com/en-us/download/details.aspx?id=35512 Von einer Unterstützung von MacOS-Anwendungen ist mir nichts bekannt. > OLE Microsoft hat viel zu lange, das OS an die Fehler der Dritthersteller angepasst. Siehe z.B. http://blogs.msdn.com/b/oldnewthing/ (Raymond Chens Blog) Zudem gibt es die Basis von OLE, COM immer noch, eingesetzt in der Windows Runtime. Ebenso existiert DCOM aka Network OLE immer noch. Hannes Jaeger schrieb: > Lange Geschichte, sehr kurze Version: > > Der ursprüngliche Zweck von .NET war pures, reines Marketing. MS hat den > Begriff zuerst in die Welt gesetzt ohne selber genau zu wissen was das > ist. Da gab es von MS Broschüren und Zeitungsanzeigen, die waren so > nichtssagend, die hätten auch komplett unbedruckt sein können. Es war > einfach ein "Ding" von Microsoft, das "irgendwie gut" ist und "alles" > kann. Weder MS, noch Programmierer, noch Kunden wussten am Anfang was > .NET wirklich ist, bzw. sein sollte. Angekündigt auf der PDC 2000, Beta Ende 2000, RTM Anfang 2002 > Erfunden wurde das "Ding", weil MS auf dem Desktop die Felle davon > schwammen. Ende der 1990er/Anfang der 2000er? Klar... Da gab's noch keine iPhones, iMacs, Android-Phones und irrelevante Chromebooks etc. Apples Marktanteil war von teilweise ~10% auf 2% zusammengeschrumpft und die gesamten anderen Betriebssysteme auf dem Desktop schon längst bedeutungslos (auf dem Server konnte zu dieser Zeit allerdings Linux schon massiv Marktanteile gewinnen, lag da afair schon bei 25%) http://arstechnica.com/features/2005/12/total-share/9/
Arc Net schrieb: > Ende der 1990er/Anfang der 2000er? Möglicherweise geraten da ein paar Events durcheinander. Als Java aufkam hatte Microsoft erhebliche Sorgen, dass dessen Portabilität ihnen das Wasser abgräbt, d.h. x86-PCs unter Windows als Clients durch beliebige Plattformen ersetzbar werden könnten. Microsofts Schnellschuss darauf war aber nicht .NET, sondern ActiveX.
:
Bearbeitet durch User
>http://www.microsoft.com/en-us/download/details.aspx?id=35512
ist das nicht "depraced" und ab Win10 abgeschafft?
Arc Net schrieb: > Christian Berger schrieb: >> Ja, das war reinstes Marketing, es gab so ein paar Ideen die so halbwegs >> konkret waren. Zum Beispiel wollte Microsoft so eine Art "zentrale >> Authentifikation" für das Internet bauen. > > Wieso wollte? Siehe Passport heute Microsoft Account Ahh OK, ich dachte das basiert jetzt auf offenen Standards. Und zugegeben hab ich das auch immer ignoriert. >> Der Java-Ersatz ist so ziemlich das einzige was übrig blieb, > > Wenn es nur ein Java-Ersatz wäre, wäre es schon längst von der > Bildfläche verschwunden. Warum das? > Die Wahrnehmungsblasen sind meist in der Umgebung der Kritiker... > Fast die gesamten Features von NGWS sind implementiert worden und bis > heute im Einsatz... Von Passport heute Microsoft Account bis > UI-Frameworks (damals Avalon, dann WPF und heute XAML Framework). > http://news.microsoft.com/2000/06/22/microsoft-unveils-vision-for-next-generation-internet/ Zugegeben ich hab noch nichts davon irgendwo eingesetzt gesehen. Welche Websites benutzen das denn? >> Typische Beispiele sind: >> >> Windows for Pen Computing (eine Erweiterung für Windows 3.1 und 95 um >> Formulare mit Stiften ausfüllen zu können) > > Das war brauchbar, eingestellt wurde es auch nicht. Kam danach für > Windows 95, dann als XP Tablet Edition und ist seit Vista Bestandteil > des OS Nein, XP Tablet Edition war technisch anders. WfPC setzte Änderungen der Anwendungen voraus und unterstützte das direkte Eintragen von Text in Formularfelder. Inklusive Texterkennung. >> Personas in Windows NT > > Das Unix-Subsystem gibt's immer noch, auch als SDK für Server 2012 und > W8... http://www.microsoft.com/en-us/download/details.aspx?id=35512 > Von einer Unterstützung von MacOS-Anwendungen ist mir nichts bekannt. Ja das Subsystem ist aber quasi tot. Von der MacOS-Unterstützung sind nur noch ein paar Reste in NTFS drin. MacOSX haben die gar nicht mehr angekündigt. >> OLE > > Microsoft hat viel zu lange, das OS an die Fehler der Dritthersteller > angepasst. Siehe z.B. http://blogs.msdn.com/b/oldnewthing/ (Raymond > Chens Blog) > Zudem gibt es die Basis von OLE, COM immer noch, eingesetzt in der > Windows Runtime. Ebenso existiert DCOM aka Network OLE immer noch. Klar, natürlich DCOM gibts noch, muss es auch geben da viele industrielle Steuerungssysteme auf diese "Zukunftstechnologie" setzen. Du sprichst ein interessantes Problem an, und das ist, dass Microsoft ja den Missbrauch ihrer APIs mit unterstützen muss der Kompatibilität halber. Das ist richtig, ignoriert aber einen sehr wichtigen Punkt. APIs müssen so gebaut sein, dass sie möglichst einfach zu nutzen sind. Und das hat Microsoft halt ignoriert. Die APIs waren schon immer kompliziert und löchrig dokumentiert. Das lag zum einen daran, dass man früher einfach nicht den Arbeitsspeicher hatte es ordentlich zu machen. Windows lief ja mal auch schon mit 4 Megabyte RAM. Zum anderen liegt es daran dass Microsoft unterschiedliche Paradigmen so halb zu implementiert hat. Das Fenstersystem ist zum Beispiel an Smalltalk orientiert, spätere Bibliotheken dazu wurden in C++ implementiert. Alles, aber auch wirklich alles, wird mit DLLs gelöst, was dazu führt dass Du plötzlich binäre Strukturen durch Deine API schleusen musst. Und diese Stukturen werden dann von 16 auf 32 auf 64 Bit erweitert... was schief geht. Das wusste auch Microsoft damals schon besser.
Uhu Uhuhu schrieb: > alt geworden schrieb: >> Für Linux wurde und wird MONO entwickelt. Das erfüllt den gleichen >> Zweck. > > Schön wärs. Der ganze GUI-Krempel von .net läuft auf Mono nicht. Ist nicht wahr. Guckst du hier http://zetcode.com/gui/csharpwinforms/firststeps/ http://zetcode.com/gui/csharpwinforms/dialogs/ Übersicht http://zetcode.com/gui/csharpwinforms/
Christian Berger schrieb: > APIs müssen > so gebaut sein, dass sie möglichst einfach zu nutzen sind. Und das hat > Microsoft halt ignoriert. Die APIs waren schon immer kompliziert Das könnte man genauso über Programmiersprachen sagen. Programmiersprachen müssen so gebaut sein, dass sie möglichst einfach zu nutzen sind. Leider wird das von bestimmten Programmiersprachen halt ignoriert.
Jay schrieb: > alt geworden schrieb: >> Jay schrieb: >>> Es erfüllt gar nichts. Es ist unvollständig, unzuverlässig >> >> Dann hilf halt mit es zu verbessern, anstatt hier herumzumeckern. > > Man muss kein Chefkoch sein und sich in die Küche drängeln um zu > erkennen dass das Essen angebrannt ist. Weiß nicht was du willst. Einfach mal anerkennen, dass hier schon viel geleistet wurde, siehe http://www.mono-project.com/download/ http://www.monodevelop.com/ > Man kann einfach ins nächste Restaurant (zur nächsten > Programmiersprache) gehen und das verbrannte Essen hinter sich lassen. Auch im "Lazarus-Restaurant" wird nur mit Wasser gekocht und die Bugliste dort ist lang. Ich lese immer mal wieder gerne in deren Foren und kenne das Gejammere. Es nützt halt nix. Bugs müssen ausgemerzt werden. Das braucht Zeit, wenn es nicht in Vollzeit geschieht. Gerade OpenSource tut sich da des Öfteren schwer und bisweilen wird es auch mal richtig zäh. Hat man diese Leidensfähigkeit nicht, muss man halt Geld ausgeben und darf dann seine Ansprüche beim VK anmahnen und drohen, ein anderes Produkt zu kaufen. Manch einen Support interessiert das aber auch herzlich wenig. Geht ein Kunde, kommt dafür in aller Regel ein neuer, denken die. So what?!
Christian Berger schrieb: > Ahh OK, ich dachte das basiert jetzt auf offenen Standards. Und > zugegeben hab ich das auch immer ignoriert. Ja und nein. MS ist Mitglied der OpenID und Passport/MS Account wohl auch ein OpenID-Provider (selbst noch nicht genutzt, daher nur ein Link http://www.golem.de/0810/63202.html) >> Wenn es nur ein Java-Ersatz wäre, wäre es schon längst von der >> Bildfläche verschwunden. > > Warum das? Welches Framework mit ähnlichem Umfang von Mobile über Desktop bis (Web und Server mit entsprechender Herstellerunterstützung gab es denn? Hätte MS einfach zugesehen, wäre Java u.U. wirklich zu einem Problem geworden. >> Die Wahrnehmungsblasen sind meist in der Umgebung der Kritiker... >> Fast die gesamten Features von NGWS sind implementiert worden und bis >> heute im Einsatz... Von Passport heute Microsoft Account bis >> UI-Frameworks (damals Avalon, dann WPF und heute XAML Framework). >> > http://news.microsoft.com/2000/06/22/microsoft-unveils-vision-for-next-generation-internet/ > > Zugegeben ich hab noch nichts davon irgendwo eingesetzt gesehen. > Welche Websites benutzen das denn? Wieso Webseiten? WPF/XAML-Framework sind deklarative UI-Frameworks (XAML ist XML basiert). Das XAML-Framework ist die neuere Variante für die Windows Runtime. Wenn's um ASP.Net geht: Stackoverflow.com, Microsoft.com, bing.com, godaddy.com, dell.com >>> Personas in Windows NT >> >> Das Unix-Subsystem gibt's immer noch, auch als SDK für Server 2012 und >> W8... http://www.microsoft.com/en-us/download/details.aspx?id=35512 >> Von einer Unterstützung von MacOS-Anwendungen ist mir nichts bekannt. > > Ja das Subsystem ist aber quasi tot. Von der MacOS-Unterstützung sind > nur noch ein paar Reste in NTFS drin. MacOSX haben die gar nicht mehr > angekündigt. Für MacOS würde mich mal die Quelle interessieren. Kann aber auch schlicht eine Verwechslung sein: HPFS = IBM OS/2 HFS = Apple > Du sprichst ein interessantes Problem an, und das ist, dass Microsoft ja > den Missbrauch ihrer APIs mit unterstützen muss der Kompatibilität > halber. > > Das ist richtig, ignoriert aber einen sehr wichtigen Punkt. APIs müssen > so gebaut sein, dass sie möglichst einfach zu nutzen sind. Und das hat > Microsoft halt ignoriert. Die APIs waren schon immer kompliziert und > löchrig dokumentiert. Das Argument halte ich für nicht sehr tragfähig. Ich habe hier Win32-Anwendungen (kein MFC etc.) aus den Anfängen der 90er. Die sehen heute zwar komisch aus, aber funktionieren. Der Punkt ist (kenne das selbst aus ST, Amiga und Palm-Zeiten), dass einige Dinge, die gewünscht sind, nicht mit den vorgegebenen APIs umsetzbar sind ohne z.T. massiv zu tricksen oder das OS gleich ganz zu umgehen. MS hat da imo zu lange den falschen Weg gewählt: Lieber keinen Kunden vergraulen und im OS z.T. Abfragen auf die laufenden Anwendungen einzubauen statt die APIs entweder zu dokumentieren oder dicht zu machen (kurze Fehlermeldung wenn ein Programm, da was "illegales" macht, hätte gereicht). > Das lag zum einen daran, dass man früher einfach > nicht den Arbeitsspeicher hatte es ordentlich zu machen. Windows lief ja > mal auch schon mit 4 Megabyte RAM. Zum anderen liegt es daran dass > Microsoft unterschiedliche Paradigmen so halb zu implementiert hat. Das > Fenstersystem ist zum Beispiel an Smalltalk orientiert, spätere > Bibliotheken dazu wurden in C++ implementiert. Alles, aber auch wirklich > alles, wird mit DLLs gelöst, was dazu führt dass Du plötzlich binäre > Strukturen durch Deine API schleusen musst. Und diese Stukturen werden > dann von 16 auf 32 auf 64 Bit erweitert... was schief geht. > Das wusste auch Microsoft damals schon besser. Lässt sich z.T. nicht vermeiden... z.B. Zeiger. Zudem wäre zu der Zeit auch der Implementierungsaufwand/Speicherbedarf/Performanceoverhead nur sehr schwer zu rechtfertigen gewesen. Jay schrieb: > unzuverlässig Wann das letzte Mal getestet? http://www.mono-project.com/docs/about-mono/showcase/companies-using-mono/ > und von Patentforderungen bedroht. Die kürzlich erfolgte Codespende von > Microsoft ändert daran auch nichts. https://github.com/dotnet/corefx/blob/master/PATENTS.TXT So langsam kann ich die z.T. hasserfüllten Hater von der FSF nicht mehr hören. So gut wie JEDE Software, egal was, ist direkt oder indirekt aufgrund der BESCHISSENEN Softwarepatente/Rechtslage bedroht. Und zwar nicht durch MS. Hier wird's auch noch lustig werden, wenn TTIP durch ist.
Arc Net schrieb: > Der Punkt ist (kenne das selbst aus ST, Amiga und Palm-Zeiten), dass > einige Dinge, die gewünscht sind, nicht mit den vorgegebenen APIs > umsetzbar sind ohne z.T. massiv zu tricksen oder das OS gleich ganz zu > umgehen. > MS hat da imo zu lange den falschen Weg gewählt: Lieber keinen Kunden > vergraulen ... Kunden? MS war doch unter den ersten, die ihre eigenen APIs und sonstige MS-Standards missbraucht haben. Kann mich noch gut erinnern, als ich das erste mal für Windows programmiert habe. Da kriegt man zum Compiler noch fette gedruckte Dokumentation dazu. Inklusive Styleguide, wie eine Windows-Applikation auszusehen hat und wie sie sich zu verhalten hat. Die ersten, die das komplett ignoriert haben, war MS selber.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.