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

R2D2
Posts: 3
Joined: Fri Dec 23, 2005 2:06 pm

Saubere Schichtentrennung in ReactOS?

Post by R2D2 »

Ich weiß natürlich nicht, ob das überhaupt bei einer angestrebten Kompatibilität mit XP (und was noch so danach kommT) möglich ist, doch würde mich mal interessieren, ob bei ReactOS versucht wird, sauberer die einzelnen Programmschichten voneinander zu trennen. Soll heißen, dass, so wie es bei Unix/Linux eine saubere Trennung zwischen Betriebssystemkern (Kernel) und grafischer Benutzeroberfläche geben wird - eben so wie es in der Informatik sinnvollerweise auch gefordert wird. Die bekannten Windows Schwächen kommen nicht von ungefähr und sind zu einem großen Teil eben aucd in der Vermengung von Kernelfuktionen und all jenen Dingen zu finden, die in einem Kernel eigentlich gar nichts zu suchen haben!
Dr. Fred
Developer
Posts: 607
Joined: Wed Dec 22, 2004 10:09 pm
Location: Amsterdam

Post by Dr. Fred »

Ich weiß natürlich nicht, ob das überhaupt bei einer angestrebten Kompatibilität mit XP (und was noch so danach kommT) möglich ist,
Nein.
doch würde mich mal interessieren, ob bei ReactOS versucht wird, sauberer die einzelnen Programmschichten voneinander zu trennen. Soll heißen, dass, so wie es bei Unix/Linux eine saubere Trennung zwischen Betriebssystemkern (Kernel) und grafischer Benutzeroberfläche geben wird - eben so wie es in der Informatik sinnvollerweise auch gefordert wird.
Siehe http://www.reactos.org/xhtml/en/dev_faq ... hicssubsys
Die bekannten Windows Schwächen kommen nicht von ungefähr und sind zu einem großen Teil eben aucd in der Vermengung von Kernelfuktionen und all jenen Dingen zu finden, die in einem Kernel eigentlich gar nichts zu suchen haben!
Kannst du das irgendwie belegen ?
Where do you want ReactOS to go today ?
R2D2
Posts: 3
Joined: Fri Dec 23, 2005 2:06 pm

Post by R2D2 »

Dr. Fred wrote:
Ich weiß natürlich nicht, ob das überhaupt bei einer angestrebten Kompatibilität mit XP (und was noch so danach kommT) möglich ist,
Nein.
schade
Dr. Fred wrote:
doch würde mich mal interessieren, ob bei ReactOS versucht wird, sauberer die einzelnen Programmschichten voneinander zu trennen. Soll heißen, dass, so wie es bei Unix/Linux eine saubere Trennung zwischen Betriebssystemkern (Kernel) und grafischer Benutzeroberfläche geben wird - eben so wie es in der Informatik sinnvollerweise auch gefordert wird.
Siehe http://www.reactos.org/xhtml/en/dev_faq ... hicssubsys
interessant
Dr. Fred wrote:
Die bekannten Windows Schwächen kommen nicht von ungefähr und sind zu einem großen Teil eben aucd in der Vermengung von Kernelfuktionen und all jenen Dingen zu finden, die in einem Kernel eigentlich gar nichts zu suchen haben!
Kannst du das irgendwie belegen ?
Kann ich - sogar mit Deine Hilfe!
1. Auszug aus der Definition eines Betriebssystems:
Betriebssysteme bestehen in der Regel aus einem Kern (englisch: Kernel), der die Hardware des Computers verwaltet, sowie grundlegenden Systemprogrammen, die dem Start des Betriebssystems und dessen Konfiguration dienen. Das ist alles was ein Kernel i.d.R. tun soll, Windows geht da entschieden weiter.
2. Dein oben ausgewiesener Link sagt es deutlich, welche grundlegende Schwäche damit einherkommt:
This does make the architecture less clean of course, and when the GUI crashes, the whole system crashes.
Matthias
Posts: 496
Joined: Tue Dec 27, 2005 12:43 am

Post by Matthias »

