Saubere Schichtentrennung in ReactOS?

Hier können Sie auf Deutsch diskutieren. Bedenken Sie, dass Sie in den englischen Foren mehr Nutzer ansprechen.

Moderators: frik85, EmuandCo, Dr. Fred

ThePhysicist
Developer
Posts: 509
Joined: Mon Apr 25, 2005 12:46 pm

Post by ThePhysicist »

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....
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.
Speicher: Keine Ahnung, aber wieso nicht?
Blackcrack wrote:wenn man beides, inc. die Bash/dos/ oder wie man das nennen mag, gleich so schreibt, daß es
Du kannst aber nicht die Bash shell mit DOS vergleichen(?)
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
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: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...
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!
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.
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..
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:... 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...
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: 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.
Wie jetzt DOS + Real Win obendrauf? Also Windows 95? Das hat bisher fast jedem geschadet, der es mal zwangsweise benutzt hat ;-)
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.
Blackcrack 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...
Das geht auch bei XP. google: nLite
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 ?
Wie schon gesagt, das funzt bei XP so wie es ist sehr gut und stabil.
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*
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.
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.
Blackcrack 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...
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-Panzers ;-)
Blackcrack wrote:uuppss.. ich wurde ja ausgeloggt *bg*
Ja das haste nu davon ;-)
Dr. Fred
Developer
Posts: 607
Joined: Wed Dec 22, 2004 10:09 pm
Location: Amsterdam

Post by Dr. Fred »

Ihr erwartet nicht ersthaft das ich eure langen posts lese oder ?

Aber hier gibt es ein paar Information über das ReactOS Kernel Design, für den Fall das es euch interessiert.

EDIT: Jetzt hab ich doch was gelesen.
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?
Ja, du irrst dich. Alles Mögliche aus dem Kernel auszulagern ist das Microkernel Prinzip, aber das ist eine Ressourcenverschwendung und schwieriger zu debuggen; darum hat es nicht durchgesetzt. Das einzige bekannte Os mit einem Microkernel ist MacOs X.
Where do you want ReactOS to go today ?
frik85
Developer
Posts: 829
Joined: Fri Nov 26, 2004 7:48 pm
Location: Austria, Europe
Contact:

Post by frik85 »

Dr. Fred wrote:Das einzige bekannte Os mit einem Microkernel ist MacOs X.
GNU Hurd :wink:

... , ja das gibt's wirklich (sogar 2 distros; eine davon von Debian) und basiert derzeit noch auf dem Mach (soll aber demnächst auf L4 umgeschrieben werden).
Dr. Fred
Developer
Posts: 607
Joined: Wed Dec 22, 2004 10:09 pm
Location: Amsterdam

Post by Dr. Fred »

frik85 wrote:
Dr. Fred wrote:Das einzige bekannte Os mit einem Microkernel ist MacOs X.
GNU Hurd :wink:

... , ja das gibt's wirklich (sogar 2 distros; eine davon von Debian) und basiert derzeit noch auf dem Mach (soll aber demnächst auf L4 umgeschrieben werden).
Ich meinte: Das einizige OS das von einer größeren Anzahl Meschnen genutzt wird.
Where do you want ReactOS to go today ?
e7
Posts: 92
Joined: Thu Dec 09, 2004 8:32 pm
Location: In Bayern ganz oben

Post by e7 »

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.
Sicherlich kann man das besser machen... Mein Vorschlag: Unter Win 9x konnte man Tasks direkt in dem Fenster killen, dass nach STRG+ALT+ENTF erschienen ist, unter Win2k/XP Prof ist da aber nur noch ein Button für den Taskmanager... In ROS könnte man ja wieder so eine Kill-Liste da einbauen... Schließlich kommt dieses Fenster fast immer zuverlässig, aber der Taskmanager nur manchmal...
Wie schon gesagt, das funzt bei XP so wie es ist sehr gut und stabil.
das "sehr" vor "gut und stabil" würde ich weglassen, wenn man die Stabilität mit der eines Linuxsystems vergleicht, kann XP einpacken...
frik85
Developer
Posts: 829
Joined: Fri Nov 26, 2004 7:48 pm
Location: Austria, Europe
Contact:

Post by frik85 »

e7 wrote:Mein Vorschlag: Unter Win 9x konnte man Tasks direkt in dem Fenster killen, dass nach STRG+ALT+ENTF erschienen ist, unter Win2k/XP Prof ist da aber nur noch ein Button für den Taskmanager... In ROS könnte man ja wieder so eine Kill-Liste da einbauen...
das "sehr" vor "gut und stabil" würde ich weglassen, wenn man die Stabilität mit der eines Linuxsystems vergleicht, kann XP einpacken...[/quote]
Das geht auch in WinNT (also WinXP, Win2k, NT 4, ...) mit folgender kombination:

Strg + Shift + Esc

Was man allerdings verbessern könnte wäre z.B.: dem Taskmanager von Haus aus beim start eine höhere priorität zu geben, wenn man speziell diese Tastenkombination drückt. Dann würde der Task-Manager auch sofort erscheinen. Außerdem wäre es nützlich wenn vorher das Programm welches ggf. im Vollbild-Modus läuft minimiert wird um freie Sicht auf den Taskmanager (welcher standardmäßig auf "immer imvordergrund" sein sollte) zu haben.
Dr. Fred
Developer
Posts: 607
Joined: Wed Dec 22, 2004 10:09 pm
Location: Amsterdam

