Nachrichten

1

OS-Design / Theorie: Mögliche Benutzerreaktion auf Dateisystem-Idee

« am: 03. January 2006, 14:48 »

Ich hab mir das 3-Bereiche Konzept mal intern vorgestellt.

Linux nutzt ja die Partitionen sehr aus, während Windows sich auf einer Partition begnügt. - Was wäre für diese 3 Bereiche Sinnvoll?
Partitionen? Wären zu starr. Woher soll ein Benutzer wissen wie viel von seinen 500GB er wie nutzt?
LVM? Ich denke das wäre wie die Geschichte mit den Kanonen und Spatzen - zumindest für die Anfangsphase. Unterstützung wünschen tät ich mir schon.

Zu der bisherigen Idee:

1 Partition. Die Partition trennt sich in Blöcke auf: 1 Block = 1 MB.

Code: [Auswählen]

+---+---+---+---+---+---+---+---+---+---+---+---+
| 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10| 11| 12|
|   |   |   |   |   |   |   |   |   |   |   |   |
|   |   | P |   | P | P | P |   |   |   |   |   |
| S | S |   | S |   |   |   |   |   |   |   |   |
|   |   |   |   |   |   |   | u | u | U | U | U |
+---+---+---+---+---+---+---+---+---+---+---+---+
S = System
P = Programme, ...
U = Benutzerdaten belegt
u = Benutzerdaten frei / generell frei
Die Blöcke sind vom Geburt an alles u Blöcke, also für den Benutzer verfügbar und frei.
Das System installiert sich in Block 1 (am Anfang der Partition | Bootsektor) und folgende (im Beispiel 1 und 2)
Dann installier der Benutzer ein Programm. Ein P Block wird belegt. Weiterhin folgt ein Trieiberupdate / Systemupdate - Wieder ein S belegt und dann kommt noch Software hinzu (3 Ps) und der Benutzer kopiert seine Dateien drauf (insgesamt 3 Us, am Ende anliegend).

Das Prinzip ist folgendes: Ich würde es mit Paging vergleichen wollen (ich hoffe ich vergleiche das richtig). Würde man es ähnlich dem NTFS lösen, würde man einen riesigen Leerbereich erhalten, aufgrund der Blockgrösse. Ich würde es mappen: 3 Bereiche: Gehen wir von P aus:
Megabyte 0 fängt bei 3 oben in der Tabelle an. Megabyte 1 fängt bei 5 an.
Die Listen würden also so aussehen:

Code: [Auswählen]

P              Sektor
0x00000000 -     6144
0x00100000 -    10240
0x00200000 -    12288
0x00300000 -    14336
Vielleicht wäre es auch Sinnvoll, aneinanderliegende Blocke nicht in der Liste aufzuführen, also anzugeben, wie viele aufeinanderfolgende es sind.

Ich hoffe da sind keine Rechenfehler bzw. Denkfehler enthalten.

THX for feedback

Silver

2

OS-Design / Theorie: Mögliche Benutzerreaktion auf Dateisystem-Idee

« am: 03. January 2006, 13:55 »

IMHO muss jedes User Programme auf alle User Dateien zugreifen dürfen. (Wenn das nicht so wäre, würde ja nichtmal das kopieren einer Datei funktionieren.)

Klar worauf du hinaus willst. Was nützt ein Office wenn man nix speichern kann. Sobald auf die Eigenen Dateien zugegriffen werden soll wird der Benutzer einmal gewarnt und kann dann sagen "Ja, Nein, Einstellung für Programm speichern" und gut ist. Später kann er z.B: in der Systemverwaltung das ganze ändern. Mir ging es explizit um uninstallierte Programme. Wenn das Programm nicht installiert ist, darf es das nicht. Ausnahmen sollte es da nicht geben. Dies wäre nur wieder ein mögliches Sicherheitsproblem.

Auf die Systemdateien müssen normale User eh nicht zugreifen und daher kann man diesen Zugriff verbieten. Ausserdem sollten die User soviel wie möglich an ihrem eigenen Konto ändern können, ohne ein admin/root Account zu besitzen.