Außer dem Grafiksystem wüsste ich aber nichts, was im WinNT-Kernel enthalten ist und nicht da sein sollte.
tscherno
Posts: 6
Joined: Tue Nov 01, 2005 7:39 pm

Post by tscherno »

Imho ist bei Windows die Trennung sogar besser: Schau dir doch mal Linux an, da muss wegen jeder Kleinigkeit der Kernel neu kompiliert werden und bei einer Änderung funktioniert überspitzt gesagt die Hälfte der Software erstmal nicht.

Klar es bringt einen großen Geschwindigkeitsvorteil aber schadet auch der Usability. Ich kann mir nähmlich bei bestem willen nicht vorstellen das meine Vater irgendwann Kernel kompilieren kann/will.

Und mit dem Grafiksubsystem im Kernel verhält es sich ähnlich:

Ist es im Kernel hat man Geschwindigkeitsvorteile.
Ist es im User-Space so ist das OS stabiler und die Oberfläche langsamer.

Also ein zweischneidiges Schwert =)

Der einzige Nachteil in der Windows Architektur ist meiner Meinung nach dass API Aufrufe über die Jahre vielfach redundant geworden sind um die Rückwertskompatibilität zu wahren. (Viele API Aufrufe für die Selbe Funktion)

gruss
Matthias
Posts: 496
Joined: Tue Dec 27, 2005 12:43 am

Post by Matthias »

tscherno wrote:Imho ist bei Windows die Trennung sogar besser: Schau dir doch mal Linux an, da muss wegen jeder Kleinigkeit der Kernel neu kompiliert werden und bei einer Änderung funktioniert überspitzt gesagt die Hälfte der Software erstmal nicht.
Wovon redest Du? Ich habe seit Monaten hier ein Linux laufen, und musste noch *nie* einen neuen Kernel kompilieren, höchstens mal ein paar Module (z. B. vom Grafiktreiber). Davon abgesehen ist es klar, daß Linux-User den Kernel öfter neu kompilieren müssen, denn diese Möglichkeit haben Windows-Benutzer gar nicht.
ThePhysicist
Developer
Posts: 509
Joined: Mon Apr 25, 2005 12:46 pm

Post by ThePhysicist »

Matthias wrote: Wovon redest Du? Ich habe seit Monaten hier ein Linux laufen, und musste noch *nie* einen neuen Kernel kompilieren, höchstens mal ein paar Module (z. B. vom Grafiktreiber).
Ich hab seit Jahren ein Windows laufen und noch nie irgendwas davon kompiliert.
Ich versteh das ganze Kernel-Kompiliere bei Linux eh nicht. In den Kernel gehört meiner Meinung nach nix hardware-spezifisches. Dafür gibt es HAL und Treiber. Bei Linux muss man ja sogar wegen ner neuen Netzwerkkarte oder ner neuen Firewall den Kernel neu kompilieren. Das ist ja fast so als müsste man am Vergaser seines Autos rumschrauben, weil man ein neues Radio eingebaut hat oder die Reifen gewechselt.
Matthias wrote: Davon abgesehen ist es klar, daß Linux-User den Kernel öfter neu kompilieren müssen, denn diese Möglichkeit haben Windows-Benutzer gar nicht.
Merkwürdige Logik: weil es bei Windows nicht geht, muss man es bei Linux machen?
Bei Windows braucht man das einfach nicht zu machen und trotzdem läuft alles ordentlich und schnell. Man muss höchstens mal schnell nen Treiber installieren.
Ich will keineswegs behaupten Windows sei perfekt oder Linux sei schlecht, aber was das Kernel-Design angeht ist Windows IMHO besser.
Blackcrack
Posts: 1808
Joined: Tue Dec 20, 2005 12:55 pm
Contact:

Post by Blackcrack »

Hy,

Tcherno, es gibt zwei arten, Treiber im Linux-Kernel zu nutzen, einmal fest ein gebunden, dann muss man :

make bzImage modules modules_install bzlilo

machen und den kernel durch rennen lassen und dann noch die zweite Möglichkeit

make modules modules_install

wenn man lediglich module einbauen möchte...

