[Meltdown]

Zitat (Connect2004: 25.08.2004, 21:52)

einen Hardware-Umschalter zu verwenden, weil dann der 32-Bit-Krempel zum alten Eisen gehört und 64-Bit sich entgültig überall durchgesetzt hat. Bei der Umstellung von 16 auf 32-Bit kam die endgültige Einstellung des vollen 16-Bit-Supports mit Windows XP auf Softwareebene und dem Athlon64 auf Hardwareebene. Zumindest ist es mir auf dem Athlon 64 nicht gelungen, ein DOS 6.2 mit Windows 3.11 von einer CD zu booten, wobei für den I/O eine RAM-DISK verwendet wird. Die Meldung(vom BIOS): Code not supported

Alter 32-Bit Krempel.... Wie Du das so sagst.

Vielleicht haben wir beide auch nur das Problem das wir in Gedanken schon 5-6 Jahre weiter sind als es die Hersteller geschafft haben. Das kommt davon wenn Intel & AMD
zuviele Ankündigungen & "Tech-Previews" machen....

Ich hab (noch!) keinen 64-Bit Hauptprozessor. Das kommt noch. Gut möglich, das es auch noch dieses Jahr sein wird. Allein schon um meinen Athlon-XP Rechner so langsam
aufs Alteisen zu schieben. Sonst geht es ja nie voran.

Die Frage nach der 16-Bit Kompatibilität wollte ich schon längere Zeit mal stellen. 16-Bit läuft also nicht mehr im vollen Ausmaß ? Wo hat der Chip da eigentlich seine Grenzen ?
Und was läuft überhaupt noch bzw. kann noch laufen ?

Bei DOS 6.2 kann das auch an dem Real-Mode Kernel liegen. Gut möglich das da nur kleinere Änderungen nötig wären - und es würde wieder laufen.

Aber wissen tue ich es nicht. Wir reden ja nur von 32 & 64 - Bit im Zusammenhang mit dem ATHLON 64. Das 16-Bit Zeitalter interessiert halt keinen mehr.

Nur: es muß ja im Großen und Ganzen eigentlich noch laufen! Sonst würde Win95/98/ME ja sofort die Segel streichen. Das ist der reinste 16/32-Bit Brei.

[Rika]

@Meltdown: Ist nach 'nem Buffer Overflow eine überschriebene Rücksprungadresse auf dem Stack etwa Code? Sicherlich nicht. Der Buffer Overflow tritt ja gerade auf weil die Adresse überschrieben werden kann. NX verhindetr nur daß ein Rücksprung mit dieser Adresse ausgeführt wird, wenn sie in einen als Daten deklarierten Speicherbereich zeigt - Code vom Originalprogramm betrifft das jedoch definitiv nicht.

[Meltdown]

Du hast gewonnen.

Das klang jetzt einleuchtend. Ich hoffe nur das es zumindest ein wenig hilft, die Virenepidemie ein wenig einzudämmen.

Nicht das die Geschichte ein Papiertiger bleibt.

[Rika]

Viren: nein
Würmer: vielleicht
DoS durch Buffer Overflows: wird durch faule Programmierer nur noch schlimmer werden

[Imperator]

Rika es musste doch eine Möglichkeite geben, dass man den Befehl formatieren deaktiviert?

[Rika]

Ähm... das war nur beispielhaft. Es geht um solche Funktionen die über sehr übliche DLLs vom Host-Programm importiert werden und in denen Funktionen vorkommen, die ohne Parameterübergabe (direkter __stdcall(IN void, OUT void) funktionieren. Eine Format-Funktion selber wäre vergleichsweise ungefährlich, weil ihr der Parameter "C" nicht übergeben werden kann - wenn die Funktion aber ohne Parameter standardmäßig "A" annimmt und 'ne Diskette liegt drin... du siehst wo das Problem liegt?

[Imperator]

Ja sehe es.