Systemdateien wird es, bis auf Einstellungsdateien, ja nicht geben. Nur halt den Systembereich. Und der ist und bleibt ja gesperrt (Einziger zugriff hat das System selbst (nur lesend, ausser Updates, Treiberintall, ...)) - Natürlich kann ein User sein Profil einstellen wie er es möchte. Dazu unten mehr.

Das Installieren der Programme ist eine gute Idee, das System könnte eine Liste aller installierten Programme führen, quasi ein Packetmanagement das fest im System verankert ist.

So wars gedacht

Programme die keinen Schaden anrichten können, können ja weniger Rechte kriegen, aber dafür auch von jedem User ohne zustimmung des Admins installiert werden. Die Autostart Programme können auch weniger Rechte kriegen.

Meine Idee dazu: Installationspackete enthalten Informationen wie z.B. Betzwerkbenutzung auf Port XY, ... Zugriff auf Eigene Dateien nötig, ..... Bla. Während der Installation sieht der Benutzer und das System das und die Rechte können schon während der Installation direkt geändert werden, ohne lästig in der Systemverwaltung alles selbst zu machen. z.B. kann je nach bedarf für ein Spiel der Netzwerkport geöffnet werden. Das System erledigt das ganze. Der Benutzer muss lediglich bei der Installation sagen "Ja, Nein, für Immer merken" und gut ist. Der Port bleibt dann immer zu, solange bis das Programm diesen anfordert. - Der Systeminterne Packetfilter wäre geboren. Das nur als kleine Idee. Was sich aus diesem bereich so rausholen lässt wäre zu diskutieren.

Programme aus dem Netzwerk oder von Wechseldatenträgern würden sich ja auch leicht installieren lassen.

Das ist mein Gedanke. Wenn jemand ein programm nutzen will, soll er es installieren. Wozu aus dem netz starten? OK - für Domänennetzwerke würde es da sicher einen Mechanismus geben (Server hält Programm bereit für Netzwerkstart oder automatische Installation). Aber nehmen wir mal an man kommt zu einer LAN Party oder sowas. "OH, Cooles Spiel - Gib ma". Und da geht das Kopierschutzgemalme wieder los. - Wenn es aber erst am System installiert werden muss, kann während der Installation die Gültigkeit, etc.... geprüft werden. Alterseinstufung vom System gecheckt werden, Bla... Meiner Meinung nach ist der Bedienungskomfort einer der Aspekte, der am wenigsten Minuspunkte bei diesem Konzept einfährt. Auf die Wage legen mit Systemsicherheit, Kommerz-Sicherheit, ... finde ich ist das schon zu akzeptieren. Vielleicht bei Gigabyte-Programmen könnte es etwas nervend sein... Aber die Idee ist ja noch nicht zuende gedacht.

Ich wollte noch kurz zur Benutzerhirarchie was sagen.

Es soll nicht EINEN Root geben, sondern die Möglichkeit Rechte zu vererben.
Ich sehe gerne auf eine 4-köpfige Familie zurück.
Vatter installiert das System. Er erstellt das Konto "Dad" und gibt sich maximale Rechte (natürlich hat er dann nicht so viele wie Root, aus Sicherheit sollten einige trotzdem das Root-Passwort erfordern). Das Mann im Haus darf also den Rechner verwalten. Die Mutter möchte auch einiges am Rechner machen - Bekommt also auch viele Rechte.
Die Zwei Kinder: Der Junge 10, die Tochter 17 jahre alt. Die Eltern richten die Profile ein, in denen steht wann sie geboren sind. Erstmal wird den Kindern verboten, Private einstellungen zu ändern (wie Geburtsdatum). Wenn nun der Sohn eine Horror-Metzel-DVD einlegt, sagt ihm das System freundlich "NEIN" oder wenn er versucht ein Programm zu installieren - "NÖ". Für die Tochter fehlt beispielsweise nur das Recht, Software zu installieren. Spiele sind OK, aber keine Programme (nur als Beispiel). DIe Tochter installiert das Spiel ab 16, der Sohn kann es aber wieder nicht starten. - Der Sohn hat jetz aber ein Spiel für 8 Jahre. WIll es installieren - Der Vater hat die zweite Möglichkeit gewählt: Der Sohn darf am System anfragen, ob die Software installiert werden darf. - Das Packet wird von der CD auf die Festplatte kopiert, aber es darf solange nicht ausgeführt werden, bis ein autorisierter Benutzer das Erlaubt hat  (z.B: Mutter). Die letzte Methode würde sich im Unternehmen auch als sehr praktisch erweisen. Mitarbeiter 044 möchte ein Packprogramm installieren. Der Computer sagt "Möchten Sie beim Admin anfragen?" - Der Benutzer gibt einen Kommentar ein und sagt "Ja". Programm wird kopiert und bleibt gesperrt - Eine Nachricht wird zu einem autorisierten in der EDV Abteilung geschickt. Er liest sich die Anfrage durch und braucht nur auf "Ja oder Nein" zu klicken. Der Benutzer wird über die Entscheidung benachrichtigt und bei NEIN fliegt das Programm automatisch wieder runter. Genau so mit Internetrechten, etc - Aber das hat jetzt weniger mit Festplattenrechten / Extene Median Rechten zu tun.