da werden dann nur noch die Module zusammen geschraubt die als Treiber dienen, jeh nach dem was als Modul angeklickt ist
aber wenn man die ganzen Treiber als Module gleich erstellen lässt, braucht man im leben eines Computer den kernel nur einmal zu compelieren im Linux, aber da man im Linux die möglihkeit hat, sein System schlank zu halten und die Bootzeit dadurch dann auch zu verkürtzen, kann man da dann nur noch das nötigste zusammen schrauben, entweder als module, die eingehängt am Kernel sind oder oder direckt in den kernel. Bei einstelleung der ganzen Module/Treiber werden aber auch nur die nötigsten Module geladen, die bootzeit leidet deshalb nicht, da ur di nötigsten Module geladen werden, aber dafür ist das System dann recht Flexibel und man kann die Festplatte dann auch überall rann hängen und es leuft einfach, weil alle "Treiber"/module zu verfügung stehen die div. Computer brauchen, wa aber an einem Standatsysten, zum beispiel für den Home-gebrauch im grunde brach liegen, wenn die ganzen Treiber als Module brach liegen...Wenn man aber weis, daß man die Pladde überall reinstecken will, daß es rennt, und man hat alle"Treiber" als module schon auf der Pladde, hat linux den Vorteil, daß es als solches nich rum zickt und einfach bootet, und der Hardware-Manager der meisten Distriebutionen (Linux-zusammenstellungen) stellt dann die ganzen Module deren Hardware durch den Manager gefunden werden, zu verfügung, die dann geladen wrden...Selbst Hal gibt es im Linux, wird derzeit bei KDE erwendet und rennt wunderbar.. USB-Stic Kamera und andere sachen.. die bediehnt hal.. aber auch noch andere sachen.. seit KDE 3.4 oder noch jünger wird Hal in QT/KDE verwendet.

Ach ja, was ich noch vergessen hab, die Standart-Kernel der Distriebutoren, sind schon alle Module die als Treiber dienen vorcompeliert und werden nur noch in das System gelegt per packetmanager(rpm/deb), es sind also am Anfang eines Standart-Linux-Systems alle derzeitigen "Treiber"/Module vorhanden und brauchen nicht nach compeliert werden, auc die Netzwerk"Treiber" und Protokolle die meistens als Module compeliert werden,
wenn nicht custom, liegegen schon breit... das heist, nur die Leutz, die was von Ihrem Sys verstehen, bauen dies masgeschneidet auf Ihren computer und lassen das, was sie wissen, was i.o.ist, direckt im Kernel um die bootzeit zu verkützen.. hummm..... also standart, einen neuen Kernel zusammen zu bauen.. ist das im grunde heute nicht mehr,
da wird nur noch .. für den anfänger/Normaluuser und so, ein rpm/deb-packet installiert
und das wars dann..

Der dicke vorteil von Modulen zu treibern ist es, daß man im Linux, die Module laden, aber auch wieder unloaden kann, während das System andere Sachen macht... und sich u.U. 200 User ein geloggt haben(nur mal als Beispiel).... es findet also keine System-Unterbrechung statt..

Wenn also die PC-Desktop-Hardware es unterstützen würde, dann bräuchte man den computer um ne Festplatte oder ne GrafiKKarte aus zu tauschen nie runter zu fahren im Linux... da jedes Gerät direckt explizit angesteuert werden kann im Linux.

humm.. wenn ich's mir recht überleg gibbet sogar mehr arten, den kernel im Linux zu nutzen :)

Humm.. und nu steck mal ne XP installation an irgendweinen beliebigen Computer...
hast du auch die ganzen Treiber-CD's dafür *s* ach ja, dann sollte man da ja noch ne Nummer erfragen vom Microsoft um sich als Registrierte Anwender nochmal melden (zu müssen) ;)

liebe Grüße
Blacky
nightshade
Posts: 14
Joined: Fri Dec 30, 2005 7:19 pm
Location: w4.noe.austria
Contact:

Post by nightshade »

