Wir haben in unser Commuity eine kleine Diskusion ( http://www.java-forum.org/de/viewtopic.php?t=1547&start=60 ):
Kann man jeden unter Windows compilierten C#-Code auch unter Linux ausführen, so wie dass bei Java (Native Code mal ausgenommen) der Fall ist ?
Java macht schöner und erhöht die Lebenserwartung. java-forum.org
naja naja kann ich dir nicht zu 100% beantworten, fakt is jedoch das leute schon so schöne programme wie #develop unter Linux zum laufen gebracht haben. Mono hat im Moment erst version 0.30 und kann scho ne ganze menge ich denke mal wenn man den jungs noch zeit gibt, dürfte bald alles auf anderne systemen wie linux & co laufen.
Viele Grüße
Alexander
Das hört sich jetzt so an, dass Sie die 'Linux-Verison' extra implementieren, hab ich das richtig verstanden ?
Java macht schöner und erhöht die Lebenserwartung. java-forum.org
Ja, oder glaubst du, das MS sich damit selbst mal das Wasser abgräbt, und wenn die Windowsleute auf Linux umsteigen die Entwicklungskosten in den Sand gesetzt haben?
C# ist nämlich von MS, aber so halb open Source. Die ganze Funktionsweise ist offengelegt...
Besuchen sie das VisualC++ - Forum
Und wozu gibt es dann den Bytecode ? Wozu einen Interpreter nutzen, wenn es doch nicht Systemunabhängig ist ? 🤔
Java macht schöner und erhöht die Lebenserwartung. java-forum.org
Den Interpreter gibt's, weil sonst die Runtime keine Kontrolle hat, was das Programm so alles treiben will ... hat was mit Sicherheit, Garbage collection, und Fehlerbehandlung zu tun ... => Managed code.
Den Bytecode gibt's, weil ein Interpreter halt keinen Maschinencode erwartet.
Und da jeder .net-Compiler (C#, VB .net, C++ .net, ...) den selben MSIL-Coder erzeugt, sind die erzeugten Dateien auch in jeder anderen .net-Sprache ohne Probleme nutzbar ... C#-Klasse in VB .net vererben und diese dann in C++ verwenden, ist so kein Problem.
Wissensvermittler und Technologieberater
für .NET, Codequalität und agile Methoden
Original von golohaas.de
Und da jeder .net-Compiler (C#, VB .net, C++ .net, ...) den selben MSIL-Coder erzeugt, sind die erzeugten Dateien auch in jeder anderen .net-Sprache ohne Probleme nutzbar
Ok. Danke. Das ist jetzt soweit klar (glaube ich). Außer das C++ in der Liste aufgeführt wurde.
_Original von golohaas.de_C#-Klasse in VB .net vererben und diese dann in C++ verwenden, ist so kein Problem.
Und wieso muss ich dann das Ganze für Linux extra implementieren ?
Java macht schöner und erhöht die Lebenserwartung. java-forum.org
Was genau musst Du denn für Linux neu implementieren?
Falls Du das .net Framework (unter Linux also Mono) meinst, dann liegt das daran, dass unter anderem der Interpreter natürlich den MSIL-Code schon irgendwie in Maschinensprache umsetzen muss ... und die Betriebssystemaufrufe sind bei Linux nun mal anders als bei Windows ...
Falls Du den Compiler meinst, liegt das daran, dass das Mono-Projekt gerne einen unter der GPL stehenden hätte, um nicht von MS abhängig zu sein ... zumal das auch voraussetzen würde, dass der Compiler selbst in einer .net-Sprache geschrieben ist ... dann könnte man auch den von MS unter Linux mittels Mono laufen lassen.
Falls Du die Anwendungen meinst, da muss nichts portiert werden, die können direkt einfach so ausgeführt werden ... es sei denn, sie verwenden Komponenten, die auf dem jeweils anderen Betriebssystem (noch) nicht verfügbar sind, wie beispielsweise die Windows Forms, die halt sehr eng an GDI gebunden sind, und unter Linux noch nicht so wirklich vollständig laufen wollen ... da muss dann halt auf ein anderes GUI-Toolkit portiert werden ...
Jetzt ein bissel klarer?
Wissensvermittler und Technologieberater
für .NET, Codequalität und agile Methoden
Original von golohaas.de
Was genau musst Du denn für Linux neu implementieren?
Ich gar nichts die Leute von #develop 😉
Original von golohaas.de
Falls Du die Anwendungen meinst, da muss nichts portiert werden, die können direkt einfach so ausgeführt werden ... es sei denn, sie verwenden Komponenten, die auf dem jeweils anderen Betriebssystem (noch) nicht verfügbar sind, wie beispielsweise die Windows Forms, die halt sehr eng an GDI gebunden sind, und unter Linux noch nicht so wirklich vollständig laufen wollen ... da muss dann halt auf ein anderes GUI-Toolkit portiert werden ... Ist zwar nicht schön, aber klar.
Original von golohaas.de
Falls Du das .net Framework (unter Linux also Mono) meinst, dann liegt das daran, dass unter anderem der Interpreter natürlich den MSIL-Code schon irgendwie in Maschinensprache umsetzen muss ... und die Betriebssystemaufrufe sind bei Linux nun mal anders als bei Windows ...
🤔 Ist irgendwie schon eigenartig, denn durch die Nutzung eines Interpreters sollte das Problem doch eigendlich gar nicht auftreten. Oder?
Original von golohaas.de
Falls Du den Compiler meinst, liegt das daran, dass das Mono-Projekt gerne einen unter der GPL stehenden hätte, um nicht von MS abhängig zu sein ... zumal das auch voraussetzen würde, dass der Compiler selbst in einer .net-Sprache geschrieben ist ... dann könnte man auch den von MS unter Linux mittels Mono laufen lassen. Das habe ich jetzt nicht verstanden, ich wollte mich eigendlich gar nicht so tief damit auseinander setzten, aber irgendwie interessiert mich das jetzt doch, könntest du (ihr) mir das erklären?
Java macht schöner und erhöht die Lebenserwartung. java-forum.org
Wegen #develop ... der Interpreter muss den MSIL-Code ja irgendwie auch in Maschinensprache umsetzen ... so letztendlich ...
Und dass die zu erzeugenden Befehle ja nach zu Grund liegendem OS anders aussehen, dürfte klar sein, oder?
Deshalb gibt es einen eigenen Interpreter für Win, und einen für Linux ... ganz so, wie die Java VM ja auch für jedes OS angepasst ist ... stell Dir einfach mal vor, die Windows Java VM kann Swing und AWT, die für Linux aber nur AWT ...
Und nun hast Du eine App, die Swing verwendet ... dann bringt es Dir auch nix, dass die im Bytecode vorliegt und interpretiert wird, wenn die Linux-VM kein Swing "kann" ... => Portierung auf AWT nötig.
So ähnlich verhält es sich mit #develop und den Windows Forms ... die müssen halt unter Linux noch bereit gestellt werden, gäbe es die schon, müsste #develop auch nicht portiert werden.
Schau Dir mal http://www.golohaas.de an und dort unter C# die Kapitel "Einführung in C#" und "Einführung in .net", die könnten Dir vielleicht noch ein bissel weiterhelfen ...
Wissensvermittler und Technologieberater
für .NET, Codequalität und agile Methoden
Original von golohaas.de
Schau Dir mal
> an und dort unter C# die Kapitel "Einführung in C#" und "Einführung in .net", die könnten Dir vielleicht noch ein bissel weiterhelfen ...
Habe ich gemacht, den C# abschnitt könnte man auch glat als Java-Einführung durchgehen lassen. Aber egal.
Original von golohaas.de
Wegen #develop ... der Interpreter muss den MSIL-Code ja irgendwie auch in Maschinensprache umsetzen ... so letztendlich ...Und dass die zu erzeugenden Befehle ja nach zu Grund liegendem OS anders aussehen, dürfte klar sein, oder?
Deshalb gibt es einen eigenen Interpreter für Win, und einen für Linux ... ganz so, wie die Java VM ja auch für jedes OS angepasst ist
Das war schon klar. Trotzdem danke.
Original von golohaas.de
stell Dir einfach mal vor, die Windows Java VM kann Swing und AWT, die für Linux aber nur AWT ...Und nun hast Du eine App, die Swing verwendet ... dann bringt es Dir auch nix, dass die im Bytecode vorliegt und interpretiert wird, wenn die Linux-VM kein Swing "kann" ... => Portierung auf AWT nötig.
So ähnlich verhält es sich mit #develop und den Windows Forms ... die müssen halt unter Linux noch bereit gestellt werden, gäbe es die schon, müsste #develop auch nicht portiert werden.
Das war jetzt ein Senario, oder? Denn Swing läuft unter Linux. Was du damit sagen wolltest ist aber klar.
Kann es sein das es solche Probleme mit keiner anderen Interpreter-Sprache gibt ?
Ich persönliche habe mich nur mit folgenen Sprache, die einen Interpreter in ihrem Konzept nutzen, außeinander gesetzt Java, Python (hiermit sind auch Anwendungen mit GUI möglich) und PHP. Dort gibt es solche Probleme im Allgemeinen aber nicht.
Java macht schöner und erhöht die Lebenserwartung. java-forum.org
IL-Code (Byte-Code) an sich ist portabel. Der ist Befehlssatz festgelegt und das erwartete Verhalten ist bis ins kleinste Fitzelchen spezifiziert, da unterscheidet sich .Net nicht von Java. Das Problem ist die Klassenbibliothek. In Java wurde beim Design der Klassenbibliothek besonders auf Plattformunabhängigkeit geachtet. In .Net hingegen sieht man an vielen Stellen Windows durchscheinen. Es gibt z.B. Klassen, die Windows-Handles veröffentlichen und Methoden zum Verarbeiten von Windows-Botschaften aufweisen. Das betrifft in erster Linie den Namespace System.Windows.Forms, der GUI-Klassen enthält. Windows-Handles gibt es aber auch an anderen Stellen, z.B. in System.Drawing oder in System.Diagnostics. Ich frage mich warum man das nicht hat anders lösen können. In Java-AWT gibt es die Peer-Klassen, die native, OS-spezifische Komponenten kapseln. Das hätte man in .Net genauso machen können, statt OS-spezifische Sachen direkt in die Haupt-API zu packen.
Gruß
Pulpapex
Kann es sein das es von Microsoft beabsichtigt wurde um das Nutzen der entwickelten Software unter Linux zu erschweren ?
Java macht schöner und erhöht die Lebenserwartung. java-forum.org
Was erwartest Du denn darauf jetzt für eine Antwort?
Wirklich WISSEN dürfte das keiner, das ist eine Frage, die in der Regel wilde Spekulationen nach sich zieht ...
Wenn es so wäre, würde Microsoft das offiziell nicht SO zugeben. Wenn es nicht so wäre, dann wird's irgendeinen anderen Grund haben, der AFAIK bislang aber auch nicht öffentlich gemacht wurde.
Klar hat Microsoft nicht das größte Interesse daran, dass auf einmal jede WinApp auch auf Linux perfekt läuft, schließlich wollen sie Geld verdienen, und das - wenn es geht - sicherlich auch mit Windows 😉.Inwieweit da nun aber Absicht dahinter steckt ("wir machen das jetzt mal möglichst inkompatibel") oder einfach nur Gedankenlosigkeit ("Linux? Was ist das? Wir unterstützen Windows und wer es umbasteln will, kann es gerne tun, WIE, ist uns aber egal ..."), ... das weiß wohl keiner von uns hier ...
Obwohl das natürlich Alexander oder ich mal auf "diplomatische" Art und Weise nachfragen könnten ...
Auf der anderen Seite kam auf dem letzten CLIP Community Get Together auch zur Sprache, inwieweit sich der von ASP .net erzeugte Code vom IE abhängig macht, oder sich an die Standards vom W3C hält ... und da wurde seitens Microsoft dem Mozilla abgesprochen, dass er sich standardkonformer verhält als der IE ... ähm, hallo?
Wissensvermittler und Technologieberater
für .NET, Codequalität und agile Methoden
Den MSIL-Code kann man sich mit Hilfe des ILDasm.exe ausgeben lassen, wenn ich das richtig in Erinnerung habe oder? Kann man sich auch den Maschinencode ausgeben lassen, also Assemblercode?
Code-Hacker
Original von stevg
Kann es sein das es von Microsoft beabsichtigt wurde um das Nutzen der entwickelten Software unter Linux zu erschweren?
Dann würden sie wahrscheinlich (ziemlich sicher) nicht selber die ganze CLR mehr oder weniger offiziell nach BSD portieren (mit Quelltext verfügbar).
Ob z.b. die aktuelle Implementation der WinForms so gewählt wurde um die Performance Probleme von Java GUIs zu vermeiden (und nicht alles von Grund auf neu programmieren zu müssen) oder nur um eine Portierung auf andere Platformen zu erschweren sei dahingestellt ... insbes. weil die aktuelle WinForms Implementierung bzgl. Threading auch nicht wirklich optimal ist ...
@CodeHacker:
Ja das geht, mit dem Assemblercode anzeigen! Aber nur wenn man VS hat. Oder besser gesagt, weiß ich es nur, wie es mit VS geht! Der Debugger kann einem den ASM-Output des JIT-Kompilers ausgeben. Aber wie das genau geht, weiß ich nicht...
Besuchen sie das VisualC++ - Forum
Original von Franknstein
@CodeHacker:
Ja das geht, mit dem Assemblercode anzeigen! Aber nur wenn man VS hat. Oder besser gesagt, weiß ich es nur, wie es mit VS geht! Der Debugger kann einem den ASM-Output des JIT-Kompilers ausgeben. Aber wie das genau geht, weiß ich nicht...
Danke! Ich werde mal gucken wie es geht.
Code-Hacker
z.b:
Als Release kompilieren, und während dem laufen (bei einer CLI zb. bei einem ReadLine) pausieren ... dann fragt es ob du die "disassembly" anzeigen willst, das sieht dann etwa so aus:
00000000 sub esp,0Ch
00000003 push edi
00000004 push esi
00000005 push ebx
00000006 push ebp
00000007 xor eax,eax
00000009 mov dword ptr [esp+18h],eax
0000000d mov ebp,ecx
0000000f mov esi,edx
00000011 mov dword ptr [esp+10h],0
00000019 mov eax,dword ptr [esi+4]
0000001c sub eax,dword ptr [esp+2Ch]
00000020 cmp eax,dword ptr [esp+28h]
00000024 jge 00000055
00000026 mov eax,dword ptr ds:[79CB807Ch]
0000002c mov ecx,dword ptr [eax]
0000002e call dword ptr ds:[79C00968h]
00000034 mov ebx,eax
00000036 mov ecx,79C538E4h
0000003b call dword ptr ds:[79CC0108h]
00000041 mov edi,eax
....
Aaaahhhh....wieso ich da nicht selbst drauf gekommen bin....löl
Danke dir!
Code-Hacker