Betriebtssystemunabängigkeit mit C# gewähleistet

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 ?

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.

Das hört sich jetzt so an, dass Sie die 'Linux-Verison' extra implementieren, hab ich das richtig verstanden ?

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

Und wozu gibt es dann den Bytecode ? Wozu einen Interpreter nutzen, wenn es doch nicht Systemunabhängig ist ? 🤔

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.

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 ?

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?

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?

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

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.

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 ?

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?

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

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