GUI: Weil Windows ein Desktop-OS ist und ohne GUI nicht sehr sinnvoll. (Is bei Linux etwas anders) GUI muss schnell sein, also hat man sie in den Kernel gesteckt.Blackcrack wrote:Auf die Gui nochmal zu kommen, die im ntos kernel anscheinend drin iss... was sucht die bitte im Kernel eines Systems, genauso die Speicherverwaltung....
Speicher: Keine Ahnung, aber wieso nicht?
Du kannst aber nicht die Bash shell mit DOS vergleichen(?)Blackcrack wrote:wenn man beides, inc. die Bash/dos/ oder wie man das nennen mag, gleich so schreibt, daß es
Speicherverwaltung als Dienst: Das kann meiner Meinung nach gar nicht funzen, da man ohne Speicherverwaltung Dienste gar nicht starten kann, oder irre ich mich da? Außerdem was ist, wenn ein Programm mal eben den Speicherdienst beendet? Dann ist das System tot! Keine gute Idee, denk ich.Blackcrack wrote:A: am Anfang ein Multiusersystem unterstützt, somit auch eine user-trennung vom Speicher
möglich währe, dann das Speichermanagment als Dienst rennt und sowie
Also da bin ich mit WinXP sehr zufrieden. Wenn da was schief läuft: einfach user abmelden und neu anmelden, dann läuft's eigentlich fast immer wieder. wenn ich als Admin angemeldet bin und hab kein Bock mehr auf was auch immer da als Benutzerxyz ausgeführt wird, dann trenn ich einfach die Verbindung und in Nullkommanix is die Session weg!Blackcrack wrote:dann jeder einzele User/Login voll als selbständige Einheit rennen würde, dann könnte
man selbst Userlogins locker als admin schnell mal kicken, ohne daß das System als solches zum stocke kommt und sauber weiter rennt...
Einzigster Schwachpunkt: Der Taskmanager! Wenn das System stark ausgelastet ist, kanns ewig dauern, bis das Teil da ist. Aber das kann man bei ROS bestimmt besser machen, ohne an der Schichtentrennung rumzuwerkeln.
Also der Terminalserver unter Windows ist verdammt schnell, solange man keine Graphic-Sachen macht. Schneller als VNC oder sowas. Ich kann nicht sagen wie das im Vergleich mit Linux ist. Aber wichtiger ist bei nem Desktop OS, dass die lokale gui schnell ist!Blackcrack wrote:ich denk mir, daß da dann eine Gui.dll währe, die mehrere Instanzen im Speicher rennen llassen könnte... da währe dann das vielleicht möglich, daß man genau diese Gui übers netz per ssh oder so rennen lassen
könnte und man kommt sich vor als wenn man direckt am rechner sitzt.. irgendwie so..
Um Windows mit ner Konsole zu starten braucht man kein DOS. Die kann man bei XP übrigends a) von der CD starten oder b) installieren und dann direkt booten. Ohne DOS! Aber nett wäre ein DOS irgenwann schon mal, aber das hat keine Priorität.Blackcrack wrote:... Dos iss wichtig.. da kann man ne box drauf rennen lassen, terminalemu und so spielerreien *bg* ach, nich nur... wenn die Gui mal nich rennen sollte, dan hat man immernoch ne oberfläche, in der man die möglichkeit hat, das System zu retten.... so seh ich das...
Wie jetzt DOS + Real Win obendrauf? Also Windows 95? Das hat bisher fast jedem geschadet, der es mal zwangsweise benutzt hatBlackcrack wrote: also, mal ganz ehlich... bis jetzt hats noch nirged geschadet, wenn man Dos als Grundsystem genommen hat und da dann ein Real-Win32-System drauf aus fetzt, selbst bei der installation wird ein dos genommen...
iss doch so.. oder ? im Grunde könnte man die Installation so gestalten, daß gleich ein Grafischer Server zu rennen gebraucht wird und dort dann VB drauf rennen lassen würde... und sich von der dos-installationsroutine ganz trennt... Heut zu tage macht jede Graka SVGA und genau das könnte man zusamen mit VB dann bei der Install-Routine nutzen.
Und bei der installation wird kein DOS genommen. Da wird ebenfalls NT gebootet, nur ohne GUI, auf die man beim 1st stage setup gut verzichten kann.
Und was meinst du mit VB? Visual Basic? Und wieso SVGA? Man kann doch einfach nen GraKa-Treiber laden. Ich raff das net.
Das geht auch bei XP. google: nLiteBlackcrack wrote:Das so screiben, daß ein Installscript abgearbeitet wird, das von User oder von Systemadmins geendert werden kann und auch die möglichkeit gibt locker und flockig noc andere verzeichnisse bei der installation wegen Treiber durchsuchen lassen per -R, in dem Installscript sollte es auch möglich sein, gleich auch div. manuelle zusatz-registry-einträge
zusätzlich ein bauen zu lassen, daß man so sein eigenes Win zusammen friekeln kann...
Wie schon gesagt, das funzt bei XP so wie es ist sehr gut und stabil.Blackcrack wrote:eigendlich sind wir ja bei Schichten Trennung.... jo... also, warum nich guggen, daß das System so geschriben wird, daß es nichts aus macht, wenn mal ein Login hängt oder ein Programm im Speicher als zombi hängen darf, diesen aber dann erkennen lassen und
per hintergrundroutine automatisch killen lassen... je ausgereifter die Schichtentrennung eines Systems ist, sag.. behaupte ich mal, um so besser lässt es sich nahher händeln...stimmt doch.. oder ?
Sauberes programmieren ist hier natürlich wichtig und deswegen kann man die Speicherverwaltung auch gleich in den Kernel stecken, weil wenn die abkackt, geht eh nix mehr.Blackcrack wrote:das einzige was nahher echt sauber geschrieben werden muss.. ist die Speicherverwaltung/mangment.. und die vielleicht per Assembler-code.... Ihr müsst ja nicht nur in c oder c++ programmieren.. ihr könnt ja variiren und das beste vom besten nehmen..*schulterzuck*
Aber ASM eignet sich sehr wenig, um "sauber" zu programmieren! Die devs sind davon ab ASM zu benutzen. Man braucht es lediglich für ganz wenige Sachen wie den Bootsektor (oder ist der inzwischen auch schon in C?) Die einzigen Vorteile, die ASM bringt sind codesize und Geschwindigkeit, und das auch nur, wenn man wirklich gut programmiert. C compiler können oftmals besser optimieren, als der Mensch. Außerdem ist ASM nicht portable.
128Bit? Bis es 128 Bit systeme gibt, vergehen wohl noch ein paar Jährchen. Und ich würde es bevorzugen, wenn ROS erstmal ein schicker Kleinwagen wird, später vielleicht ein Kombi oder ein Sportwagen, statt eines atomgetriebenen fliegenden Unterwasser-Ketten-Rad-Raketen-PanzersBlackcrack wrote: warum nicht ein ein Allroundsystem schreiben (so alla amphibie (mit dem auto aufs wasser)) aber sich trotzdem auf der Seite von Win64/32/16 halten.. denn die 64bit Maschinen sind ja im kommen... so kann kann man später dann weiter aufbauen auf 182 in dem mal blos den Assember-speichermanager auswächelt und eine Win32-emu auf 64-bit hin zu fügt.. das gleiche dannspäter auf 128bit... und die 16bit proggys rennen immernoch...
Ja das haste nu davonBlackcrack wrote:uuppss.. ich wurde ja ausgeloggt *bg*