Das heisst, jeder Benutzer kann Rechte verschrieben bekommen von darüberliegenden Ebenen. Auf diese Rechte verzichten kann er natürlich selber, indem er sie sich wieder wegnimmt. - Einige Rechte sind altersbedingt einstellbar (wie im beispiel bei Familien - wenn gewünscht) oder weitere Möglichkeiten.

Das System soll von den Rechten her relativ einfach gestaltet werden. Nicht zu viele Einstellmöglichkeiten (generell vom System nicht allzu viele und z.B. diese Ausblenden, die ein Benutzer eh nicht hat (oder zumindest die Steuerelemente deaktivieren)) - Das wahrt die Übersicht und Bedianbarkeit. Aber zu wenig natürlich auch nicht. Ziel soll es sein, möglichst viel selber entscheiden zu können aber nicht zu unübersichtlich zu werden. Es muss nicht jedes Details sperrbar sein (wozu den Bildschirmschoner sperren oder verhindern, dass der Benutzer die Farben ändern kann?) Was es an Einstellungen gäbe würde sich während der konkreten Systemplanung zeigen.

Natürlich sind im System auch Benutzergruppen anlegbar.

Detailierte Lösung bzw. Entwicklungswege sind dabei noch nicht mit reingedacht

Silver

3

OS-Design / Theorie: Mögliche Benutzerreaktion auf Dateisystem-Idee

« am: 03. January 2006, 12:42 »

Aber was ist mit den Userdateien? Dann müsste man dem Programm ja auch verbieten, auf die Eigenen Dateien zuzugreifen (Der Sicherheit wegen).
Da jedes Programm nur auf seine eigens erstellten Dateien im Anwendungsordner (siehe weiter unten) zugreifen darf, wäre das ja nicht das Thema.

Add zum User-Bereich wie ich es mir gedacht hatte (Anwendungsdaten);

Code: [Auswählen]


\
\Username 1\
\Username 1\....
\Username 1\Eigene Dateien\
\Username 1\Eigene Dateien\....
\Username 1\Eigene Dateien\Eigene Bilder\
\Username 1\Eigene Dateien\Eigene Bilder\.....
\Username 1\Anwendungsdaten\
\Username 1\Anwendungsdaten\Officeprogramm\
\Username 1\Anwendungsdaten\Officeprogramm\.....
\Username 1\Anwendungsdaten\Malprogramm\
\Username 1\Anwendungsdaten\Malprogramm\.......
\........
und so weiter

Der Admin (bzw. andere Berechtigte) sollten natürlich ind er Lage sein per COmputer / per User bestimmen zu können, ob nicht installierte Programme ausgeführt werden dürfen, ob sie Dateien anlegen dürfen, etc.

Weitere Ideen?

THX

4

OS-Design / Theorie: Mögliche Benutzerreaktion auf Dateisystem-Idee

« am: 02. January 2006, 23:27 »

