C# Betreibssystem
-
Habe ein frage kann man in c# ein Betriebssystem schreiben das dann auch läuft?
Und was für Nachteile hat c# gegeüber andere Progamier sprachen wie C oder C++.
Danke schon ma
und entschuldigt die dumme frage wenn se einer dumme frage ist.
-
MartinBarber schrieb:
Habe ein frage kann man in c# ein Betriebssystem schreiben das dann auch läuft?
Möglich ist es, ja. ABER: Das setzt voraus, dass der Quelltext zu 100% in Bytecode umgewandelt wird und nicht mehr zur Laufzeit, wie es eigentlich der Sinn von C# ist. Allein aus diesen Gründen, sollte man die Finger davon lassen. Vorallem da einem dadurch nicht der Sprachumfang und Namespaces zur verfügung stehen. Hat also keinen Sinn.
MartinBarber schrieb:
Und was für Nachteile hat c# gegeüber andere Progamier sprachen wie C oder C++.
Eigentlich sogut wie gar keine, es kommt immer auf den Fall an, es gibt einfach keine "Allround-Sprache". Jede Sprache hat ihr eigenes Anwendungsgebiet, manche paar mehr, manche paar weniger.
Und wenn hier einer ankommt von wegen "Ja, ist 100000x langsamer als C blablabla", dann klatscht es!!!
MartinBarber schrieb:
und entschuldigt die dumme frage wenn se einer dumme frage ist.
Nicht die Frage ist dummm, sondern deine Rechtschreibung
-
Welche Programmier sprachen würdest du denn Empfehlen für ein Betriebssystem welche sind schnell und nicht allzu kompliziert zu lernen.
Ich übernehme keine Haftung für Rechtschreibfehler.
-
Hallo
Willst du selber ein BS schreiben?
chrische
-
Warum die Frage sieht wahrscheinlich so aus oder aber genau gesagt ich will einfach nur Informationen zusammen sammeln wie ein Betriebssystem funktioniert und man weiß ja nie.
Kann ja noch kommen aber ich schätze ma wenn ich sage das ich( und Paar andere leute) irgent wann ma vor habe ein Betriebssystem zu schreiben werde ich aus gelacht oder !
-
Kurz gesagt:
Du brauchst C und ein wenig assembler.
Fertig. PS: C# ist VIEL zu langsam, denn wenn schon im Kernel lahmercode ist, wie lahm soll dann der rest vom betriebssystem werden (applications etc).Nene, vergiss mal C# schön. Wenn du dir den Quellcode von einem betriebssystem angucken willst, dann geh auf http://www.kernel.org udn lad dir den source vom aktuellen linux kernel runter.
ps: nimm das package welches > 30 bzw > 40 mb groß ist. die kleinen packages sind nur patches.
-
JA habe schon oft gehört das c# einfach zu langsam ist
Aber was soll man machen werde mich dann ma weiter informieren.
-
du schrieb:
Kurz gesagt:
PS: C# ist VIEL zu langsam, denn wenn schon im Kernel lahmercode ist, wie lahm soll dann der rest vom betriebssystem werden (applications etc).Quatsch mit Soße...
Schau nur mal Singularity an. Vor allem vielleicht diese Übersicht. Dort sind z.B. auch Aussagen zu Standardbetriebssystemtasks drin wie RPC Aufrufe, System Calls, Prozesse erzeugen usw. und da ist Singularity durch das Design um längen besser als heutige Betriebssysteme, und das obwohl es in managed Code geschrieben ist(Sing# welches ne Erweiterung von C# ist)
Und vor allem hat Singularity einen Vorteil - es ist sicher. Damit mein ich nicht die Applikationssicherheit, keine logischen Fehler etc., sondern es ist in managed Code geschrieben der von sich aus schon zigmal sicherer ist als irgendein ASM/C/C++ Code.
Trotzdem muss man bedenken das Singularity ein Forschungsprojekt ist und so niemals aufn Markt kommt - das größte Problem dabei ist nämlich dass nichts dazu kompatibel wäre
-
Tut mir Leid, aber ich werde meine Zeit sicher nicht damit verschwenden irgendwelches Propagandamaterial durchzulesen. Defakto ist C# zu langsam. Punkt.
Die Kernelroutinen müssen nunmal so perfomant wie möglich gehalten werden.C# mag im Applikationbereich für Microsoft Betriebssysteme mehr oder weniger sinnvoll sein (.NET und sonstiger Kram), aber im Kernel hat dieser Quatsch nix zu suchen. Das ist so.
-
Also geht nicht direkt um ein Betriebssystem aber auch um Programmieren.
Da hier schon einige Programmiersprachen genannt wurden frage ich gleich.
Welche Sprache würdet ihr empfehlen um PC spiele zu Programmieren (EGO shooter)
Was ist schnell und was für Erfahrungen habt ihr schon gemacht ?
In welchen sprachen sind heutige egoshooter geschrieben auf welchen Grundlage fangen die(EA UBISOFT) an.
-
Martin Barber schrieb:
Also geht nicht direkt um ein Betriebssystem aber auch um Programmieren.
Da hier schon einige Programmiersprachen genannt wurden frage ich gleich.
Welche Sprache würdet ihr empfehlen um PC spiele zu Programmieren (EGO shooter)
Was ist schnell und was für Erfahrungen habt ihr schon gemacht ?
In welchen sprachen sind heutige egoshooter geschrieben auf welchen Grundlage fangen die(EA UBISOFT) an.C++
EDIT: Mit Sicherheit nich C#. Denn in der Computerspieleszene kommt es nunmal auf performacne an. man könnte fast schon sagen: Performance = Geld. Je niedriger die Systemvoraussetzungen sind, desto größer ist die potentielle Zielgruppe. Je performanter die engine geschrieben ist, desto mehr grafische Effekte können ins Spiel integriert werden, ohne die akzeptable FPS-Rate von 24 zu unterschreiten.
-
Da muss ich dich leider enttäuschen. Propagandamaterial wirst du da nicht finden, nur wissenschaftliche Abhandlungen die nicht von der Marketingabteilung geschrieben wurden, sondern von Wissenschaftlern die garatiert weit gebildeter sind als wir hier aufm Board und wissen was sie tun - aber naja, ignorante Menschen gibts überall.
Defakto ist C# zu langsam.
Diese Aussage ist quatsch. C# ist an sich genauso schnell wie jeder andere native Code, da C# genauso letztendlich in nativen Code kompiliert wird. Was C# subjektiv langsamer macht ist der JIT Compiler beim ersten Start einer Applikation und die höhere Abstraktion der Klassenbibliothek. Leider wird für Singularity ein Compiler benutzt der den managed Code direkt in Maschinencode kompiliert und auch wird nicht die .Net Klassenbibliothek verwendet sondern nur die managed Sprache an sich. Damit fallen die beiden Gründe was das .Net Framework auf hiesigen PCs langsam macht weg und übrig bleibt nativer Code der aus einer managed Sprache kompiliert wurde und kein bissle langsamer ist als die oben schon aufgeführten üblichen Verdächtigen wenns um OS Programmierung geht: ASM/C/C++. Wieso sollte das jetzt langsamer sein?!?
Übrigens disqualifiziert man sich mit Pseudoargumenten wie
Defakto...Punkt.
und
Das ist so
selbst schon aus jeder Diskussion da keinerlei Fakten genannt werden sondern nur rechthaberisch die eigene Meinung durchgesetzt werden soll. Ohne objektive Fakten hat man im vorhinein schon verloren...
-
Singularity sieht auf jeden Fall nach einem interessanten Projekt aus! Ich hab's größtenteils nur überflogen, aber kann es nicht auch sein, dass einige der Geschwindigkeitsvorteile (wie z.B. das ultra-schnelle Prozess-Laden) an der Technik liegen, also weil einige Konzepte einfach grundlegend verändert wurden verändert wurden (SIP z.B.)?
Auch wenn andere Techniken verwendet wurden (die Channels sahen auch interessant aus, hab ich aber noch nicht im Detail verstanden), haben mich die Geschwindigkeitstabellen doch erstaunt. Meine bisherigen (kurzen) Erfahrungen mit C# waren, dass die Programme, evtl wegen dem Overhead, doch um ein Stückchen langsamer waren. Naja, ich schau mir erstmal das Video davon an
-
Badestrand schrieb:
...also weil einige Konzepte einfach grundlegend verändert wurden verändert wurden (SIP z.B.)?...
Das ist genau der Punkt worum es in dem Projekt geht. Es ist ein Forschungsbetriebssystem an dem neue Konzepte ausprobiert werden. Heutige OS Architekturen sind auch net das gelbe vom Ei, und dort probiert man halt was anderes aus, was dem heutigen in einigen Bereichen überlegen ist.
Von den Ideen ist das Projekt wirklich hochinteressant.Nochmal zu dem Geschwindigkeitsding: Singularity ist in Sing# geschrieben welches eine Erweiterung von C# ist und damit eine managed Sprache - aber es wird nicht das .Net Framework benutzt wir wir es vom PC kennen. Das habe ich ja schon im vorherigen Beitrag vesucht zu erläutern dass der managed Code direkt in Maschinencode umgesetzt wird. Die Verwendung von managed Code hat halt den Vorteil das der Code von sich aus sicher ist. Wenn man jetzt dafür sorgt das der Compiler praktisch fehlerfrei arbeitet und der genügend verifiziert ist, dann ist automatisch sichergestellt das das ganze OS sicher ist. Das wird auf der Singularity Projektseite ja auch genannt, das ein großer Teil des Projektes sich auch mit dem Compiler, Codesicherheit, Verifizirbarkeit etc. befasst.
-
Ignoriert "du" einfach.
- Er ist ein Flamer aus dem Developia-Forum und mit TGGC "per du"
- Hat keinen Plan
- Flamer
- Uneinsichtig
- Nur auf seine beschränkte Sichtweise fixiertDer kann ruhig gebannt werden.
-
Talla schrieb:
...dass der managed Code direkt in Maschinencode umgesetzt wird. Die Verwendung von managed Code hat halt den Vorteil das der Code von sich aus sicher ist.
wenn er zu maschinencode umgewandelt wird, dann ist er aber nicht mehr 'managed'
ausserdem hab' ich irgendwo gelesen, dass in singularity auch etwas ASM und C stecken, task switcher, bootloader, interrupt-routinen etc. gehen wohl nicht mit C#.
-
Bouncer schrieb:
wenn er zu maschinencode umgewandelt wird, dann ist er aber nicht mehr 'managed'
Wieso nicht? Wenn du heute ein Programm aufm PC in irgend einer .Net Sprache schreibst wird das vor der ausführung auch in Maschinencode kompiliert und es ist trotzdem managed
Die Runtime und den GC z.B. gibts in Singularity genauso wie im .Net Framework aufn PC. Der einzige Unterschied ist halt das der Code nicht durch nen Jitter vorm Programmstart kompiliert wird, sondern schon vorher.Ob Maschinencode oder nicht hat mit managed Code gar nichts zu tun. Managed bezeichnet nur die Überwachung durch die Runtime und die gibts auch in Singularity.
ausserdem hab' ich irgendwo gelesen, dass in singularity auch etwas ASM und C stecken, task switcher, bootloader, interrupt-routinen etc. gehen wohl nicht mit C#.
ASM ja, C nicht, dafür aber C++
Mal dazu nen Ausschnitt aus "Singularity: Rethinking the Software Stack:"
Counting lines of code, over 90% of the Singularity kernel is written in Sing#.
While most of the kernel is type-safe Sing#, a significant portion
of the kernel code is written in the unsafe variant of the language.
The most significant unsafe code is the garbage collector, which
accounts for 48% of the unsafe code in Singularity. Other major
sources of unsafe Sing# code include the memory management
and I/O access subsystems. Singularity includes small pockets of
assembly language code in the same places it would be used in a
kernel written in C or C++, for example, the thread context
switch, interrupt vectors, etc. Approximately 6% of the
Singularity kernel is written in C++, consisting primarily of the
kernel debugger and low-level system initialization code.
-
Talla schrieb:
Ob Maschinencode oder nicht hat mit managed Code gar nichts zu tun. Managed bezeichnet nur die Überwachung durch die Runtime und die gibts auch in Singularity.
Dazu mal eine Frage (bitte um Nachsicht falls sie irgendwie deplaziert oder offtopic wirkt
:Kann man "native code", der mit einem Debugger im Einzelschritt ausgeführt wird, auch als "managed code" bezeichnen ?
-
Talla schrieb:
Ob Maschinencode oder nicht hat mit managed Code gar nichts zu tun. Managed bezeichnet nur die Überwachung durch die Runtime und die gibts auch in Singularity.
und wie will sie den code überwachen, wenn er direkt auf dem prozessor läuft? oder läuft der prozessor im single-step betrieb, so dass die runtime vor jedem befehl diesen überprüfen kann?
merker schrieb:
Kann man "native code", der mit einem Debugger im Einzelschritt ausgeführt wird, auch als "managed code" bezeichnen ?
besser 'managed' geht schon gar nicht mehr.
-
Bouncer schrieb:
oder läuft der prozessor im single-step betrieb, so dass die runtime vor jedem befehl diesen überprüfen kann?
Wie realistisch wäre das ? Sind Prozessoren schon "schnell genug" ? Aber dazu bräuchte man keine runtime.
-
merker schrieb:
Bouncer schrieb:
oder läuft der prozessor im single-step betrieb, so dass die runtime vor jedem befehl diesen überprüfen kann?
Wie realistisch wäre das ? Sind Prozessoren schon "schnell genug" ?
prozessoren mit hardwaremässiger debugger-unterstützung gibt's schon lange, z.b. bei einigen ARMs die sogenannte 'trace macrocell' --> http://www.arm.com/products/solutions/ETM.html
merker schrieb:
Aber dazu bräuchte man keine runtime.
klar doch. irgendwas muss ja entscheiden, ob das, was das programm gerade machen will, erlaubt ist.