... Module geladen, die bootzeit leidet deshalb nicht, da ur di nötigsten Module geladen werden, aber dafür ist das System dann recht Flexibel und man kann die Festplatte dann auch überall rann hängen und es leuft einfach, weil alle "Treiber"/module zu verfügung stehen ...
Nun ja, warum hab ich dann noch nie ein Linux gesehen, das schneller als mein Windows gestartet is? Mein USB-Festplatte kann ich auch nicht nach belieben ein und ausstecken. Wenn ich unter Win mein Hdd einsteck und es is der buchstabe U: frei, funktioniert es einfach. Unter Linux kennt er zwar die platte, wenn ich aber vorher eine andere platte eingesteckt hab, passt der mountpoint nicht mehr und er versucht das falsche dateisystem zu verwenden und es klappt irgendwie einfach nicht zuverlässig.

Wenn ich meine usb mircrosoft maus beim booten eingesteckt hab, dann auf ps/2 umsteck, weil ich meine hdd brauch (hab nur einen usb stecker), funktioniert das nicht. Denn mein touchpad wird auch als ps/2 maus entdeckt, und die kollidieren anscheinend.
Thema WLAN (Netgear 108 Mbit/s-karte): nein dazu sag ich ab besten gar nichts

Auf meinem hauptpc funktioniert sowieos überhaupt keine grafische benutzeroberfläche von haus aus (ATI Radeaon X800).
Bei Win muss ich zwar einen treiber installieren, dass es schneller läuft, aber es läuft wenigstens von anfang an ...
Bei Linux muss ich mir die treiber im internet suchen, wenn's blöd hergeht, bekomm ich nur die sourcen und muss selber kompillieren, blöd nur, um platz zu sparen hab ich bei der installation make, gcc usw nicht installiert ... Wie mach ich das jetzt auf der command line?
Und da helfen mir all die vielen module nicht weiter, is ja schön wenn ich einen treiber für eine uralt logitech maus dabeihab, oder ein modul für eine alte bnc netzwerkkarte, aber ...

Nicht falsch verstehen, ich bin gerade im bereich server von linux überzeugt, gerade wegen sicherheit und auch stabilität - da gibt's gar nichts zu bemängeln. Mein samba server läuft und läuft und läuft (nein, keine duracel batterien *g*). Aber im bereich desktop kann kde/gnome einfach nicht mithalten. Vllt liegt es daran, dass ich ein windows poweruser bin, der alles mit shortcuts macht, aber es ist einfach alles nicht so rund (uB die geschwindigkeit, der aufbau der oberfläche). Ein bsp ist: wenn ich in win ein maximiertes fester zumachen will, schmeiß ich meinen mauszeiger ganz rechts oben in die bildschirmecke, klick einmal und das fenster is weg. Der button wird gar nicht getroffen, aber die programmierer habe sich wahrscheinlich was dabei gedacht, er reagiert nämlich trotzdem. Das funktioniert auch bei meinem selbst erstellten windows style. Unter linux muss ich den button genau treffen, da der rahmen so dick is, das es sich nicht ausgeht. Das kann man zwar aussteleln, damit er nicht mehr sichtbar ist, aber dann funktioniert es auch nicht. Bleibt nur noch zielen oder Alt-F4.
Ein weiteres bsp gefällig: Unter windows wird jeder ordner so angezeigt, wie ich ihn verlassen hab (zB symbolgröße und -anordnung, ordnermaße, oderkoordinaten). So will ich das haben, damit alles an seinem platz is. Unter linux? Hmm, naja ...
Das sind eben so die kleinen probleme, die man hat. Das letzt gesagte dürft ihr nicht als allgemeingültige wahrheit nehmen, sind nur meine persönlichen, ganz subjektiven gedanken.

Ach ja nochwas. Der vergleich ntoskrnlmit linux kernel hinkt. ntoskrnl is ein microkernel, linux is ein monolithischer kernel (nicht mehr ganz, wegen der nachladbaren module)
TiKu
Posts: 157
Joined: Wed Jan 05, 2005 9:09 pm
Location: Unterföhring, Germany
Contact:

Post by TiKu »