Ich finde es hängt zusammen. Wenn das Dateisystemkonzept (ich nenne es singemäß lieber Festspeicher-Management-System) es verbietet "Dateien" auszuführen, sondern es nur erlaubt durch Pachet-Dateien auf dem Rechner installierte Softwarepackete zu starten... Wie löse ich dann einen CD Autostart, oder Software über Netz bzw. USB Stick. Da spielt doch ein FMS (Festspeicher-Management-System) eine wichtige Rolle.

Naja, wie man es auch sehen mag - ich geh schlafen und dann mir den Kopf weiter zerbrechen wie man das ganze lösen kann.

THX for Posts

Silver

5

OS-Design / Theorie: Mögliche Benutzerreaktion auf Dateisystem-Idee

« am: 02. January 2006, 14:08 »

Ala HTA

6

OS-Design / Theorie: Mögliche Benutzerreaktion auf Dateisystem-Idee

« am: 02. January 2006, 09:08 »

Wie es mit der Netzwerktechnik aussehen soll in dem Bereich weiss ich noch nicht. Wenn es etwas "Domänen" ähnliches gäbe wären Anwendungen ausm Netzwerk sicher nicht das Problem. "Arbeitsgruppennetzwerke" wären wieder eine Sicherheits-Frage. Wer weiss was da drin is. Und ausserdem wäre eine Installation da auch nicht so aufwändig.
Anwendungen vom USB Stick... OK, optische Medien kommen auch dazu... Muss ich mir mal durch den Kopf gehen lassen. Zum CD Autostart hatte ich mir gedacht, HTML zu verwenden.
Jemand ideen? Muss mir mal den Kopf zerbrechen.

Silver

7

OS-Design / Theorie: Mögliche Benutzerreaktion auf Dateisystem-Idee

« am: 30. December 2005, 18:29 »

Das mit dem "registrieren" meine ich, dass das Betriebssystem nur Programme starten lässt die installiert worden sind.
Ausführbare Dateien wird es generell nicht geben. Für Installationen werden Archive speziellen Formates benutzt. Wie z.B: mit MSI Dateien unter Windows oder den RPMs unter einigen Linux'es.
Der Admin kann natürlich einzelnen Benutzern mehr Rechte geben. z.B. wenn man sich eine Familie vorstellt, dürfen Mutter und Vater Sachen installieren. Die Kinder dürfen nichts installieren und nur Programme ausführen, die ihrem Alter entsprechen (FSK USK Prüfung anhand des Geburtsdatums, wo die Eltern den Kindern das Recht enziehen können, persönliche Informationen zu ändern).

Ein Rechte / Erlaubnisystem füs Betriebssystem sollte es schon geben, nut halt vereinfacht für Dateien.

Mit den selbstentwickelten Programmen dachte ich es mir so, wie es schon erwähnt wurde: Die Entwicklungsumgebung kann das Programm selbstständig Installieren, allerdings ist es nur für den Benutzer startbar und wenn es im Debugmodus läuft, weiter eingeschränkt, damit nix kaputt gehen kann.

Zur Installation berechtigte Benutzer können auswählen, für wen welches Programm ausführbar sein soll, Features, etc........; solange sie im Release Status sind. Debug-Programme werden als "In Entwicklung" angesehen und werden zusätzlich eingeschränkt, falls es Fehlfunktionen gibt.

Natürlich sind Details noch zu überdenken.

Frohe Weihnachten und guten Rutsch wünsch ich euch ausm Urlaub.

Silver

8

OS-Design / Theorie: Mögliche Benutzerreaktion auf Dateisystem-Idee

« am: 23. December 2005, 13:06 »