Post by Dr. Fred »

frik85 wrote:Was man allerdings verbessern könnte wäre z.B.: dem Taskmanager von Haus aus beim start eine höhere priorität zu geben, wenn man speziell diese Tastenkombination drückt. Dann würde der Task-Manager auch sofort erscheinen. Außerdem wäre es nützlich wenn vorher das Programm welches ggf. im Vollbild-Modus läuft minimiert wird um freie Sicht auf den Taskmanager (welcher standardmäßig auf "immer imvordergrund" sein sollte) zu haben.
Unser Scheduler ünterstützt (noch) keine prioritäten.
Where do you want ReactOS to go today ?
frik85
Developer
Posts: 829
Joined: Fri Nov 26, 2004 7:48 pm
Location: Austria, Europe
Contact:

Post by frik85 »

Dr. Fred wrote:Unser Scheduler ünterstützt (noch) keine prioritäten.
Ich weiß, meinte aber auch WinXP :wink:
TiKu
Posts: 157
Joined: Wed Jan 05, 2005 9:09 pm
Location: Unterföhring, Germany
Contact:

Post by TiKu »

Also bei mir kommt unter WinXP bei Strg+Alt+Entf sofort der Taskmanager. Kann man vermutlich irgendwie einstellen.*noahnung*
frik85
Developer
Posts: 829
Joined: Fri Nov 26, 2004 7:48 pm
Location: Austria, Europe
Contact:

Post by frik85 »

TiKu wrote:Also bei mir kommt unter WinXP bei Strg+Alt+Entf sofort der Taskmanager. Kann man vermutlich irgendwie einstellen.*noahnung*
Dieses verhalten ist aber nur der Fall wenn dein WinXP nicht an einer Domain-Server (Win2k/2k3 Server) angeschlossen ist. Denn dann kommt statt dessen das "Sicherheitsfenster" (oder so ähnlich), wo man den PC sperren kann, Task Manager aufrufen, etc.
Matthias
Posts: 496
Joined: Tue Dec 27, 2005 12:43 am

Post by Matthias »

Dr. Fred wrote:Ihr erwartet nicht ersthaft das ich eure langen posts lese oder ?

Aber hier gibt es ein paar Information über das ReactOS Kernel Design, für den Fall das es euch interessiert.

EDIT: Jetzt hab ich doch was gelesen.
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?
Ja, du irrst dich. Alles Mögliche aus dem Kernel auszulagern ist das Microkernel Prinzip, aber das ist eine Ressourcenverschwendung und schwieriger zu debuggen;
Ressourcenverschwendung in dem Sinne ist das nicht, man erkauft sich mehr Stabilität mit ein wenig Performance. Und bei richtigen Prozessoren (z. B. POWER/PowerPC) sind Kontext-Switches so schnell, daß sich ein Mikrokerneldesign nur in geringem Maße auf die Performance auswirkt.
Dr. Fred
Developer
Posts: 607
Joined: Wed Dec 22, 2004 10:09 pm
Location: Amsterdam

Post by Dr. Fred »

Matthias wrote:Ressourcenverschwendung in dem Sinne ist das nicht, man erkauft sich mehr Stabilität mit ein wenig Performance.
Welchen Sinn hat es denn wenn man z.B. den Memory Manager auslagert ? Wenn der abstürtzt, dann nützt es wenig wenn der Rest von System noch weiter läuft oder sehe ich das falsch ?
Matthias wrote:Und bei richtigen Prozessoren (z. B. POWER/PowerPC) sind Kontext-Switches so schnell, daß sich ein Mikrokerneldesign nur in geringem Maße auf die Performance auswirkt.
Solche "richtigen Prozessoren" sind nun mal leider nicht so verbreitet wie der x86.
Where do you want ReactOS to go today ?
TiKu
Posts: 157
Joined: Wed Jan 05, 2005 9:09 pm
Location: Unterföhring, Germany
Contact:

Post by TiKu »

Dr. Fred wrote:
Matthias wrote:Ressourcenverschwendung in dem Sinne ist das nicht, man erkauft sich mehr Stabilität mit ein wenig Performance.
Welchen Sinn hat es denn wenn man z.B. den Memory Manager auslagert ? Wenn der abstürtzt, dann nützt es wenig wenn der Rest von System noch weiter läuft oder sehe ich das falsch ?
Ich denke, er ließe sich dann leichter durch einen anderen ersetzen, der für einen bestimmten Einsatzzweck möglicherweise besser geeignet wäre.
Für den Standardnutzer dürfte es freilich egal sein, ob das Ding nun im Kernel steckt oder nicht.
Matthias
Posts: 496
Joined: Tue Dec 27, 2005 12:43 am

Post by Matthias »

Dr. Fred wrote:
Matthias wrote:Ressourcenverschwendung in dem Sinne ist das nicht, man erkauft sich mehr Stabilität mit ein wenig Performance.
Welchen Sinn hat es denn wenn man z.B. den Memory Manager auslagert ? Wenn der abstürtzt, dann nützt es wenig wenn der Rest von System noch weiter läuft oder sehe ich das falsch ?
Das schon, aber wenn z. B. der Dateisystem- oder Soundtreiber hängt, interessiert das Prozesse, die diese nicht brauchen, überhaupt nicht.
Post Reply

Who is online

Users browsing this forum: No registered users and 14 guests