Ein Microkernel ist ntoskrnl auch nicht. Microkernel heißt, dass wirklich nur das allernötigste im Kernel ist und selbst Sachen wie die Speicherverwaltung ausgelagert werden.

Um mal zum Thema zurückzukommen:
Es heißt, Microsoft würde bei Vista die GUI wieder aus dem Kernel rausnehmen. Das kann aber auch ein Gerücht sein, denn offizielle Statements von Microsoft habe ich zu dem Thema noch nicht gefunden.
Dr. Fred
Developer
Posts: 607
Joined: Wed Dec 22, 2004 10:09 pm
Location: Amsterdam

Post by Dr. Fred »

TiKu wrote:Ein Microkernel ist ntoskrnl auch nicht. Microkernel heißt, dass wirklich nur das allernötigste im Kernel ist und selbst Sachen wie die Speicherverwaltung ausgelagert werden.
Ich glaube man hat sich geeinigt das es ein Hybrid-Kernel ist.
TiKu wrote:Es heißt, Microsoft würde bei Vista die GUI wieder aus dem Kernel rausnehmen. Das kann aber auch ein Gerücht sein, denn offizielle Statements von Microsoft habe ich zu dem Thema noch nicht gefunden.
Hier ein Quote von frik85 aus einem anderen Thread.
frik85 wrote:Some passages from IRC:
Someone asked:
Is it planned to follow the Vista model of moving GUI code out of kernel mode (win32k) and if so, are there plans to follow/support the LDDM/VDDM?


Alex_Ionescu:

1) win32k will not be moved out in vista. GUI code will not be moved out in vista. nothign will be moved out in vista.

2) we are not trying to move the kernel to user-mode. we are trying to get it running in a user-mode environment in linux or windows.

3) vista will not change the model. and remember that win32k is a driver, not part of the kernel; much like xfree86/xorg, afaik, has kernel modules

4) you read what some idiots from the beta program leaked out and was misunderstood by the press

5) if someone tells you about vista graphics in user-mode, it's not true


and btw. we have a branch that are trying move the kernel to user mode (the whole kernel) and it was started before vista existed
Ich habe das ganze ein wenig zusammen gefasst. Ich hoffe ihr könnt das englische es verstehen.
Where do you want ReactOS to go today ?
Dr. Fred
Developer
Posts: 607
Joined: Wed Dec 22, 2004 10:09 pm
Location: Amsterdam

Post by Dr. Fred »

nightshade wrote:Mein USB-Festplatte kann ich auch nicht nach belieben ein und ausstecken. Wenn ich unter Win mein Hdd einsteck und es is der buchstabe U: frei, funktioniert es einfach. Unter Linux kennt er zwar die platte, wenn ich aber vorher eine andere platte eingesteckt hab, passt der mountpoint nicht mehr und er versucht das falsche dateisystem zu verwenden und es klappt irgendwie einfach nicht zuverlässig.
Kann man aber hingekommen. Für das automatische Mounten ist ein Script names Hotplug zuständig, dem man sagen kann eine bessimte platte immer auf einen bestimmten Mountpunkt mounten soll.
Thema WLAN (Netgear 108 Mbit/s-karte): nein dazu sag ich ab besten gar nichts
Dann sag ich auch nichts dazu. ;)
Bei Linux muss ich mir die treiber im internet suchen, wenn's blöd hergeht, bekomm ich nur die sourcen und muss selber kompillieren, blöd nur, um platz zu sparen hab ich bei der installation make, gcc usw nicht installiert ... Wie mach ich das jetzt auf der command line?
Das kommt auf die Disto an. Bei debain so:
apt-get install links
links http://google.de (nach treiber so suchen und runterladen)
apt-get intstall gcc make (und was man sonst so braucht)
Unter *nix kann man eigendlich alles von der Commandline aus machen.
Das sind eben so die kleinen probleme, die man hat. Das letzt gesagte dürft ihr nicht als allgemeingültige wahrheit nehmen, sind nur meine persönlichen, ganz subjektiven gedanken..
Simmt, ein gehohnheits KDE/Gnome nutzer wird sicher auch viele futures vermissen, wenn er mit Windows arbeitet.