Oder wie wäre es mit Patches? Man entwickelt ein Programm neu, compiliert zum Packet, installiert, testet, erstellt weiter, compiliert, erstellt n Patch vom Original zum NeuPacket (automatisiert vielleicht (Script, etc)) und patcht dann die Anwendung. Wäre auch ne ersparnis (vielleicht alles direkt automatisieren, wenn das OS erkennt dass das Programm Debugbar ist, oder sowas.....
*aufschreib*

Muss ma Ideen sammeln und vergleichen

9

OS-Design / Theorie: Mögliche Benutzerreaktion auf Dateisystem-Idee

« am: 23. December 2005, 13:03 »

Das ist mir auch im Kopf. Ich überlege schon krampfhaft eine Lösung ohne das Konzept komplett überarbeiten zu müssen. Vielleicht nen Modus den der Root anschalten kann wo es auch erlaubt ist, WindowsEXE oder Linux* zu starten... Was weiss ich. Muss ma drüber nachdenken.

10

OS-Design / Theorie: Mögliche Benutzerreaktion auf Dateisystem-Idee

« am: 23. December 2005, 12:35 »

Sehr unpraktisch, finde ich... Das garantiert zwar fast 100%ige Sicherheit vor Viren, allerdings wird so auch niemand für dein System entwickeln, vorallem keine Hobby-Coder oder so. Und du musst ständig dein OS updaten. Oder zumindest die Tabelle, in der alle registrierten Programme stehen. Das bremst die Entwicklung/Benutzung eines OS enorm. Sollte es aber trotzdem "groß" werden, so wird man schnell Hacks finden, die die Tabelle entsprechend manipulieren um neue Programme installieren zu können.

Wo genau siehst du die Propleme beim Entwickeln?

11

OS-Design / Theorie: Mögliche Benutzerreaktion auf Dateisystem-Idee

« am: 23. December 2005, 10:38 »

Eigentlich wollte ich jetz mit so nem Kommentar werfen wie "Hast du alles gelesen?" Aber da ist mit eingefallen, dass ich diese Informationen nicht geschrieben hatte.... Sollte eigentlich der zweite Post werden, aber ich hatte mich aus irgend einem vergessenen Grund dafür entschieden, es nicht zu schreiben. Also dacht ich ich hätts geschrieben aber ... ^^:

Ich nenne das Dateisystem nicht Dateisystem, sondern Festplatten-Management-System. Das Dateisystem ist einer von 3 Bereichen (Der einzige direkt sichtbare).
Das Betriebssystem ist ein Teil (Modulare erweiterung (Treiber, etc), und die Programme ("Programm-Packete") bilden den zweiten. Der Zweck ist, dass diese nicht sichtbar sind und nicht zum "Dateisystem gehören". Programm-packete werden durch einen vom System bereitgestellten Installer hinzugefügt.
Das Nachteil ist klar: jedes noch so kleine Programm (auch selbstgeschrieben) muss beim Betriebssystem registriert werden. Der Vorteil wenn nur registrierte Programme ausgeführt werden können: Maximale Sicherheit und leichtes Management (u.A. Rechteverwaltung durch Root).

Sry, dass ich vergessen habe das zu cshreiben. Ich denke über das Konzept so viel nach, und ich bin von Natur aus so zerstreut... Lassen wir das ^^

So, jetz nochmal deine Meinung taljeth (und die anderen)

THX

Silver

12

OS-Design / Theorie: Mögliche Benutzerreaktion auf Dateisystem-Idee

« am: 23. December 2005, 00:00 »

Ich glaube, wie das ganze intern verwaltet wird, ist relativ egal. Das entscheidene in dieser Frage ist eher, wie das Dateisystem dem Benutzer präsentiert wird. Windows macht es ja vor: Der Desktop liegt zwar in irgendeinem Unterverzeichnis herum, wird aber von den Benutzern trotzdem als oberste Ebene angesehen, weil er eben so präsentiert wird.

Wie der Verzeichnisbaum jetzt aber konkret aussehen muß, kann man sich sicher beliebig lang streiten.

Da hast du irgendwie recht. Wenn ich meine Idee / Konzept so realisieren würde, würden sich die Benutzer langsam daran anpassen, solange es wirklich nicht nach Verschwörung, etc, aussieht.

13

OS-Design / Theorie: Mögliche Benutzerreaktion auf Dateisystem-Idee

« am: 22. December 2005, 19:44 »

@Legend:

Code: [Auswählen]


ROOT Ansicht:
/Benutzer A
- /Eigene Dateien
- /Programmdaten (Vielleicht versteckt & nur über Netzwerk als Root einsehbar)
/Benutzer B
- /Eigene Dateien
- /Programmdaten (Vielleicht versteckt & nur über Netzwerk als Root einsehbar)
/Öffentlich
- /Eigene Dateien
- /Programmdaten (Vielleicht versteckt & nur über Netzwerk als Root einsehbar)
/Netzwerkumgebung
/DVD-Laufwerk
/DVD-Brenner
/USB-Stick

Benutzeransicht "Benutzer A":
/Eigene Dateien
/Programmdaten (Vielleicht versteckt & nur über Netzwerk als Root einsehbar)
/Öffentlich
- /Eigene Dateien
- /Programmdaten (Vielleicht versteckt & nur über Netzwerk als Root einsehbar)
/Netzwerkumgebung
/DVD-Laufwerk
/DVD-Brenner
/USB-Stick

Natürlich alles als Tree ansicht.
So sollte das nicht verwirren. Der Admin / Root bekommt keine Eigenen Dateien um zu verhindern, dass er als normaler Account genutzt wird. Auch der Admin sollte sich einen normalen Benutzer anschaffen.


@nooooooooos:
So wie oben dargestellt ist es schnell zugänglich, effizient und der Benutzer kann seine Dateien und Verzeichnisse unterhalb von "Eigene Dateien" selber verwalten wie er möchte.


@T0ast3r:
Wie gesagt, wie das intern aussehen soll bin ich mir noch ganz und gar nicht sicher. Ich überlege schon seit Tagen rum wie sich die Daten am effizientesten legen lassen, und zwar so, dass sie von mir (oder sonstigen OS Entwicklern) unkompliziert genutzt werden können (also die Nutzung leicht und effizient programmieren lässt).
Nur dass der Benutzer halt im Dateisystem nichts vom System und den Programmen wiederfindet. Dazu wird es in der Konfiguration "ala Systemsteuerung" Einträge geben, Programme zu entfernen, Systemeinstellungen zu verändern (die sowieso in /Benutzername/Programmdaten/System bzw im AllUsers / Öffentlich Ordner (oder ähnlich) liegen.

14

OS-Design / Theorie: Mögliche Benutzerreaktion auf Dateisystem-Idee

« am: 22. December 2005, 13:45 »

THX für die Antwort.

Ziel ist es, dem Benutzer eine einfache Struktur vorzulegen. Diese einfache Struktur soll natürlich weniger Angriffsfläche als ein aufwändiges Dateisystem bieten, da ja nur die Benutzerdateien "öffentlich" liegen und durch ein sehr simples Rechtesystem geschützt werden (das ist in meinem Plan noch nicht ausgereift - ich mache mir z.Zt. eher sorgen zu meinem Jetzigen "Ideen-Stand" die interne umsetzung zu machen.

Nur mit den vielen Einstellungen bin ich auf dem Kriegspfad (Muss der Benutzer denn wirklich jedes Detail einstellen dürfen / können?). Was würdest du denn an "vielen Einstellungen" vermissen?

Silver

15

OS-Design / Theorie: Mögliche Benutzerreaktion auf Dateisystem-Idee

« am: 22. December 2005, 09:20 »

Hi.

Ich hatte in den letzten Tage ein paar Gedanken zum Thema "Benutzer - DAU - Profi - ..." im Zusammenhang mit Datenzugriff.

Ich möchte von einigen anderen Personen die Ahnung von dem Gebiet OS Entwicklung haben mal wissen, wo die Grenzen für Verständnis stecken, ihrer Meinung nach.

Beispielsweise: Das Dateisystem erlaubt NIEMANDEN in OS-Daten, Programmdaten, treiber einzusehen. Der einzig sichtbare Teil des Dateisystems wären halt die Benutzerdateien. Der Rest wird geschützt vom System verwaltet und ist und bleibt nicht einsehbar.

-> Wie das ganze zu realisieren wäre lasse ich mal aussen vor, es geht mir rein um die Theorie, wie der Benutzer sich verhalten KÖNNTE. <-

Ich sperre den Benutzer sozusagen in die eigenen Dateien ein. Höher berechtigte Benutzer "root, Admin, whatever...", können natürlich in alle Dateien der Benutzer einsehen.

Ich denke mal das erklärt meinen Gedanken.
Ich wäre mir aber nicht sicher wie der Benutzer bei so einem Konzept reagiert? Kein Vertrauen, weil er nicht alles sieht? (Verschwörungstheorie ^^) --- Zufriedenheit - da es sehr einfach und übersichtlich zu bedienen wäre...

Für Meinungen / Kritik wäre ich Dankbar.

Silver

16

Lowlevel-Coding / 64 Bit

« am: 20. December 2005, 10:27 »

@n3Ro: Die AMD Referenzen sind echt Klasse. Ich hab es noch nie so gut erklärt gelesen. Echt empfehlenswert (musste das mal loswerden ^^)

17

Lowlevel-Coding / 64 Bit

« am: 20. December 2005, 08:37 »

Danke für das Material - Ich werde mich bei nächster Gelegenheit einlesen.

Das ganze ist ziemlich AMD basierend - soweit ich weiss haben die ja den 64bit Anfang gemacht - aber die Prozessoren haben ja auch unterschiede (z.B: Speichercontroller). Sind diese relevant / was muss ich beachten?

Ich werd mich mal in den Dschungel der Intel-Homepage durchwühlen und schaun ob ich da vielleicht doch Material finde... Ich meine ich wäre per Zufall mal worauf gestoßen....

Für weiteres Material (ihr müsst jetz net krampfhaft anfangen zu Suchen) wäre ich trotzdem Dankbar - mann kann nie genug haben

THX SO MUCH

Silver

18

Lowlevel-Coding / 64 Bit

« am: 19. December 2005, 18:20 »

EDIT: Vielleicht könnte man in der neuen Ausgabe was dazu schreiben... Wenn noch Zeit und Platz is... Wär klasse!

Wenn du was schreibst oder jemanden findest, der was schreibt, wieso nicht.

So absurd finde ich die Idee gar nicht... Ich habe zwar kaum Erfahrung in dem Bereich... Aber mit (viel) Zeit, Geduld, Hilfe und einigen Korrekturlesern ()werd ich das vielleicht packen. Aber ich lasse das mal so im Raum gestellt, also als idee

Naja mit abwaertskompatibel hab ich schon gemeint, dass auch noch die Workarounds da sind

Ich weiss Auf der einen Seite hasse ich die abwärtskompatiblität... Bringt viele Probleme mit sich, wie man ja sieht... Aber ohne wäre das "Userleben" um vieles schwerer.

Bei dem Thema ging es mir eigentlich darum dass wenn ich mich in sowas einlese, möglichst auf den ganzen "Garbage" der nicht mehr benötigt wird zu verzichten.

19

Lowlevel-Coding / 64 Bit

« am: 19. December 2005, 17:34 »

Ich hoffte eigentlich Sachen zu hören wie "A20 nicht mehr nötig". Was ich mich da durchgelesen habe und so viele "WorkArounds" gelesen habe die die in den 80ern und 90ern verzapft haben... Nee nee
Kann mir jemand nen Link o.Ä. für 64bit Referenz (z.B: von Intel oder AMD) geben (sorry dass ich frag, weiss in Foren ist das net gemocht (google lieber), aber ich HASSE die Seiten der Hersteller weil ich da teilweise absolut net durchblick).

EDIT: Vielleicht könnte man in der neuen Ausgabe was dazu schreiben... Wenn noch Zeit und Platz is... Wär klasse!

THX SOO MUCH

Silver

20

Lowlevel-Coding / 64 Bit

« am: 19. December 2005, 13:42 »

Hi.

Wie sieht in der LowLevel Programmierung der Unterschied zwischen 32-Bit und 64-Bit CPU bzw Betriebssystem aus? Ich meine damit nicht die Architektur des CPU sondern z.B: Speicherverwaltung, A20, ... ?
Speziell dazu habe ich leider noch nix gefunden.

Silver