Ich bin übrigends auch Windows User.

EDIT:
Ach ja nochwas. Der vergleich ntoskrnlmit linux kernel hinkt. ntoskrnl is ein microkernel, linux is ein monolithischer kernel (nicht mehr ganz, wegen der nachladbaren module)
Wieso das denn ? Man kann 2 Kernel doch trotzdem vergleichen auch wenn sie verschiedene Architekturen haben.
Last edited by Dr. Fred on Fri Feb 03, 2006 2:16 pm, edited 1 time in total.
Where do you want ReactOS to go today ?
Dr. Fred
Developer
Posts: 607
Joined: Wed Dec 22, 2004 10:09 pm
Location: Amsterdam

Post by Dr. Fred »

Blackcrack wrote:[jede menge über module]
Die Module unter Linux sind imho ein relativ guter Hack. Nicht mehr und nicht weniger.
Blackcrack wrote:Selbst Hal gibt es im Linux, wird derzeit bei KDE erwendet und rennt wunderbar.. USB-Stic Kamera und andere sachen.. die bediehnt hal.. aber auch noch andere sachen.. seit KDE 3.4 oder noch jünger wird Hal in QT/KDE verwendet.
Dann wird der Begriff aber anderes verwendet als in Windows
Der dicke vorteil von Modulen zu treibern ist es, daß man im Linux, die Module laden, aber auch wieder unloaden kann
Kann Nt auch.
Wenn also die PC-Desktop-Hardware es unterstützen würde, dann bräuchte man den computer um ne Festplatte oder ne GrafiKKarte aus zu tauschen nie runter zu fahren im Linux... da jedes Gerät direckt explizit angesteuert werden kann im Linux.
Wenn das kein konstruiertes Argument ist ....
humm.. wenn ich's mir recht überleg gibbet sogar mehr arten, den kernel im Linux zu nutzen :)
Was meinst du damit ? Das man ihn auch auf PDAs, MP3 Playern, Kühlschränken, Toastern und so installieren kann ?
Where do you want ReactOS to go today ?
Blackcrack
Posts: 1808
Joined: Tue Dec 20, 2005 12:55 pm
Contact:

Post by Blackcrack »

Hallole :)

PDA's umgebaute Toaster mit Festplatte und CPU, X-Box und und und...,
geht alles, aber dann sid das spezielle kernel.. mit spetziellen Treiber die da dann darauf platz finden, der allgemeine Kernel kann mann vergessen... denk ich mal *bg* Der iss einfach zu klein *lol*

Auf die Gui nochmal zu kommen, die im ntos kernel anscheinend drin iss... was sucht die bitte im Kernel eines Systems, genauso die Speicherverwaltung.... wenn man beides, inc. die Bash/dos/ oder wie man das nennen mag, gleich so schreibt, daß es
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
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... 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.. iss klar, ich hab keinen blassen vom programmieren, geb ich offen zu, aber ich kann mir mit meinen paar jährchen Poweruzer dasein vorstellen, wie das eventuell sein könnte...
Ich bin jetzt zwar nach Linux gewechselt um einach woanders mein Hobby aus zu leben, weils einfach zu heftig verfolgt wird, aber ich hatte denk ich mal so viel in der Hand, daß ich weis was so Sache iss..aber bitte, ich lehrne gern dazu ;)
Aber eins muss ich sagen, wenn ich so die Programm-verwaltung von Linux im gegesatz zu windows angugg, dann iss das im linux echt um einiges ausgereifter, wenn Ihr das so ähnlich als Win32 System mit 16Bit emulation +Dos VDM hin bekommen würdet, wäret Ihr manchen Win32 Systemen ziemlich vorraus....humm....
Win32Grundsystem, das die Treiber annimmt, dann die Gui und Speicherverwaltung, da
dann wenn gebraucht ein Win16Bitemu sowie ein VDM drauf.... auf der man Supervga sachen rennen lassen kann.. ich denk an die alten Demos, die im Dos damals liefen, wenn die laufen, rennt soweit der rest im dos auch denk ich mir mal... 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... 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.
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...
daß dann genau so steht, wie man es gerne selber so haben möchte...
Möglichkeit geben, daß man die Installation anders ausseen lassen kann, per skining und auch gleich in dem Skript festlegt, welches skin später als Standatskin verwendet wird... und welches Login-Skin auch genommen wird... uhh.. bin ich abgeschweift.......

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 ? 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* 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... somit hat man später dann die möglichkeit merer XXBit Systeme auf einer CD an zu bieten, die dann per installroutine automatisch bestimmt werden können und dann entweder das 16bit-install-script, 32bit-install-script oder auch das 64bit-install-script automatisch auswählen lassen könnte......so.. jetzt hab ich abergenug getippert...

liebe Grüße
Blacky

uuppss.. ich wurde ja ausgeloggt *bg*
Matthias
Posts: 496
Joined: Tue Dec 27, 2005 12:43 am

Post by Matthias »

ThePhysicist wrote:
Matthias wrote: Wovon redest Du? Ich habe seit Monaten hier ein Linux laufen, und musste noch *nie* einen neuen Kernel kompilieren, höchstens mal ein paar Module (z. B. vom Grafiktreiber).
Ich hab seit Jahren ein Windows laufen und noch nie irgendwas davon kompiliert.
Und das lässt auf die Qualität des Kernel-Designs schließen? Mach dich nicht lächerlich. Darüber kann man als reiner Benutzer sowieso nichts aussagen, das können eigentlich nur Kernelentwickler.
ThePhysicist wrote:Ich versteh das ganze Kernel-Kompiliere bei Linux eh nicht.
Dann solltest Du auch nicht darüber reden.
ThePhysicist wrote: In den Kernel gehört meiner Meinung nach nix hardware-spezifisches. Dafür gibt es HAL und Treiber. Bei Linux muss man ja sogar wegen ner neuen Netzwerkkarte oder ner neuen Firewall den Kernel neu kompilieren.
Wo hast Du denn den Quatsch her? Wenn man die Treiber direkt in den Kernel einkompilieren möchte, muss man das, aber deswegen werden ja schon vor Jahren die Kernelmodule eingeführt, dank derer das nicht mehr nötig ist.
ThePhysicist wrote:Das ist ja fast so als müsste man am Vergaser seines Autos rumschrauben, weil man ein neues Radio eingebaut hat oder die Reifen gewechselt.
Computer sind keine Autos und Autovergleiche generell abzulehnen.
ThePhysicist wrote:
Matthias wrote: Davon abgesehen ist es klar, daß Linux-User den Kernel öfter neu kompilieren müssen, denn diese Möglichkeit haben Windows-Benutzer gar nicht.
Merkwürdige Logik: weil es bei Windows nicht geht, muss man es bei Linux machen?
Wie gesagt, man muss es unter Linux i. A. auch nicht. Daß es trotzdem manchmal unumgänglich ist liegt u. a. daran, daß jede Distri ihren eigenen Kernel verwendet in den dann noch 100 Sachen hineingepatcht wurden, außerdem werden unterschiedliche Compiler verwandt usw. usf. Da es nur eine Windows-"Distribution" gibt, hat man solche Probleme dort nicht; wenn der Kernel eine benötigte Funktion nicht hat, hat man eben Pech gehabt, unter Linux ist das dann kein Problem. Und wie gesagt kann man die meisten Treiber usw. auch als Kernelmodule kompilieren.
ThePhysicist wrote:Bei Windows braucht man das einfach nicht zu machen und trotzdem läuft alles ordentlich und schnell. Man muss höchstens mal schnell nen Treiber installieren.
...Also auch eine Art Kernelmodul laden :o)
ThePhysicist wrote:Ich will keineswegs behaupten Windows sei perfekt oder Linux sei schlecht, aber was das Kernel-Design angeht ist Windows IMHO besser.
Wie gesagt, das kann man als nicht-Kernelhacker nicht beurteilen, da man als Benutzer ja nur wenig vom Kernel mitbekommt.
Post Reply

Who is online

Users browsing this forum: DotBot [Crawler] and 14 guests