Lowlevel
Lowlevel => Lowlevel-Coding => Thema gestartet von: rizor am 02. April 2011, 19:12
-
Hallo zusammen,
ich habe momentan ein Problem mit meinen BIOS-Interrupts.
Mein System soll den Speicher selbst bestimmen durch 0xe820.
Habe mir dazu Code geschrieben, der in den unreal-mode springt und wieder in den PM springt.
Den Code habe ich gegen Adresse 0x7000 gelinkt und lade ihn auch an die Stelle.
In meinem Kernel rufe ich folgenden Assembler-Befehl:
call *0x7000
Leider laedt er nicht 0x7000 in EIP sondern den Inhalt von 0x7000.
Wenn ich es mit
call (0x7000)
probiere, kommt nichts sinnvolles bei raus. Das was dann in EIP steht, kann ich in meinem Code nicht finden.
Wie sieht er richtige Befehl aus?
Danke.
Grusz
rizor
-
Wie wär's mit
call 0x7000
?
-
Das geht auch nicht. Da versucht er auch auf komische Adressen zuzugreifen.
Keine Ahnung, woher er die Werte bekommt.
-
Wäre es nicht möglich
mov eip, 7000h
zu benutzen?
-
Das laesst GAS nicht zu. Da sagt er mir, dass EIP das falsche Register ist.
-
EIP kann man weder lesen noch schreiben. Darum geht keine IP-relative Adressierung. Es lässt sich nur über CALL und JMP verändern.
-
EIP kann man weder lesen noch schreiben. Darum geht keine IP-relative Adressierung. Es lässt sich nur über CALL und JMP verändern.
Wir können auch eine Adresse auf den Stack schieben und dann ein Rücksprung machen.
Dirk
-
Wenn "call *0x7000" den Inhalt von 0x7000 nach EIP lädt und nicht 0x7000, dann müsste
var db 0x7000
call var
doch 0x7000 nach EIP laden.
Das ist doch das Ziel!
Sfan
-
Normalerweise macht man das so:
mov $0x7000, %eax
call *%eax
oder lädt gleich das Segment dazu:
lcall $0x08,$0x7000
-
Normalerweise macht man das so:
mov $0x7000, %eax
call *%eax
Das geht natürlich auch!
Meine Methode sollte aber möglichst nichts an den Regtistern ändern.
Sfan
-
also laut AMD-Manuals gibt es keinen
call immfür absolute adressen
es bleiben dir also nur die drei möglichkeit: far call, eax oder var
-
Meine Methode sollte aber möglichst nichts an den Regtistern ändern.
Programme, die nichts an den Registern ändern, müssen ziemlich langweilig sein.
-
Okay, jetzt wird der Code ausgefuehrt, macht aber ein paar Zicken, sobald ich in den RM springe.
Hier ist mal der Code:
.code16gcc
int_e820:
xor %ebx, %ebx
xor %bp, %bp
mov $0x8004, %eax
mov %eax, %edi
mov $0x0534D4150, %edx
mov $0xe820, %eax
mov $24, %ecx
int $0x15
jc exit
cmp %eax, %edx
jnz exit
cmp %ebx, 0x0
jz exit
jmp check
loop:
mov $0x1, %eax
mov %eax, 0x14(%edi)
mov $24, %ecx
int $0x15
jc exit
mov $0x0534D4150, %edx
check:
jcxz bad_entry
cmp %cl, 20
jbe check_length
mov 20(%edi), %ecx
test $0x1, %ecx
je bad_entry
check_length:
mov 0xc(%edi), %ecx
or 0x8(%edi), %ecx
jz bad_entry
inc %bp
add 24, %edi
bad_entry:
test %ebx, %ebx
jne loop
exit:
mov %bp, (0x8000)
clc
mov %cr0, %eax
or 0x1, %eax
mov %eax, %cr0
push $0x8
push $goback
retf
In den RM springe ich, indem ich einfach das PM-Bit loesche.
Sollte doch funktionieren, oder?
-
So einfach ist das nicht.
Wie das geht, steht hier: http://wiki.osdev.org/Real_mode#Switching_from_Protected_Mode_to_Real_Mode
-
Meine Methode sollte aber möglichst nichts an den Regtistern ändern.
Programme, die nichts an den Registern ändern, müssen ziemlich langweilig sein.
Nur das kleine Codestück sollte nichts an den Registern ändern
Sfan
-
Okay, jetzt wird der Code ausgefuehrt, macht aber ein paar Zicken, sobald ich in den RM springe.
Hier ist mal der Code:
....
Wird diesen 16 Bit-RM-Bios-Interrupt vom Virtual 8086 Mode aus aufgerufen, denn sonst zickt dieser Bios-Interrupt schon selber sogar noch bevor in den RM geschaltet wird herum?
Dirk
-
Die Frage verstehe ich nicht. Der Kernel soll in den Unrealmode springen und dort den Interrupt ausfuehren. Das muesste funktionieren.
-
Du willst die BIOS-Interrupts im Unrealmode ausführen? Geht das überhaupt zuverlässig, denn so ein BIOS-Code kann ja sonstwas tun?
-
Du willst die BIOS-Interrupts im Unrealmode ausführen? Geht das überhaupt zuverlässig, denn so ein BIOS-Code kann ja sonstwas tun?
Bios-Interrupts lassen sich entweder im RM, oder im V86-Mode, oder im 16 Bit-Unrealmode ausführen, aber nicht im PM.
Erst wenn erneut in den PM geschaltet wird und Segmente geladen werden mit anderen Einträgen bei der Segmentgrößße im dortigen GDT,
dann wird diese Segmentgröße in die Schattenregister geschrieben.
Mir ist kein Bios-Interrupt bekannt der selber in den PM schaltet und wieder zurückin den RM. (Mainboad mit EFI-Bios?)
Dirk
-
Hallo,
während meiner Schulzeit, also vor sehr vielen Jahren, hab ich und ein Kumpel mal versucht ein RM-Programm zu bauen das mit Hilfe von FS und GS mehr als 64 kB ansprechen sollte. Wir haben FS und GS auch anständig im PM initialisiert und sind korrekt in den RM zurückgesprungen. Das System lief auch ganz normal weiter aber irgendwann gab es dann eine GP-Exception wenn über FS oder GS mit einem Offset größer 64 kB zugegriffen wurde. Unsere Lösung war das wir einen passenden Excpetion-Handler in die RM-IDT eingetragen haben (für INT 0x0D) der einfach nur in den PM ging, FS und GS wieder passend initialisierte und dann zurück im RM ein IRET gemacht hat. Mit diesem Trick konnten wir die durchschnittliche Laufzeit unseres Programm deutlich steigern aber irgendwann krachte es trotzdem wegen irgendeiner unbehandelten Exception. Soweit ich mich noch erinnern kann hatten wir einfach Probleme im RM genau zu analysieren ob der INT nun wirklich eine Exception ist oder eben ein IRQ 5 (ein INT 0x0D wäre zwar auch möglich gewesen aber das hatten wir einfach mal ignoriert). Eigentlich sollte das kein Problem sein aber mit dem PIC kannten wir uns damals nicht so richtig aus. Einen Dissasembler der den Befehl auf den der IP auf dem Stack zeigt genau analysiert um zu erkennen ob das ein Speicherzugriff ist oder nicht erschien uns damals als zu aufwendig und einfach immer in den PM zu gehen kostete enorm viel Performance und löste das Problem trotzdem nicht vollständig. Zumindest nicht bei Programmen die die Soundkarte (welche ja IRQ 5 wollte) benutzt haben. Aber auch wenn es keinen IRQ 5 gab hielt unser Schmalspur-UnReal-Mode nicht ewig.
Es ist zwar durchaus möglich das wir das damals nicht ordentlich implementiert haben und es deswegen nicht stabil lief aber von einer ernsthaften/längeren Benutzung des UnReal-Mode kann ich persönlich trotzdem einfach nur abraten.
Grüße
Erik
-
Mir ist kein Bios-Interrupt bekannt der selber in den PM schaltet und wieder zurückin den RM. (Mainboad mit EFI-Bios?)
Da in keiner Spezifikation steht, dass das ausgeschlossen ist, würde ich mich nicht darauf verlassen. Prinzipiell darf jeder BIOS-Interrupt auch in den Protected Mode gehen.
Ich habe mal gelesen, dass einige Option-ROMs (SCSI-Controller, Grafikkarten) in ihren Handlern auch genau das tun. Guter BIOS-Code würde im Übrigen auch dann, wenn er in den PM schaltet, alles brav wieder zurücksetzen. Die ACPI-Problematik mit ihren Workarounds zeigt aber, dass realer BIOS-Code halt nicht gut ist(*).
Gruß,
Svenska
(*) Ich hab hier ein displayloses Acer-Notebook. Unter Linux wurde der Lüfter nicht angesteuert, d.h. war er beim Booten aus, ging das Gerät irgendwann wegen Überhitzung aus. Für "ACPI_OS=Linux" war im BIOS ein Workaround vorgesehen, der aber auch nicht funktioniert hat. Nach einem BIOS-Update geht es jetzt zuverlässig, obwohl mir der Kernel immernoch ein paar Warnungen entgegenwirft.
-
Hallo,
während meiner Schulzeit, also vor sehr vielen Jahren, hab ich und ein Kumpel mal versucht ein RM-Programm zu bauen das mit Hilfe von FS und GS mehr als 64 kB ansprechen sollte. Wir haben FS und GS auch anständig im PM initialisiert und sind korrekt in den RM zurückgesprungen. Das System lief auch ganz normal weiter aber irgendwann gab es dann eine GP-Exception wenn über FS oder GS mit einem Offset größer 64 kB zugegriffen wurde. Unsere Lösung war das wir einen passenden Excpetion-Handler in die RM-IDT eingetragen haben (für INT 0x0D) der einfach nur in den PM ging, FS und GS wieder passend initialisierte und dann zurück im RM ein IRET gemacht hat. Mit diesem Trick konnten wir die durchschnittliche Laufzeit unseres Programm deutlich steigern aber irgendwann krachte es trotzdem wegen irgendeiner unbehandelten Exception. Soweit ich mich noch erinnern kann hatten wir einfach Probleme im RM genau zu analysieren ob der INT nun wirklich eine Exception ist oder eben ein IRQ 5 (ein INT 0x0D wäre zwar auch möglich gewesen aber das hatten wir einfach mal ignoriert). Eigentlich sollte das kein Problem sein aber mit dem PIC kannten wir uns damals nicht so richtig aus. Einen Dissasembler der den Befehl auf den der IP auf dem Stack zeigt genau analysiert um zu erkennen ob das ein Speicherzugriff ist oder nicht erschien uns damals als zu aufwendig und einfach immer in den PM zu gehen kostete enorm viel Performance und löste das Problem trotzdem nicht vollständig. Zumindest nicht bei Programmen die die Soundkarte (welche ja IRQ 5 wollte) benutzt haben. Aber auch wenn es keinen IRQ 5 gab hielt unser Schmalspur-UnReal-Mode nicht ewig.
Es ist zwar durchaus möglich das wir das damals nicht ordentlich implementiert haben und es deswegen nicht stabil lief aber von einer ernsthaften/längeren Benutzung des UnReal-Mode kann ich persönlich trotzdem einfach nur abraten.
Grüße
Erik
Ich habe den 16 Bit UnReal-Mode schon auf mehreren x86-Rechnerplattforemen erfolgreich verwendet. Begonnen mit 80386er, 80468, mit Rechner für Sockel 5, 6, 7, Pentuim 3, 4 und jetzt Core2Quad und ich habe noch nie derartige Probleme damit feststellen können.
Ich erweiterte aber eigentlich nur DS, da man bei der Verwendung von FS, oder GS ja immer ein Segment-Prefix benutzen muss. Und so kann man auch weiterhin über DS auf das Datensegment unserer Anwendung wie gewohnt mit einem 16 Bit-Offset darauf zugreifen und nun zusätzlich mit einem 32 Bit-Offset auf den gesamten 4 GiB-Adressraum zugreifen.
Ich sehe keinen Grund auf den UnReal-Mode zu verzichten, auf unseren Rechnern lief er bisher genauso stabil und zuverlässig wie RM und PM.
Dirk
-
Mir ist kein Bios-Interrupt bekannt der selber in den PM schaltet und wieder zurückin den RM. (Mainboad mit EFI-Bios?)
Da in keiner Spezifikation steht, dass das ausgeschlossen ist, würde ich mich nicht darauf verlassen. Prinzipiell darf jeder BIOS-Interrupt auch in den Protected Mode gehen.
Das würde aber bedeuten das man mit solchen BIOS-Interrupt kein Memmorymanager wie emm386.exe mehr verwenden kann. Mir ist kein Rechner bekannt der nicht mehr auf diese Weise DOS-kompatibel ist.
Ich habe mal gelesen, dass einige Option-ROMs (SCSI-Controller, Grafikkarten) in ihren Handlern auch genau das tun.
Ich habe es nur gerüchteweise gehört, das es so etwas geben soll. Welche Karten davon nun genau betroffen sind konnnte ich jedoch noch nicht ermitteln.
Guter BIOS-Code würde im Übrigen auch dann, wenn er in den PM schaltet, alles brav wieder zurücksetzen.
Wenn emm386.exe bereits gestartet wurde, dann wird kein Bios-Interrupt selber mehr in den PM schalten können.
Ich denke aus diesem Grund werden solche Bios-Funktionen die selber in den PM schalten nicht oft anzutreffen sein und damit eine Ausnahme bleiben.
Dirk
-
Hallo,
Genau das sind Doppelposts, Dirk. ;-)
Prinzipiell darf jeder BIOS-Interrupt auch in den Protected Mode gehen.
Das würde aber bedeuten das man mit solchen BIOS-Interrupt kein Memmorymanager wie emm386.exe mehr verwenden kann. Mir ist kein Rechner bekannt der nicht mehr auf diese Weise DOS-kompatibel ist.
Bei geladenem EMM386 bist du im VM86, das lässt sich feststellen. Der Unrealmode lässt sich nicht feststellen, denn er ist mit dem RM identisch. BIOS und Treiber können also darauf Rücksicht nehmen.
Ich habe mal gelesen, dass einige Option-ROMs (SCSI-Controller, Grafikkarten) in ihren Handlern auch genau das tun.
Ich habe es nur gerüchteweise gehört, das es so etwas geben soll. Welche Karten davon nun genau betroffen sind konnnte ich jedoch noch nicht ermitteln.
Kurze Suche ergibt dieses (http://downloadmirror.intel.com/10177/eng/P43-0260_Release_Notes.txt):
#12881: Intel RAID cards not working on Westville 533 (BIOS B05 +).
This was due to the Intel RAID card going into protected mode and
not returning to big real mode. The fix is to go back into big real
mode immediatly after option ROMs have executed.
Auch PXE-Boot-ROMs müssen im Protected Mode arbeiten, um die Boot-Images im Speicher verwalten zu können und sie stellen meist auch einen Zugriff auf das Netzwerk "für später" bereit. Der TCP/IP-Stack dafür dürfte auch im erweiterten Speicher liegen...
Die Frage ist immer, ob die Funktionen korrekt zurückkehren (also auch in den Unrealmode) oder nicht.
Guter BIOS-Code würde im Übrigen auch dann, wenn er in den PM schaltet, alles brav wieder zurücksetzen.
Wenn emm386.exe bereits gestartet wurde, dann wird kein Bios-Interrupt selber mehr in den PM schalten können.
Aber er kann dies feststellen. Stellt der Interrupt fest, dass er im VM86 aufgerufen wurde, dann wird eine RM-kompatible Routine aufgerufen, andernfalls eine effizientere Routine, die über den PM geht.
Ich denke aus diesem Grund werden solche Bios-Funktionen die selber in den PM schalten nicht oft anzutreffen sein und damit eine Ausnahme bleiben.
Naja, RM ist nur 16-bittig. Die große Masse der BIOS-Funktionen wird damit auskommen - nach dem Boot sind BIOS-Interrupts ohnehin fast nutzlos - aber wenn es um hohe Geschwindigkeit geht... wie gesagt, ich würde mich nicht drauf verlassen. There be dragons.
Die mitgelieferten PCMCIA-Treiber für mein eines Notebook (486er) funktionieren übrigens mit geladenem EMM386 nicht, neuere Versionen schon. Und mein VIA VX800 mag es garnicht, wenn man die Vesa-Treiber benutzt (danach funktionieren die nativen Treiber nicht mehr ohne Neustart); das mag aber schlechte Hardware sein.
Gruß,
Svenska
-
Hallo,
Genau das sind Doppelposts, Dirk. ;-)
Erwischt. Den nachfolgenden Beitrag hatte ich allerdings noch gar nicht gelesen um darauf gleichzeitig antworten zu können, denn beim Schreiben schaue ich eigentlich nicht ständig nach, ob schon neue Beiträge eingetroffen sind.
Prinzipiell darf jeder BIOS-Interrupt auch in den Protected Mode gehen.
Das würde aber bedeuten das man mit solchen BIOS-Interrupt kein Memmorymanager wie emm386.exe mehr verwenden kann. Mir ist kein Rechner bekannt der nicht mehr auf diese Weise DOS-kompatibel ist.
Bei geladenem EMM386 bist du im VM86, das lässt sich feststellen.
Damit dann die Bios-Routine anstatt selber in den PM zu schalten einen Speicherzugriff über den Memorymanager macht?
Der Unrealmode lässt sich nicht feststellen, denn er ist mit dem RM identisch.
Ja leider. Man kann nur festellen ob der obere Adressbereich erreichbar ist.
BIOS und Treiber können also darauf Rücksicht nehmen.
Bisher habe ich noch keine solche Hardware verwendet.
Ich habe mal gelesen, dass einige Option-ROMs (SCSI-Controller, Grafikkarten) in ihren Handlern auch genau das tun.
Ich habe es nur gerüchteweise gehört, das es so etwas geben soll. Welche Karten davon nun genau betroffen sind konnnte ich jedoch noch nicht ermitteln.
Kurze Suche ergibt dieses (http://downloadmirror.intel.com/10177/eng/P43-0260_Release_Notes.txt):
#12881: Intel RAID cards not working on Westville 533 (BIOS B05 +).
This was due to the Intel RAID card going into protected mode and
not returning to big real mode. The fix is to go back into big real
mode immediatly after option ROMs have executed.
Ah prima. Aber wie darf man das denn nun verstehen, werden beim Zurückschalten in den "big real mode/UnRealmode" etwa nur FS und GS auf 4 Gib erweitert, wie es oft für den UnRealmode empfohlen wird, oder werden auch DS und ES erweitert?
Auch PXE-Boot-ROMs müssen im Protected Mode arbeiten, um die Boot-Images im Speicher verwalten zu können und sie stellen meist auch einen Zugriff auf das Netzwerk "für später" bereit. Der TCP/IP-Stack dafür dürfte auch im erweiterten Speicher liegen...
Die Frage ist immer, ob die Funktionen korrekt zurückkehren (also auch in den Unrealmode) oder nicht.
PXE-Boot-ROMs habe ich noch nie verwendet, auch kenne ich keinen einzigen PC-Anwender persöhnlich der je so etwas benutzt hat.
Guter BIOS-Code würde im Übrigen auch dann, wenn er in den PM schaltet, alles brav wieder zurücksetzen.
Wenn emm386.exe bereits gestartet wurde, dann wird kein Bios-Interrupt selber mehr in den PM schalten können.
Aber er kann dies feststellen. Stellt der Interrupt fest, dass er im VM86 aufgerufen wurde, dann wird eine RM-kompatible Routine aufgerufen, andernfalls eine effizientere Routine, die über den PM geht.
Ok, also wahlweise läuft der Speicherzugriff dann über den Memmorymanager, wenn vom VM86 aufgerufen wurde.
Ich denke aus diesem Grund werden solche Bios-Funktionen die selber in den PM schalten nicht oft anzutreffen sein und damit eine Ausnahme bleiben.
Naja, RM ist nur 16-bittig. Die große Masse der BIOS-Funktionen wird damit auskommen - nach dem Boot sind BIOS-Interrupts ohnehin fast nutzlos
Für DOS sind BIOS-Interrupts ganz gewiss nicht nutzlos und ein wesentlicher Bestandteil des Systems.
- aber wenn es um hohe Geschwindigkeit geht... wie gesagt, ich würde mich nicht drauf verlassen. There be dragons.
Ich selber möchte eigentlich nur Hardware verwenden mit den der RM und auch der UnRealmode zuverlässig läuft.
Die mitgelieferten PCMCIA-Treiber für mein eines Notebook (486er) funktionieren übrigens mit geladenem EMM386 nicht, neuere Versionen schon.
Es gibt auch einige ältere DOS-Spiele die selber in den PM schalten und kein EMM386 mögen.
Und mein VIA VX800 mag es garnicht, wenn man die Vesa-Treiber benutzt (danach funktionieren die nativen Treiber nicht mehr ohne Neustart); das mag aber schlechte Hardware sein.
Gruß,
Svenska
Ich würde immer ein System mit auswechelbarer GraKa vorziehen und Notebooks/Schlappis haben mir zu viele Mängel als das ich dazu Lust verspühren würde mich damit zu befassen.
Dirk
-
Hallo,
Genau das sind Doppelposts, Dirk. ;-)
Erwischt. Den nachfolgenden Beitrag hatte ich allerdings noch gar nicht gelesen um darauf gleichzeitig antworten zu können, denn beim Schreiben schaue ich eigentlich nicht ständig nach, ob schon neue Beiträge eingetroffen sind.
Genau dafür gibt es den "Editieren"-Knopf an jedem deiner Posts. ;-)
Bei geladenem EMM386 bist du im VM86, das lässt sich feststellen.
Damit dann die Bios-Routine anstatt selber in den PM zu schalten einen Speicherzugriff über den Memorymanager macht?
Beispielsweise. Oder eine langsamere, kompatible RM-Routine einsetzt.
BIOS und Treiber können also darauf Rücksicht nehmen.
Bisher habe ich noch keine solche Hardware verwendet.
Oder es nicht gemerkt. Das meinte ich oben mit "gutem Code".
Ich habe mal gelesen, dass einige Option-ROMs (SCSI-Controller, Grafikkarten) in ihren Handlern auch genau das tun.
Ich habe es nur gerüchteweise gehört, das es so etwas geben soll. Welche Karten davon nun genau betroffen sind konnnte ich jedoch noch nicht ermitteln.
Kurze Suche ergibt dieses (http://downloadmirror.intel.com/10177/eng/P43-0260_Release_Notes.txt):
#12881: Intel RAID cards not working on Westville 533 (BIOS B05 +).
This was due to the Intel RAID card going into protected mode and
not returning to big real mode. The fix is to go back into big real
mode immediatly after option ROMs have executed.
Ah prima. Aber wie darf man das denn nun verstehen, werden beim Zurückschalten in den "big real mode/UnRealmode" etwa nur FS und GS auf 4 Gib erweitert, wie es oft für den UnRealmode empfohlen wird, oder werden auch DS und ES erweitert?
Ich vermute, dass die Routine nicht in den "big real mode", sondern nur in den "real mode" zurückgeschaltet hat und damit jeden Unrealmode vernichtet hat. Der Fix wäre dann, einfach vorher DS/ES/FS/GS zu sichern und wiederherzustellen - also in den Ursprungszustand zurückzuschalten.
Wie auch immer, um die Details ging es mir nicht, sondern nur um zu zeigen, dass Option-ROMs durchaus in den Protected Mode und zurück schalten können und es auch tun.
Auch PXE-Boot-ROMs müssen im Protected Mode arbeiten, um die Boot-Images im Speicher verwalten zu können und sie stellen meist auch einen Zugriff auf das Netzwerk "für später" bereit. Der TCP/IP-Stack dafür dürfte auch im erweiterten Speicher liegen...
PXE-Boot-ROMs habe ich noch nie verwendet, auch kenne ich keinen einzigen PC-Anwender persöhnlich der je so etwas benutzt hat.
Ich nutze sowas öfter. Für mein Netbook und andere halbwegs moderne Hardware, wenn sie nicht von meinem USB-Stick booten kann. Aber alle Funktionen nutze ich auch nicht.
Naja, RM ist nur 16-bittig. Die große Masse der BIOS-Funktionen wird damit auskommen - nach dem Boot sind BIOS-Interrupts ohnehin fast nutzlos
Für DOS sind BIOS-Interrupts ganz gewiss nicht nutzlos und ein wesentlicher Bestandteil des Systems.
Ja. Für DOS selbst ist der PM aber auch nicht relevant (nur für Anwendungen wie EMM386 oder HIMEM). Ich meinte moderne Betriebssysteme. Für die sind BIOS-Interrupts nach dem Systemstart nur Makulatur.
Ich würde immer ein System mit auswechelbarer GraKa vorziehen und Notebooks/Schlappis haben mir zu viele Mängel als das ich dazu Lust verspühren würde mich damit zu befassen.
Sie sind praktisch und transportabel. Das ist für mich wichtiges Argument.
Aber wir kommen vom Thema ab.
Gruß,
Svenska
-
Erwischt. Den nachfolgenden Beitrag hatte ich allerdings noch gar nicht gelesen um darauf gleichzeitig antworten zu können, denn beim Schreiben schaue ich eigentlich nicht ständig nach, ob schon neue Beiträge eingetroffen sind.
Wenn du auf Absenden drückst, weist dich das Forum eigentlich darauf hin. Das steht dann in roter Schrift über dem Eingabeformular, das in diesem Fall dann wieder erscheint.
-
Erwischt. Den nachfolgenden Beitrag hatte ich allerdings noch gar nicht gelesen um darauf gleichzeitig antworten zu können, denn beim Schreiben schaue ich eigentlich nicht ständig nach, ob schon neue Beiträge eingetroffen sind.
Wenn du auf Absenden drückst, weist dich das Forum eigentlich darauf hin. Das steht dann in roter Schrift über dem Eingabeformular, das in diesem Fall dann wieder erscheint.
Das muss ich wohl dann übersehen haben. Danke für den Hinweis.
Dirk
-
Hallo,
Ich habe den 16 Bit UnReal-Mode schon auf mehreren x86-Rechnerplattforemen erfolgreich verwendet. Begonnen mit 80386er, 80468, mit Rechner für Sockel 5, 6, 7, Pentuim 3, 4 und jetzt Core2Quad und ich habe noch nie derartige Probleme damit feststellen können.
Wir haben damals auf einem 486 und einem Pentium 60MHz (erste Generation, noch kein Sockel 7 aber dafür mit VLB-Slots auf dem Board) getestet und es nicht stabil hin bekommen. Aber vielleicht haben wir uns damals einfach nur zu blöd angestellt, auch das ist nicht ausgeschlossen.
Ich erweiterte aber eigentlich nur DS ....
Ich weis nicht ob das eine Rolle spielt aber ich denke eher nicht.
Ich sehe keinen Grund auf den UnReal-Mode zu verzichten, auf unseren Rechnern lief er bisher genauso stabil und zuverlässig wie RM und PM.
Der UnReal-Mode ist keine zugesicherte Eigenschaft und das macht ihn zu einer Kann-Angelegenheit. Es wäre also durchaus möglich das er irgendwann nicht mehr funktioniert, z.B. auf einer abgespeckten Embedded-Version die trotzdem voll x86-Kompatibel ist. Es gab mal eine 386EX-Variante (Single-Chip-Lösung mit dem üblichen x86-Drum-Herrum komplett integriert), die letzten davon sogar mit Unterstützung für CPUID und den SMM, speziell für kleine Lowest-Power-Applikationen, ich kann mir durchaus vorstellen das da nicht alle üblichen Tricks funktioniert haben, schon weil z.B. keine Windows-Kompatibilität gefragt war dürften auch die Endtests deutlich kleiner ausgefallen sein.
Könnte es eigentlich sein das der SMM den UnReal-Mode kaputt macht?
In den SMM kann ja von jedem beliebigen anderen Modus hinein gewechselt werden und der Ausgangs-Modus wird da speziell gesichert. Ich könnte mir vorstellen dass das Wiederherstellen von "undefinierten Betriebszuständen" (in genau diese Kategorie fällt der UnReal-Mode) nicht immer funktioniert.
Grüße
Erik
-
Hallo,
Ich habe den 16 Bit UnReal-Mode schon auf mehreren x86-Rechnerplattforemen erfolgreich verwendet. Begonnen mit 80386er, 80468, mit Rechner für Sockel 5, 6, 7, Pentuim 3, 4 und jetzt Core2Quad und ich habe noch nie derartige Probleme damit feststellen können.
Wir haben damals auf einem 486 und einem Pentium 60MHz (erste Generation, noch kein Sockel 7 aber dafür mit VLB-Slots auf dem Board) getestet und es nicht stabil hin bekommen. Aber vielleicht haben wir uns damals einfach nur zu blöd angestellt, auch das ist nicht ausgeschlossen.
Ich erweiterte aber eigentlich nur DS ....
Ich weis nicht ob das eine Rolle spielt aber ich denke eher nicht.
Ich sehe keinen Grund auf den UnReal-Mode zu verzichten, auf unseren Rechnern lief er bisher genauso stabil und zuverlässig wie RM und PM.
Der UnReal-Mode ist keine zugesicherte Eigenschaft und das macht ihn zu einer Kann-Angelegenheit. Es wäre also durchaus möglich das er irgendwann nicht mehr funktioniert, z.B. auf einer abgespeckten Embedded-Version die trotzdem voll x86-Kompatibel ist. Es gab mal eine 386EX-Variante (Single-Chip-Lösung mit dem üblichen x86-Drum-Herrum komplett integriert), die letzten davon sogar mit Unterstützung für CPUID und den SMM, speziell für kleine Lowest-Power-Applikationen, ich kann mir durchaus vorstellen das da nicht alle üblichen Tricks funktioniert haben, schon weil z.B. keine Windows-Kompatibilität gefragt war dürften auch die Endtests deutlich kleiner ausgefallen sein.
Könnte es eigentlich sein das der SMM den UnReal-Mode kaputt macht?
In den SMM kann ja von jedem beliebigen anderen Modus hinein gewechselt werden und der Ausgangs-Modus wird da speziell gesichert. Ich könnte mir vorstellen dass das Wiederherstellen von "undefinierten Betriebszuständen" (in genau diese Kategorie fällt der UnReal-Mode) nicht immer funktioniert.
Grüße
Erik
Über SMM werden z.B. auch mit "USB legacy" die USB-Signale konvertiert, damit man eine USB-Mouse auch als PS2-Mouse benutzen kann.
Auf meinem Asus Striker-MoBo mit Sockel 775 und Intel Core2quad klappt das auch mit angeschalteten Unrealmode, ohne das der Unrealmode dadurch völlig ausgeschaltet, oder übermäßig gestört wird. Wenn ich es richtig verstanden habe, dann benutzt der SMM einen eigenen Adressierungsmode um auf den gesamten physikalischen Speicher zuzugreifen.
Als "undefinierten Betriebszustand" wurde der Unrealmode doch nur definiert, weil Microsaft ihr damals gerade herauskommendes Windows 95 vermarkten wollte, obwohl MS den Unrealmode im Himem.sys(version 2.03) ja selber jahrelang benutzt hat und der auf nahezu allen damaligen Rechnern ab 1988 verwendet wurde.
Erst mit der Einführung von Windows 95 wurde der Unrealmode nicht mehr interessant, da er nicht mit Windows kooperiert und Anwendungen die den Unrealmode nutzen möchten einen Neustart des Rechners benötigen. Vorher (im Zeitraum von 1990-1995) benutzten viele Computer-Spiele noch den Unrealmode. Hinterher davon zu sprechen das der Unrealmode ein "undefinierten Betriebszustand" wäre ist doch einfach nur eine dreiste Lüge, auch dann wenn manche neuere Hardware diesen selbstauferlegten "undefinierten Betriebszustand" durch nicht mehr kompatible Firmware in wenigen Fällen dazu inkompatibel gemacht haben. Auch der Umstand das Intel in einigen ihrer CPUs für den Unrealmode selber ein Loadall-Opcode integriert hat, zeigt es doch das wir es hier keinesfalls mit einem Hardware-Bug, oder undefinierten Betriebsmode zu tun haben, sondern das hier ganz gezielt eine Unterstützung für den Unrealmode beabsichtigt war.
Dirk
-
Hallo,
Wenn ich es richtig verstanden habe, dann benutzt der SMM einen eigenen Adressierungsmode um auf den gesamten physikalischen Speicher zuzugreifen.
Richtig, der SMM ist wimre so was ähnliches wie ne Kreuzung aus Protected-Mode und UnReal-Mode. Es gibt aber noch einige Modi mehr auf modernen x86-CPU, z.B. für das nicht vertrauenswürdige Trusted-Computing. Ich könnte mir vorstellen das nicht jede beliebige Kombination vom Modus-Wechseln unter allen Umständen immer fehlerfrei funktioniert, AMD und Intel machen auch mal Fehler und testen tun die zu erst mal mit den wichtigen Features die häufig benutzt werden und die auch laut Datenblatt vorhanden sein müssen.
Als "undefinierten Betriebszustand" wurde der Unrealmode doch nur definiert,
Da hast Du mich leider missverstanden, es geht nicht um einen "undefinierten Betriebszustand" sondern um eine nicht zugesicherte Eigenschaft. Verantwortlich fühlen sich AMD, Intel und alle anderen die x86-CPUs herstellen nur für das was sie auch zugesichert haben, zuerst kommt das Pflichtprogramm und der Rest ist die Kür aber wenn sich dafür keiner interessiert und eben auch niemand Beifall klatscht dann wird die Kür auch schon mal weggelassen oder zumindest stark reduziert. Schau Dir mal an bei was für Fehler AMD und Intel in den letzten 20 Jahren ihre Produkte schon mal zurück gerufen haben und was für Fehler stillschweigend ignoriert werden (das Letzte findet man oft in den Erratas und das Erste in den Medien, ich würde wetten das ein Problem mit dem UnReal-Mode in den Erratas verschwindet).
obwohl MS den Unrealmode im Himem.sys(version 2.03) ja selber jahrelang benutzt hat und der auf nahezu allen damaligen Rechnern ab 1988 verwendet wurde.
Dann hätte HIMEM.SYS mit sehr vielen Spielen und etlichen anderen Programmen die einen DOS-Extender benutzen nicht ordentlich funktioniert. Das Problem am UnReal-Mode ist das man ihn nicht erkennen kann und auch nicht prüfen kann ob er beschädigt wurde, man kann nur probieren und schauen ob ne Exception kommt.
Vorher (im Zeitraum von 1990-1995) benutzten viele Computer-Spiele noch den Unrealmode.
Bitte nenne mal ein paar Beispiele. Alle DOS-Spiele aus der Zeit die ich kenne nutzen einen (zugekauften) anständigen DOS-Extender.
Auch der Umstand das Intel in einigen ihrer CPUs für den Unrealmode selber ein Loadall-Opcode integriert hat, zeigt es doch das wir es hier keinesfalls mit einem Hardware-Bug, oder undefinierten Betriebsmode zu tun haben, sondern das hier ganz gezielt eine Unterstützung für den Unrealmode beabsichtigt war.
Das der UnReal-Mode von den Intel-Ingeniören nicht unbedingt unbeabsichtig war vermute ich auch (ist halt so ein dirty Hack der sich eigentlich ganz von selbst nebenbei ergibt wenn man die Protected-Mode-Spezifikation passend interpretiert), aber das der UnReal-Mode jemals ein echtes zugesichertes Produkt-Feature war ist nicht richtig.
Grüße
Erik
PS.: die Art wie Du zitiert finde ich persönlich eher unschön, wenn Du schon meinen ganzen Beitrag am Stück zitierst dann kannst es auch ganz bleiben lassen denn er steht ja eh am Stück unmittelbar vor Deinem Beitrag
-
Wenn ich es richtig verstanden habe, dann benutzt der SMM einen eigenen Adressierungsmode um auf den gesamten physikalischen Speicher zuzugreifen.
Richtig, der SMM ist wimre so was ähnliches wie ne Kreuzung aus Protected-Mode und UnReal-Mode.
Nun habe ich gelesen das alle modernen Intel-CPUs wie bisher mit dem RM beginnen und dann zu einem "Reset Vector" nach 0xFFFFFFF0 (16 Byte unterhalb der 4 Gib Grenze und damit weit oberhalb des ersten Mib) springen, um dort den ersten Befehl auszuführen. Dabei wird eine "hidden base address" für EIP verwendet. Auch wenn es nicht offiziell von Intel bekannt gegeben wird, wenn es alle modernen Intel so machen, dann ist es eben eine Methode die auf allen modernen Intel so verfügbar ist und das völlig unabhängig davon ob es nun offiziel zugesichert wird, oder auch nicht.
Es gibt aber noch einige Modi mehr auf modernen x86-CPU, z.B. für das nicht vertrauenswürdige Trusted-Computing. Ich könnte mir vorstellen das nicht jede beliebige Kombination vom Modus-Wechseln unter allen Umständen immer fehlerfrei funktioniert, AMD und Intel machen auch mal Fehler und testen tun die zu erst mal mit den wichtigen Features die häufig benutzt werden und die auch laut Datenblatt vorhanden sein müssen.
Als "undefinierten Betriebszustand" wurde der Unrealmode doch nur definiert,
Da hast Du mich leider missverstanden, es geht nicht um einen "undefinierten Betriebszustand" sondern um eine nicht zugesicherte Eigenschaft.
Indirekt meinte ich ja genau das. Es ist einfach unwichtig ob es eine offizielle Bestätigung z.B. von Intel dafür gibt wenn alle modernen Intel es so machen. Auch ist es egal ob das nun als "Hack" aller modernen Intel-Rechner bezeichnet wird, oder als offiizell zugesichter Feature. Fakt ist, das es ein Standard auf modernen Intel CPUs geworden ist.
Verantwortlich fühlen sich AMD, Intel und alle anderen die x86-CPUs herstellen nur für das was sie auch zugesichert haben, zuerst kommt das Pflichtprogramm und der Rest ist die Kür aber wenn sich dafür keiner interessiert und eben auch niemand Beifall klatscht dann wird die Kür auch schon mal weggelassen oder zumindest stark reduziert. Schau Dir mal an bei was für Fehler AMD und Intel in den letzten 20 Jahren ihre Produkte schon mal zurück gerufen haben und was für Fehler stillschweigend ignoriert werden (das Letzte findet man oft in den Erratas und das Erste in den Medien, ich würde wetten das ein Problem mit dem UnReal-Mode in den Erratas verschwindet).
Das denke ich auch, da der Unrealmode innerhalb von Anwendungen ja kaum mehr benutzt wird.
obwohl MS den Unrealmode im Himem.sys(version 2.03) ja selber jahrelang benutzt hat und der auf nahezu allen damaligen Rechnern ab 1988 verwendet wurde.
Dann hätte HIMEM.SYS mit sehr vielen Spielen und etlichen anderen Programmen die einen DOS-Extender benutzen nicht ordentlich funktioniert.
Was soll daran denn nicht ordentlich funktioniert haben, es gab eben eine Menge Spiele die es benutzen konnten.
Das Problem am UnReal-Mode ist das man ihn nicht erkennen kann und auch nicht prüfen kann ob er beschädigt wurde, man kann nur probieren und schauen ob ne Exception kommt.
Ich denke nicht das Spiele die für den RM/Unrealmode entwickelt wurden damit jemals grosse Probleme hatten. Jede dieser Anwendungen kann ja überprüfen ob Himem.sys gestartet wurde und ggf. wenn nicht ja selber den Unrealmode anschalten und ob er nun schon vorher aktiv war oder nicht ist hierbei doch völlig unwesentlich, da man aus dem RM, und/oder auch aus dem Unrealmode jederzeit wieder erneut den Unrealmode anschalten kann. Wo ist nun also das Problem, wenn man nicht wirklich festellen kann ob Segmente erweitert wurden, oder noch nicht?
Vorher (im Zeitraum von 1990-1995) benutzten viele Computer-Spiele noch den Unrealmode.
Bitte nenne mal ein paar Beispiele. Alle DOS-Spiele aus der Zeit die ich kenne nutzen einen (zugekauften) anständigen DOS-Extender.
Das kann ich dir leider auch nicht sagen welche Spiele nun genau den Unrealmode benutz haben, aber sicherlich waren es Spiele die den damaligen Himem.sys benutz haben, der ja den Unrealmode dafür benutzt hat. Und nicht jeder Entwickler hatte damals Lust dazu den umständlicher Weg über DOS-Extender zu wählen.
Auch der Umstand das Intel in einigen ihrer CPUs für den Unrealmode selber ein Loadall-Opcode integriert hat, zeigt es doch das wir es hier keinesfalls mit einem Hardware-Bug, oder undefinierten Betriebsmode zu tun haben, sondern das hier ganz gezielt eine Unterstützung für den Unrealmode beabsichtigt war.
Das der UnReal-Mode von den Intel-Ingeniören nicht unbedingt unbeabsichtig war vermute ich auch (ist halt so ein dirty Hack der sich eigentlich ganz von selbst nebenbei ergibt wenn man die Protected-Mode-Spezifikation passend interpretiert), aber das der UnReal-Mode jemals ein echtes zugesichertes Produkt-Feature war ist nicht richtig.
So wie ich es verstanden habe ist der Loadall-Befehl doch nicht für den PM entwickelt worden, sondern nur für den RM, um nicht in den PM schalten zu müssen. Wenn es nur ein Nebenproduckt bei der Entwicklung des PM gewesen wäre, dann hätte man ihn doch gar nich implementieren müssen.
Ob nun der Unrealmode offizilel zugesichert wurde, das intersesierte doch die damaligen Entwickler ebenso wenig, wie es mich heute interessiert, wichtig ist doch nur ob er im weitem Umfeld verfügbar ist, oder eben nicht. Das es hier wenige Ausnahmen gibt wo er dann nicht reibungslos funktioniert ist dabei doch eher nebensächlich. Auf den meisten Rechner bis zu heutigen modernen Rechnern ist der Unrealmode verfügbar, alleine das zählt und dafür brauche ich dann bestimmt keine offizielle Zusage von Intel, AMD mehr dafür. Mir genügt es das er bis heute auch auf modernen Rechner im weitem Umfeld benutzbar ist.
PS.: die Art wie Du zitiert finde ich persönlich eher unschön, wenn Du schon meinen ganzen Beitrag am Stück zitierst dann kannst es auch ganz bleiben lassen denn er steht ja eh am Stück unmittelbar vor Deinem Beitrag
Ja das finde ich auch unschön, wo du es nun erwähnst. Ich war wohl noch etwas zu müde als ich den Beitrag schrieb, so das es mir dabei gar nicht aufgefallen ist. Eigentlich versuche ich auch so etwas zu vermeiden.
Dirk
-
Hallo,
Nun habe ich gelesen das alle modernen Intel-CPUs wie bisher mit dem RM beginnen und dann zu einem "Reset Vector" nach 0xFFFFFFF0 (16 Byte unterhalb der 4 Gib Grenze und damit weit oberhalb des ersten Mib) springen, um dort den ersten Befehl auszuführen. Dabei wird eine "hidden base address" für EIP verwendet. Auch wenn es nicht offiziell von Intel bekannt gegeben wird, wenn es alle modernen Intel so machen, dann ist es eben eine Methode die auf allen modernen Intel so verfügbar ist und das völlig unabhängig davon ob es nun offiziel zugesichert wird, oder auch nicht.
Dieses Verhalten ist wimre offiziell so dokumentiert/spezifiziert. Es ist aber ein Unterschied ob in ein (Schatten-)Register beim Reset ein bestimmter Wert geladen wird oder ob zur Laufzeit ein bestimmter Wert geladen wird, hängt mit dem physischen Aufbau der D-FlipFlops zusammen aus denen die Register zusammengesetzt sind. Sobald das erste mal CS neu geladen wird (also durch einen FAR-JMP/CALL) kommt eine normale RM-Basis in das zugehörige Schatten-Register (das Limit war ja schon vorher auf 64 kB).
Indirekt meinte ich ja genau das. Es ist einfach unwichtig ob es eine offizielle Bestätigung z.B. von Intel dafür gibt wenn alle modernen Intel es so machen. Auch ist es egal ob das nun als "Hack" aller modernen Intel-Rechner bezeichnet wird, oder als offiizell zugesichter Feature. Fakt ist, das es ein Standard auf modernen Intel CPUs geworden ist.
Falls Du jemals dazu kommen solltest kommerzielle Software zu entwickeln dann wird Dir Dein Chef sicher etwas von Produkthaftung usw. erzählen und dann ist auch verständlich warum es keine kommerzielle SW gibt die diesen UnReal-Mode benutzt. Wenn ich ein Programm kaufen würde auf dessen Verpackung "x86-PC" steht und das geht dann plötzlich nicht dann habe ich ein Anspruch auf Wandlung das Kaufvertrages.
Es fällt mir schwer zu glauben das Microsoft den UnReal-Mode tatsächlich mal benutzt haben soll, aber selbst wenn dann ist Microsoft einfach eine andere Kategorie von Software-Anbieter da seit über 10 Jahren selbst auf CPUs ein offizielles Siegel "Kompatibel mit MS-Windows [aktuelle Version]" einfach Pflicht ist. Auch arbeitet MS schon immer eng mit Intel und auch AMD zusammen.
da der Unrealmode innerhalb von Anwendungen ja kaum mehr benutzt wird.
Und auch nie wirklich breit benutzt wurde, außer von ein paar kleinen Spezial-Programmen vielleicht.
Wenn Du wirklich der Meinung bist das der UnReal-Mode oft benutzt wurde dann nenne bitte mal ein paar Beispiele (an Programmen mit nennenswerter Marktrelevanz).
da man aus dem RM, und/oder auch aus dem Unrealmode jederzeit wieder erneut den Unrealmode anschalten kann. Wo ist nun also das Problem, wenn man nicht wirklich festellen kann ob Segmente erweitert wurden, oder noch nicht?
Wenn man das wirklich ständig machen würde würde das enorm viel Performance kosten, die Modus-Wechsel benötigen ziemlich viele Taktzyklen (sich ja auch nicht dafür vorgesehen ständig benutzt zu werden).
aber sicherlich waren es Spiele die den damaligen Himem.sys benutz haben, der ja den Unrealmode dafür benutzt hat. Und nicht jeder Entwickler hatte damals Lust dazu den umständlicher Weg über DOS-Extender zu wählen.
HIMEM.SYS wird dazu benutzt um den XMS zu Verwalten (eine Art malloc und free für den XMS) und nicht um ihn aktiv zu benutzen.
Und DOS-Extender sind eigentlich recht einfach zu benutzen, man benötigt nur eine passende Entwicklungsumgebung und die haben die Anbieter damals oft mitgeliefert. (die Entwicklungsumgebung von PharLab für den TNT-DOS-Extender hab ich heute noch und die ist etwa von 1985, AutoDesk hat für das damalige AutoCAD 11 auch auf einen DOS-Extender gesetzt und ein umfangreiches Entwicklungspaket angeboten wenn man für das AutoCAD 11 Treiber für Grafikkarten oder Digitizer usw. entwickeln wollte)
So wie ich es verstanden habe ist der Loadall-Befehl doch nicht für den PM entwickelt worden, sondern nur für den RM, um nicht in den PM schalten zu müssen.
Der LOADALL-Befehl war auch nie offiziell spezifiziert und war auch auf jeder CPU-Generation unterschiedlich realisiert (was ja auch logisch ist da er sehr stark von der internen Funktionsweise der CPU abhängt). Außerdem gibt es seit dem 486 kein LOADALL mehr (angeblich auf drängen der NSA).
Mir genügt es das er bis heute auch auf modernen Rechner im weitem Umfeld benutzbar ist.
Dann hoffe ich sehr das Du niemals Software machst auf die ich angewiesen bin, sowas ist einfach keine ordentliche Herangehensweise. Sorry, wenn das hart oder arrogant klingt aber wenn man Software entwickelt die zuverlässig funktionieren soll dann muss man auch auf Dinge aufbauen die ebenfalls zuverlässig funktionieren bzw. wo man jemanden dafür verantwortlich machen kann wenn diese Dinge mal nicht so funktionieren wie sie sollten. Das Konzept des Schuld-Pointers ist Dir bekannt?
Grüße
Erik
-
Hallo,
Nun habe ich gelesen das alle modernen Intel-CPUs wie bisher mit dem RM beginnen und dann zu einem "Reset Vector" nach 0xFFFFFFF0 (16 Byte unterhalb der 4 Gib Grenze und damit weit oberhalb des ersten Mib) springen, um dort den ersten Befehl auszuführen. Dabei wird eine "hidden base address" für EIP verwendet. Auch wenn es nicht offiziell von Intel bekannt gegeben wird, wenn es alle modernen Intel so machen, dann ist es eben eine Methode die auf allen modernen Intel so verfügbar ist und das völlig unabhängig davon ob es nun offiziel zugesichert wird, oder auch nicht.
Dieses Verhalten ist wimre offiziell so dokumentiert/spezifiziert.
Es ist aber ein Unterschied ob in ein (Schatten-)Register beim Reset ein bestimmter Wert geladen wird oder ob zur Laufzeit ein bestimmter Wert geladen wird, hängt mit dem physischen Aufbau der D-FlipFlops zusammen aus denen die Register zusammengesetzt sind. Sobald das erste mal CS neu geladen wird (also durch einen FAR-JMP/CALL) kommt eine normale RM-Basis in das zugehörige Schatten-Register (das Limit war ja schon vorher auf 64 kB).
Solch einen Unterschied im Verhalten der Schattenregister habe ich noch auf keinen der von mir benutzen 80386 bishin zu Core2-Architektur festellen können. Welcher 80386+ soll sich denn hier anders verhalten, so das man ich nicht im Unrealmode betreiben kann?
Indirekt meinte ich ja genau das. Es ist einfach unwichtig ob es eine offizielle Bestätigung z.B. von Intel dafür gibt wenn alle modernen Intel es so machen. Auch ist es egal ob das nun als "Hack" aller modernen Intel-Rechner bezeichnet wird, oder als offiizell zugesichter Feature. Fakt ist, das es ein Standard auf modernen Intel CPUs geworden ist.
Falls Du jemals dazu kommen solltest kommerzielle Software zu entwickeln dann wird Dir Dein Chef sicher etwas von Produkthaftung usw. erzählen und dann ist auch verständlich warum es keine kommerzielle SW gibt die diesen UnReal-Mode benutzt.
Ich benutze Computer nur rein privat. Es gab zwischen 1990-1995 DOS-Spiele die den Unrealmode benutzen.
Wenn ich ein Programm kaufen würde auf dessen Verpackung "x86-PC" steht und das geht dann plötzlich nicht dann habe ich ein Anspruch auf Wandlung das Kaufvertrages.
Bei der gesetzlicher Gewährleistung darf ein Händler vorher noch nachbessern, bzw. ein funktionstüchtiges Exemplar aushändigen, bevor man überhaupt ein Recht auf Wandlung bekommt. Eine sofortige Wandlung weil es plötlich doch nicht geht, das wäre nur aus Kulanz möglich, oder wenn der Händler kein funktionstüchtiges Exemplar verfügbar hat.
Es fällt mir schwer zu glauben das Microsoft den UnReal-Mode tatsächlich mal benutzt haben soll,
http://www.os2museum.com/wp/?p=322
"In August 1988, HIMEM.SYS version 2.03 implemented a new method of copying memory on 386 compatible processors, using unreal mode (or Big Real mode as it’s called in the HIMEM source)"
Leider kann ich nur den Sourcode von Version 2.06 finden in dem aber auf den Big Mode von Version 2.03 hingewiesen wird:
http://202.129.48.214/CD3003/Source/XMMAPI/XMS20/HIMEM.ASM
; 2.03 - Added 386 Big Mode MoveBlock 8/04/88
aber selbst wenn dann ist Microsoft einfach eine andere Kategorie von Software-Anbieter da seit über 10 Jahren selbst auf CPUs ein offizielles Siegel "Kompatibel mit MS-Windows [aktuelle Version]" einfach Pflicht ist.
Von mir aus kann auf modernen CPUs auch gerne kompatibel mit Linux stehen, denn an derartige Plfichten brauche ich mich ja nicht gebunden fühlen.
Auch arbeitet MS schon immer eng mit Intel und auch AMD zusammen.
Davon merkt man aber sehr wenig so verbugt wie Windows immer ist.
da der Unrealmode innerhalb von Anwendungen ja kaum mehr benutzt wird.
Und auch nie wirklich breit benutzt wurde, außer von ein paar kleinen Spezial-Programmen vielleicht.
Wenn Du wirklich der Meinung bist das der UnReal-Mode oft benutzt wurde dann nenne bitte mal ein paar Beispiele (an Programmen mit nennenswerter Marktrelevanz).
Welche Spiele nun genau den Unrealmode benutzten ist mir auch nicht bekannt. Es gab aber zahlreiche Spiele im Zeitraum von 1990 - 1995 die den Unrealmode benutzten, das ist allgemein bekannt. In wie weit diese Spiele auch marktrelevant waren ist doch völlig unwerheblich, denn die technische Möglichkeit war allseits vorhanden in den Unrealmode zu schalten, denn sonst hätte kein einziges dieser Spiele, welches den Unrealmode benutzt, es jemals geschaft auf dem Markt angeboten zu werden.
da man aus dem RM, und/oder auch aus dem Unrealmode jederzeit wieder erneut den Unrealmode anschalten kann. Wo ist nun also das Problem, wenn man nicht wirklich festellen kann ob Segmente erweitert wurden, oder noch nicht?
Wenn man das wirklich ständig machen würde würde das enorm viel Performance kosten, die Modus-Wechsel benötigen ziemlich viele Taktzyklen (sich ja auch nicht dafür vorgesehen ständig benutzt zu werden).
Mit jederzeit meine ich ganz gewiss nicht ständig, sondern nur dann wenn hin und her geschaltet werden soll und ob man nun in den RM schaltet, oder in den Unrealmode, das wird ganz gewiss keinen zeitlichen Unterschied machen. Ausgehend von dem Umstand das man nicht feststellen kann ob Segmente erweitert wurden (wir uns im Unrealmode befinden), oder doch nur im RM, macht das überhaupt keinen zeitlichen Unterschied wenn man in den PM schaltet und wieder zurück.
aber sicherlich waren es Spiele die den damaligen Himem.sys benutz haben, der ja den Unrealmode dafür benutzt hat. Und nicht jeder Entwickler hatte damals Lust dazu den umständlicher Weg über DOS-Extender zu wählen.
HIMEM.SYS wird dazu benutzt um den XMS zu Verwalten (eine Art malloc und free für den XMS) und nicht um ihn aktiv zu benutzen.
Hä, warum sollte man HIMEM.SYS (und darüber XMS-Speicher) nicht selber aktiv benutzen können (ohne EMS)?
Und DOS-Extender sind eigentlich recht einfach zu benutzen, man benötigt nur eine passende Entwicklungsumgebung und die haben die Anbieter damals oft mitgeliefert. (die Entwicklungsumgebung von PharLab für den TNT-DOS-Extender hab ich heute noch und die ist etwa von 1985, AutoDesk hat für das damalige AutoCAD 11 auch auf einen DOS-Extender gesetzt und ein umfangreiches Entwicklungspaket angeboten wenn man für das AutoCAD 11 Treiber für Grafikkarten oder Digitizer usw. entwickeln wollte)
Im Vergleich zu einer linearen Adressierung im Unrealmode (beispielsweise über DS:Reg32) sind DOS-Extender aber nur sehr umständlich benutzbar.
Ich würde mir das nicht freiwillig antun wollen einen DOS-Extender zu benutzen, wenn es nicht sein muss und das es auch einfacher geht habe ich ja schon seit Jahren erfolgreich auf verschiedenen CPUs seit 80386 bishin zu modernen CPUs von Intel feststellen können. Auch ohne das es eine offizielle Dokumentation dafür gibt.
So wie ich es verstanden habe ist der Loadall-Befehl doch nicht für den PM entwickelt worden, sondern nur für den RM, um nicht in den PM schalten zu müssen.
Der LOADALL-Befehl war auch nie offiziell spezifiziert und war auch auf jeder CPU-Generation unterschiedlich realisiert (was ja auch logisch ist da er sehr stark von der internen Funktionsweise der CPU abhängt). Außerdem gibt es seit dem 486 kein LOADALL mehr (angeblich auf drängen der NSA).
Es ist einfach unwichtig ob der LOADALL-Befehl je offiziell spezifiziert wurde, er war vorhanden und das genügt um zu zeigen das es für den Unrealmode
eine Unterstützung gab die beabsichtigt implementiert wurde und wenn du nun auch noch darauf hinweist, das es verschiedene Arten gab diesen Befehl
zu implementieren, na dann ist das noch mehr ein Grund von einem weit verbreiteten Unrealmode zu reden.
Mir genügt es das er bis heute auch auf modernen Rechner im weitem Umfeld benutzbar ist.
Dann hoffe ich sehr das Du niemals Software machst auf die ich angewiesen bin, sowas ist einfach keine ordentliche Herangehensweise.
Ich sehe schon "ordentlich" ist wohl nur das für dich nur was du offiziell erlaubt/bestätigst bekommst. Ich hingegen schaue lieber selber nach und probiere es einfach mal aus und wenn es dann auf verschiedener Hardware beginnend vom 80386 bis zu modernen Rechnern funktioniert, dann bilde ich mir ein eigenen Urteil. Egal ob es so nicht offizilell gewollt ist, oder auch nicht. Für mich ist das Jacke wie Hose.
Sorry, wenn das hart oder arrogant klingt aber wenn man Software entwickelt die zuverlässig funktionieren soll dann muss man auch auf Dinge aufbauen die ebenfalls zuverlässig funktionieren
Bei allen den von mir verwendeten x86-Rechnern seit 80386 lief der Unrealmode immer zuverlässig. Mir genügt das.
bzw. wo man jemanden dafür verantwortlich machen kann wenn diese Dinge mal nicht so funktionieren wie sie sollten. Das Konzept des Schuld-Pointers ist Dir bekannt?
Grüße
Erik
Den Begriff Schuld-Pointers kenne ich noch nicht. Ich suche gleich mal danach.
Eine Verantwortung für die Sachen die ich programmiert haben lehne ich grundsätzlich ab.
Alles darf jeder Anwender in völliger Eigenverantwortung benutzen.
Dirk
-
Hallo,
Es ist aber ein Unterschied ob in ein (Schatten-)Register beim Reset ein bestimmter Wert geladen wird oder ob zur Laufzeit ein bestimmter Wert geladen wird, hängt mit dem physischen Aufbau der D-FlipFlops zusammen aus denen die Register zusammengesetzt sind. Sobald das erste mal CS neu geladen wird (also durch einen FAR-JMP/CALL) kommt eine normale RM-Basis in das zugehörige Schatten-Register (das Limit war ja schon vorher auf 64 kB).
Solch einen Unterschied im Verhalten der Schattenregister habe ich noch auf keinen der von mir benutzen 80386 bishin zu Core2-Architektur festellen können.
Was für einen Unterschied möchtest Du feststellen? Wie sich die Transistoren in den CPUs verhalten? Das folgt zum einen den Gesetzen der Physik und ist zum anderen so umfangreich das sich das nicht von außen betrachtet auf einzelne Transistoren runter brechen lässt.
Welcher 80386+ soll sich denn hier anders verhalten, so das man ich nicht im Unrealmode betreiben kann?
Habe ich irgenwo geschrieben das ich eine 80386+ CPU kenne die den UnReal-Mode nicht unterstützt?
Ich weise lediglich darauf hin das diese Betriebsart nicht zugesichert wird und damit eine Unterstützung möglicherweise in Zukunft nicht mehr vorhanden sein könnte (wenn z.B. mal Transistoren gespart werden müssen).
Ich benutze Computer nur rein privat.
Auch bei meinem privaten Computer ist für mich Zuverlässigkeit ein sehr wichtiges Kriterium. Wenn Du das für Dich persönlich anders entscheidest ist das völlig in Ordnung, aber deswegen kannst Du nicht auf andere schließen.
Es gab zwischen 1990-1995 DOS-Spiele die den Unrealmode benutzen.
Beispiele Bitte!
Bei der gesetzlicher Gewährleistung darf ein Händler vorher noch nachbessern ....
Wenn es sich wirklich um eine Software handelt die den UnReal-Mode nutzt und meine x86-CPU den aber nicht unterstützt (egal aus welchen Grund) dann dürfte es schwer für den Händler werden ein funktionsfähiges Exemplar dieser Software aus dem Regal zu nehmen und das Nachbessern würde einem Neuentwickeln gleich kommen und das kostet unter Umständen sehr viel Geld.
Leider kann ich nur den Sourcode von Version 2.06 finden in dem aber auf den Big Mode von Version 2.03 hingewiesen wird:
http://202.129.48.214/CD3003/Source/XMMAPI/XMS20/HIMEM.ASM
; 2.03 - Added 386 Big Mode MoveBlock 8/04/88
Okay, Microsoft hat also tatsächlich mal in einer Version von HIMEM.SYS den UnReal-Mode benutzt. Warum nur in einer Version? Gab es da etwa Probleme mit? Ob der verantwortliche Programmierer, der das eingebaut hat, heute noch für MS arbeitet?
Von mir aus kann auf modernen CPUs auch gerne kompatibel mit Linux stehen, denn an derartige Plfichten brauche ich mich ja nicht gebunden fühlen.
Andere fühlen sich an solche Dinge gebunden. Z.B. Hersteller von Bankautomaten legen extrem großen Wert darauf die verwendete Hardware sehr gründlich zu validieren, die testen wirklich jeden einzelnen Rechen-Befehl in der verwendeten CPU damit die auch alle gehen und wenn die CPU in einer neuen Masken-Revision raus kommt wird noch mal von vorne Validiert. Das machen die (obwohl das viel Geld kostet) weil der Image-Verlust für die Bank (die diesen Automaten für sich einsetzt) durch eine Fehlbuchung deutlich schlimmer wäre.
Welche Spiele nun genau den Unrealmode benutzten ist mir auch nicht bekannt. Es gab aber zahlreiche Spiele im Zeitraum von 1990 - 1995 die den Unrealmode benutzten, das ist allgemein bekannt.
Also mir ist davon nichts bekannt und ich hab in dieser Zeit viele Spiele ausprobiert (natürlich hab ich nicht in jedes reingesehen aber bei vielen hat man bekannte Anzeichen bestimmter DOS-Extender gefunden). Also von "allgemein bekannt" kann man da wirklich nicht reden. Ich will ja gar nicht bestreiten das es nicht doch einzelne kommerzielle Programme gab die den UnReal-Mode genutzt haben aber echte Bedeutung hatte davon sicher keines.
Hä, warum sollte man HIMEM.SYS (und darüber XMS-Speicher) nicht selber aktiv benutzen können (ohne EMS)?
Klar kannst Du den XMS selber aktiv benutzen (nachdem Du Deinen Block gelockt hast um auch seine physische Adresse zu kennen) aber HIMEM.SYS benutzt Deinen Block nicht für sich.
Im Vergleich zu einer linearen Adressierung im Unrealmode (beispielsweise über DS:Reg32) sind DOS-Extender aber nur sehr umständlich benutzbar.
Hast Du Dich denn damit schon mal wirklich richtig beschäftigt? Auf was für eigenen Erfahrungen beruht dieses Urteil von Dir?
Vor 10 Jahren hab ich einige große Programme mit Hilfe von verschiedenen DOS-Extendern entwickelt und das ist nicht schwieriger als würde man ein Programm für Windows oder für POSIX entwickeln, DOS-Extender sind einfach nur eine andere Laufzeitumgebung (mit spezifischen Schwächen aber auch Stärken).
Es ist einfach unwichtig ob der LOADALL-Befehl je offiziell spezifiziert wurde, er war vorhanden und das genügt um zu zeigen das es für den Unrealmode eine Unterstützung gab die beabsichtigt implementiert wurde
Den LOADALL-Befehl gab es auch auf 286, hatten die etwa auch einen UnReal-Mode? Das es den LOADALL-Befehl gab hat ganz sicher andere Gründe.
.... Mir genügt das.
Es gibt Bereiche wo das nicht genügt. Wenn Du z.B. für ein medizinisches Gerät eine Zulassung haben möchtest und der Prüfer sieht das Du irgend ein Bauteil außerhalb der Spezifikation betreibst kannst Du Dir sicher sein das die Zulassung nicht allzu bald erteilt werden wird. Ich hab schon mal ein medizinisches Gerät durch den Zulassungsprozess begleitet (ich hab bei einer der Komponenten den FPGA-Inhalt und Teile des Schaltplans entwickelt) und das ist wahrlich kein Zuckerschlecken.
Eine Verantwortung für die Sachen die ich programmiert haben lehne ich grundsätzlich ab.
Alles darf jeder Anwender in völliger Eigenverantwortung benutzen.
Stell Dir vor Dein Stromanbieter würde das auch so handhaben. Ich bin mir sicher Du findest Dinge in Deinem Leben wo es Dir doch extrem wichtig ist das die 100% Zuverlässig funktionieren bzw. das die verantwortlichen Entwickler zumindest alles menschenmögliche Unternommen haben um die Zuverlässigkeit zu hoch wie nur irgend möglich zu bringen.
Sorry, aber solange Du so eine Meinung vertrittst hoffe ich wirklich das ich nie auf Dinge von Dir angewiesen bin.
Grüße
Erik
-
Hallo,
Es ist aber ein Unterschied ob in ein (Schatten-)Register beim Reset ein bestimmter Wert geladen wird oder ob zur Laufzeit ein bestimmter Wert geladen wird, hängt mit dem physischen Aufbau der D-FlipFlops zusammen aus denen die Register zusammengesetzt sind. Sobald das erste mal CS neu geladen wird (also durch einen FAR-JMP/CALL) kommt eine normale RM-Basis in das zugehörige Schatten-Register (das Limit war ja schon vorher auf 64 kB).
Solch einen Unterschied im Verhalten der Schattenregister habe ich noch auf keinen der von mir benutzen 80386 bishin zu Core2-Architektur festellen können.
Was für einen Unterschied möchtest Du feststellen?
Ich möchte im Verhalten der Schatten-Register eigentlich gar keinen Unterschied feststellen. Ich bin nur überascht davon, das es dabei überhaupt einen Unterschied geben soll zwischen der Laufzeit und einem Reset.
Wie sich die Transistoren in den CPUs verhalten? Das folgt zum einen den Gesetzen der Physik und ist zum anderen so umfangreich das sich das nicht von außen betrachtet auf einzelne Transistoren runter brechen lässt.
Und wie macht sich der Unterschied im Verhalten der CPU programmtechnisch bemerkbar?
Welcher 80386+ soll sich denn hier anders verhalten, so das man ich nicht im Unrealmode betreiben kann?
Habe ich irgenwo geschrieben das ich eine 80386+ CPU kenne die den UnReal-Mode nicht unterstützt?
Abgeleitet von dem von dir erwähnten Unterschied zwischen den Schatten-Register einmal zur Laufzeit und einmal beim Reset erschien es mir naheliegend, das du hier auch ein abweichendes Verhalten bezüglich des Unrealmodes hättest andeuten können. Daher frage ich nun einmal gezielt nach, ob du das damit meintest. Wenn du das jedoch gar nicht so meintest, dann freue ich mich darüber.
Aber von welchen Unterschied redest du denn nun genau?
Ich weise lediglich darauf hin das diese Betriebsart nicht zugesichert wird und damit eine Unterstützung möglicherweise in Zukunft nicht mehr vorhanden sein könnte (wenn z.B. mal Transistoren gespart werden müssen).
Damit rechne ich auch das zukünftlige Rechner auch nicht mehr im RM starten und auch kein RM-Bios mehr mitbringen. Ich denke Rechner mit EFI-Bios sind bisher immer noch zweigleisig aufgebaut und bringen über den Kompatibilitätsmode auch den RM mit. Die Entwicklung geht aber ständig weiter. Doch es dauert noch eine Weile bis alle Retro-Museums-Rechner kaputt gehen und ganz genau so lange wird es auch den RM und auch den Unrealmode geben. Ich denke nicht das eine Sparmassnahme nur den Unrealmode verhindert, nicht aber den RM. Also wenn, dann geht beides nicht mehr, denn ich denke das es keine speziellen Transistoren nur für den Unrealmode gibt ganz ohne das sie nicht ebenso anders benutzt werden.
Ich benutze Computer nur rein privat.
Auch bei meinem privaten Computer ist für mich Zuverlässigkeit ein sehr wichtiges Kriterium.
Meine Unrealmode-Anwendungen laufen stets zu 100% zuverlässig. Das kann man von Windows und Anwendungen die dort laufen leider nicht immer behaupten, denn dafür ist selbst Windows 7 einfach immer noch zu fehlerhaft, als das man hier von einer hohen Zuverlässigkeit reden kann.
Wenn Du das für Dich persönlich anders entscheidest ist das völlig in Ordnung, aber deswegen kannst Du nicht auf andere schließen.
Aaaah, du möchtest damit andeuten das der Unrealmode weniger zuverlassig sein soll und stütz diese Vermutung einzig und alleine auf den Umstand das der Unrealmode nicht dokumentiert wurde, weil MS das Windows 95 damals vermarkten wollte und wie du schon sagtest sehr eng mit Intel und AMD zusammen arbeitet und man sich dann wohl darauf geeinigt hat, hier ein Mantel des Stillschweigens über den Unrealmode auszubreiten, obwohl MS den Unrealmode selber vor Jahren im Himem.sys benutzt hat und fast alle x86-Rechner damit betrieben wurden. Nun gut, wenn es das ist was dich zuverlässig werden läßt, ich stütze mich auf meine eigenen Erfahrungen und höre nicht nur auf das was uns Großkonzerne veraten.
Nein du hast nicht gesagt das du einen 80386+ kennst bei dem der Unrealmode nicht funktioniert. Ich vermute nun das du keinen einzigen Rechner kennst bei dem der Unrealmode nicht funktioniert. Soweit zu der von dir erwarteten Zuverlässigkeit.
Es gab zwischen 1990-1995 DOS-Spiele die den Unrealmode benutzen.
Beispiele Bitte!
Es ist ja nicht gerade so das DOS-Spiele als Opensource den Markt überschwemmt haben.
So wüßte ich auch gerne mehr über die Spiele und kann dir leider auch kein konkretes Beispiel nennen.
Bei der gesetzlicher Gewährleistung darf ein Händler vorher noch nachbessern ....
Wenn es sich wirklich um eine Software handelt die den UnReal-Mode nutzt und meine x86-CPU den aber nicht unterstützt (egal aus welchen Grund) dann dürfte es schwer für den Händler werden ein funktionsfähiges Exemplar dieser Software aus dem Regal zu nehmen und das Nachbessern würde einem Neuentwickeln gleich kommen und das kostet unter Umständen sehr viel Geld.
Ja wenn der UnReal-Mode bei dir nicht funktioniert. Hast du eine funktionstüchtige Anwendung die den Unrealmode unterstützt auf deinem Rechner überhaupt schon einmal ausprobiert?
Leider kann ich nur den Sourcode von Version 2.06 finden in dem aber auf den Big Mode von Version 2.03 hingewiesen wird:
http://202.129.48.214/CD3003/Source/XMMAPI/XMS20/HIMEM.ASM
; 2.03 - Added 386 Big Mode MoveBlock 8/04/88
Okay, Microsoft hat also tatsächlich mal in einer Version von HIMEM.SYS den UnReal-Mode benutzt. Warum nur in einer Version? Gab es da etwa Probleme mit?
Soweit war ich noch gar nicht Suchen. Woraus wird denn ersichtlich das bereits in der nächsten Version der Unrealmode nicht mehr benutz wurde?
Ich spekuliere mal, die CPUs wurden immer schneller und es sollte mehr Protection geben, so das der V86-Mode immer beliebter wurde?
Ob der verantwortliche Programmierer, der das eingebaut hat, heute noch für MS arbeitet?
Nicht das es mich wirklich interessieren würde, aber arbeitet denn heute aus der damaligen Zeit überhaupt noch einer der damaligen Programmierer bei MS?
Von mir aus kann auf modernen CPUs auch gerne kompatibel mit Linux stehen, denn an derartige Plfichten brauche ich mich ja nicht gebunden fühlen.
Andere fühlen sich an solche Dinge gebunden. Z.B. Hersteller von Bankautomaten legen extrem großen Wert darauf die verwendete Hardware sehr gründlich zu validieren, die testen wirklich jeden einzelnen Rechen-Befehl in der verwendeten CPU damit die auch alle gehen und wenn die CPU in einer neuen Masken-Revision raus kommt wird noch mal von vorne Validiert. Das machen die (obwohl das viel Geld kostet) weil der Image-Verlust für die Bank (die diesen Automaten für sich einsetzt) durch eine Fehlbuchung deutlich schlimmer wäre.
[Ironie]Ok das überzeugt mich, das Betrügen mit rein virtuellen Werten an den Börsen ist sicherlich sehr viel einfacher, da es ja kaum jemand zu bemerken scheint. So ein minimaler Rechenfehler ist im Vergleich dazu natürlich sehr viel mehr beachtenswerter.[/Ironie]
Mal Spaß wieder beiseite, wir leben in einer Welt in der wir auf Computer nur sehr schwer wieder verzichten können. Da müssen wir uns ganz gewiss auf die Funktionsweise dieser Geräte auch verlassen können. Doch ich programmiere nur für rein private Zwecke und ich habe es auch zukünftig nicht vor einen gewerblichen Zweck damit zu erfüllen. So fühle ich mich auch in keinster Weise daran gebunden nur spezifizierte Verfahren zu benutzen. Ich vermute auch, das die meisten Programmierer ebenfalls nur aus rein privater Natur heraus Spaß daran haben ein klein wenig zu programmieren und diese brauchen für sich eben nicht wirklich eine so hohe Zuverlässigkeit das ihre Anwendung auf allen Rechner nur mit spezifizierten Verfahren läuft. Es genügt das es funktioniert, wir brauchen keinen Intel-Papst der unser Verfahren im nachherein noch segnet.
Welche Spiele nun genau den Unrealmode benutzten ist mir auch nicht bekannt. Es gab aber zahlreiche Spiele im Zeitraum von 1990 - 1995 die den Unrealmode benutzten, das ist allgemein bekannt.
Also mir ist davon nichts bekannt und ich hab in dieser Zeit viele Spiele ausprobiert (natürlich hab ich nicht in jedes reingesehen aber bei vielen hat man bekannte Anzeichen bestimmter DOS-Extender gefunden). Also von "allgemein bekannt" kann man da wirklich nicht reden. Ich will ja gar nicht bestreiten das es nicht doch einzelne kommerzielle Programme gab die den UnReal-Mode genutzt haben aber echte Bedeutung hatte davon sicher keines.
Genau davon ist aber die Rede das eine erhebliche Anzahl an DOS-Spiele im Zeitraum von 1990-1995 den Unrealmode benutzt haben.
Ich weiss nun nicht welche Spiele für dich überhaupt bedeutsam sind, oder einmal waren. Ich habe unter DOS eigentlich sehr wenig gespielt und eher programmiert. Auch fand ich DOS-Spiele bisher nie besonders reizvoll. Heute spiele ich sehr viele mehr mit dem Spiele-Windows, denn für alles Andere ist mir Windows einfach zu unsicher. Beruflich würde ich mich daher nie mit Windows beschäftigen wollen.
Hä, warum sollte man HIMEM.SYS (und darüber XMS-Speicher) nicht selber aktiv benutzen können (ohne EMS)?
Klar kannst Du den XMS selber aktiv benutzen (nachdem Du Deinen Block gelockt hast um auch seine physische Adresse zu kennen)
Ok, das meine ich.
aber HIMEM.SYS benutzt Deinen Block nicht für sich.
Braucht er ja auch nicht.
Im Vergleich zu einer linearen Adressierung im Unrealmode (beispielsweise über DS:Reg32) sind DOS-Extender aber nur sehr umständlich benutzbar.
Hast Du Dich denn damit schon mal wirklich richtig beschäftigt? Auf was für eigenen Erfahrungen beruht dieses Urteil von Dir?
Vor 10 Jahren hab ich einige große Programme mit Hilfe von verschiedenen DOS-Extendern entwickelt und das ist nicht schwieriger als würde man ein Programm für Windows oder für POSIX entwickeln, DOS-Extender sind einfach nur eine andere Laufzeitumgebung (mit spezifischen Schwächen aber auch Stärken).
Einfacher als selber den gesamten linearen Speicher im Unrealmode zu adressieren geht es nun mal nicht und bei der Verwendung von Speichermanager(ob nun XMS oder EMS) muss man Speicher erst relativ umständlich anfordern. Das kostet nicht nur Zeit, sondern bläht auch den gesamten Code auf, weit mehr als eine kleine Routine die in den Unrealmode schaltet und nur ein einziges Mal am Anfang angesprungen wird.
Es ist einfach unwichtig ob der LOADALL-Befehl je offiziell spezifiziert wurde, er war vorhanden und das genügt um zu zeigen das es für den Unrealmode eine Unterstützung gab die beabsichtigt implementiert wurde
Den LOADALL-Befehl gab es auch auf 286, hatten die etwa auch einen UnReal-Mode?
Mein erster PC war ein 80286er, nur leider kannte ich damals den Unrealmode noch nicht. Ich kann mir aber vorstellen das man damit im Unrealmode möglicherweise 16 MiB linear adressieren kann.
Das es den LOADALL-Befehl gab hat ganz sicher andere Gründe.
Wenn du dir hierbei so sicher bist, dann kanst du uns auch mögliche Gründe dafür nennen, anderfalls bist du dir eben auch nicht sicherer und spekulierst hier ebenso wie ich es jetzt tue.
.... Mir genügt das.
Es gibt Bereiche wo das nicht genügt. Wenn Du z.B. für ein medizinisches Gerät eine Zulassung haben möchtest und der Prüfer sieht das Du irgend ein Bauteil außerhalb der Spezifikation betreibst kannst Du Dir sicher sein das die Zulassung nicht allzu bald erteilt werden wird. Ich hab schon mal ein medizinisches Gerät durch den Zulassungsprozess begleitet (ich hab bei einer der Komponenten den FPGA-Inhalt und Teile des Schaltplans entwickelt) und das ist wahrlich kein Zuckerschlecken.
Das glaube ich dir.
Doch das dieser Zulassungsprozess keine Bauteile erlaubt welche nicht spezifiziert wurden, das sagt über die Zuverlässigkeit nicht spezifizierter Bauteile eigentlich überhaupt gar nichts aus, bzw. nur das sie möglicherweise wegen zu geringer Nachfrage noch keine Spezifikation bekamen. Auch wenn bestimmte Bauteile nicht vermarktet werden bedeutet das ja nicht in jedem Fall, das sie nur schlecht waren.
Eine Verantwortung für die Sachen die ich programmiert haben lehne ich grundsätzlich ab.
Alles darf jeder Anwender in völliger Eigenverantwortung benutzen.
Stell Dir vor Dein Stromanbieter würde das auch so handhaben.
Dieser Vergleich hinkt aber etwas. Ich bin zur Zeit kein Stromanbieter und wenn ich mal einer werden sollte, na dann bekommen alle Menschen von mir kostenlos Strom und am besten gleich vorort völlig dezentral und individuell so viel wie benötigt wird. Die Frage ist wohl wie lange es dauert so etwas zu entwickeln, wenn es keine Spezifikation von den Stromanbietern dafür gibt.
Ich bin mir sicher Du findest Dinge in Deinem Leben wo es Dir doch extrem wichtig ist das die 100% Zuverlässig funktionieren bzw. das die verantwortlichen Entwickler zumindest alles menschenmögliche Unternommen haben um die Zuverlässigkeit zu hoch wie nur irgend möglich zu bringen.
Sorry, aber solange Du so eine Meinung vertrittst hoffe ich wirklich das ich nie auf Dinge von Dir angewiesen bin.
Grüße
Erik
Hilfe nein, ich bin kein Mensch der nach 100 prozentiger Sicherheit sucht. So ein Denken ist mir eher fremd. Für mich ist die Freiheit auch mal nicht so sichere Dinge tun zu dürfen weit aus wichtiger als für einen Kontrollfreak. So einer bin ich ganz bestimmt nicht, auch wenn ich eine gewisse Ordnung in meinem Leben zu schätzen gelernt habe Ich würde mich jetzt auch nicht gerade aufdrängen wollen, so das du in irgendeiner Abhängigkeit auf mich angewiesen wärest.
100% Sicherheit ist für mich eh nur eine fiktive Illusion und dabei sollte man meiner Meinung nach schon abwägen können wie viele solcher Illusionen man verträgt ohne selber in eine Traumwelt abzudriften. Es ist noch gar nicht so lange Zeit her da hat man sich zur Tageschau einen Anzug angezogen und dem Sprecher auch mit einem Guten Abend begrüsst, so als wenn der Tagesschau-Sprecher jeden Zuschauer ganz persöhnlich hören und auch sehen könne. Im Nachherein klinkt das jetzt eher lustig, doch das war es in Wirklichkeit zu keiner Zeit. Damals wurde dann auch der Begriff einer Elektronenstrahl-Marionette gebildet, um so einen fremdgesteuerten Menschen zu beschreiben der unter einem zu grossem Einfluss von vorgesetzten Dingen steht und dabei völlig kritikunfähig sich verhält. Vergleichsweise wie Menschen die unter einer frühkindlichen Suggestiv-Erziehung bis ins hohe Alter an den Folgen davon leiden.
Dirk
-
PS.: die Art wie Du zitiert finde ich persönlich eher unschön, wenn Du schon meinen ganzen Beitrag am Stück zitierst dann kannst es auch ganz bleiben lassen denn er steht ja eh am Stück unmittelbar vor Deinem Beitrag
Deine Art ist für mich als Mitleser auch nicht schön. Beim Verfassen einer Antwort ist es sicherlich leicht den referenzierten Post in zehn bis zwanzig kleine Häppchen zu zerlegen und alle einzeln zu kommentieren. Wenn ich allerdings in einem Thema nur mitlesen will, muss ich immer wieder die Zitate lesen, um die Antwort darauf zu verstehen. Das stört meinen Lesefluss. Mir ist ein in sich zusammenhängender Text mit sorgfältig eingesetzen Zitaten lieber. Das sollte man nicht als Einschränkung (was oder wieviel man kommentieren darf) sehen, sondern als Methode einen Post ansprechend zu strukturien. Alles was sich nicht kohärent einbringen lässt ist vermutlich Offtopic und am falschen Platz.
-
Hallo,
Ich möchte im Verhalten der Schatten-Register eigentlich gar keinen Unterschied feststellen. Ich bin nur überascht davon, das es dabei überhaupt einen Unterschied geben soll zwischen der Laufzeit und einem Reset.
Es kann einen solchen Unterschied geben. Allein schon, weil der Zustand nach einem Reset ein Zustand ist, den du zur Laufzeit nicht herstellen kannst.
Meine Unrealmode-Anwendungen laufen stets zu 100% zuverlässig. Das kann man von Windows und Anwendungen die dort laufen leider nicht immer behaupten, denn dafür ist selbst Windows 7 einfach immer noch zu fehlerhaft, als das man hier von einer hohen Zuverlässigkeit reden kann.
Naja, wenn du die Programme nur für dich produzierst, dann wirst du sie wahrscheinlich in einem begrenzten Biotop ausführen, außerdem bedienst du sie dann prinzipiell so, wie du sie bedienen musst, damit sie das tun, was sie tun sollen. Als Programmierer kennst du das Verhalten, als Anwender nicht unbedingt.
Nicht alles ist direkt schlüssig, nicht alles funktioniert wie erwartet und bisher hat noch keiner vollkommen idiotensichere Software produziert. Von daher halte ich die Aussage "Windows taugt nichts" für nicht ganz angemessen: Es gibt wieviele Anwender? Wieviele haben keine Ahnung und klicken alles an, was nicht bei drei auf den Bäumen ist? Wieviel komische Hardware (auch China-Billig) ist im Einsatz? Da ein Betriebssystem einigermaßen hinzukriegen ist m.M.n. eine ordentliche Leistung.
Nein du hast nicht gesagt das du einen 80386+ kennst bei dem der Unrealmode nicht funktioniert. Ich vermute nun das du keinen einzigen Rechner kennst bei dem der Unrealmode nicht funktioniert. Soweit zu der von dir erwarteten Zuverlässigkeit.
Ich habe ziemlich weit oben ein Errata von Intel zitiert. Solche Bugs werden sicherlich auch weiterhin existieren. Moderne Betriebssysteme nutzen den Unrealmode nicht mehr, DOS hat auf BIOS-Update-CDs eine Berechtigung, dort aber ohne HIMEM. Der Unrealmode wird also überwiegend nicht mehr genutzt, entsprechend behaupte ich, dass Hard- & Firmware nicht mehr in dem Maße darauf getestet werden wie früher. Es gibt in dem Bereich also potentiell mehr Bugs.
Da der Unrealmode außerdem nicht offiziell existiert, rate ich von dessen dauerhafter Nutzung ab.
Mal Spaß wieder beiseite, wir leben in einer Welt in der wir auf Computer nur sehr schwer wieder verzichten können. Da müssen wir uns ganz gewiss auf die Funktionsweise dieser Geräte auch verlassen können.
Richtig, und das geht nur im dokumentierten Umfang. Um mehr geht es hier nicht.
Den LOADALL-Befehl gab es auch auf 286, hatten die etwa auch einen UnReal-Mode?
Mein erster PC war ein 80286er, nur leider kannte ich damals den Unrealmode noch nicht. Ich kann mir aber vorstellen das man damit im Unrealmode möglicherweise 16 MiB linear adressieren kann.
Auf dem 80286 kann es prinzipbedingt keinen Unrealmodus geben, da dessen Register nur 16 Bit breit sind. Damit kannst du sie auch durch Tricks nicht erweitern, sodaß jede lineare Adressierung von Blöcken jenseits der 64K nicht möglich ist.
Doch das dieser Zulassungsprozess keine Bauteile erlaubt welche nicht spezifiziert wurden, das sagt über die Zuverlässigkeit nicht spezifizierter Bauteile eigentlich überhaupt gar nichts aus, bzw. nur das sie möglicherweise wegen zu geringer Nachfrage noch keine Spezifikation bekamen.
Du verwechselst spezifiziert mit zertifiziert.
Bauteile, die nicht spezifiziert sind, kann man nicht zertifizieren, da deren Funktionsweise nicht bekannt (gesichert) ist. Bauteile, die außerhalb ihrer Spzifikation betrieben werden (Unrealmode), werden nicht zertifiziert, da ihre Funktion nicht garantiert ist oder gewährleistet werden kann.
Ein nicht zertifiziertes Bauteil mag trotzdem funktionieren, aber ehrlich gesagt... der Z80 ist als Nachbau des 8080 bugkompatibel - und musste es auch sein, weil sich die Software auf Bugs verlassen hat; das war auf dem 6502 ebenfalls nicht anders.
Möchtest du diese Zeiten zurück haben?
Gruß,
Svenska
-
Hallo,
Ich möchte im Verhalten der Schatten-Register eigentlich gar keinen Unterschied feststellen. Ich bin nur überascht davon, das es dabei überhaupt einen Unterschied geben soll zwischen der Laufzeit und einem Reset.
Es kann einen solchen Unterschied geben. Allein schon, weil der Zustand nach einem Reset ein Zustand ist, den du zur Laufzeit nicht herstellen kannst.
Ich gehe davon aus das dieser Zustand ebenfalls zur Laufzeit herstellbar ist. Nur ohne Dokumentation wird es schwer.
Meine Unrealmode-Anwendungen laufen stets zu 100% zuverlässig. Das kann man von Windows und Anwendungen die dort laufen leider nicht immer behaupten, denn dafür ist selbst Windows 7 einfach immer noch zu fehlerhaft, als das man hier von einer hohen Zuverlässigkeit reden kann.
Naja, wenn du die Programme nur für dich produzierst, dann wirst du sie wahrscheinlich in einem begrenzten Biotop ausführen, außerdem bedienst du sie dann prinzipiell so, wie du sie bedienen musst, damit sie das tun, was sie tun sollen. Als Programmierer kennst du das Verhalten, als Anwender nicht unbedingt.
Eine andere Bedienung als jene welche ich vorgesehen habe ist in meinen Anwendungen gar nicht möglich.
Eine Fehlbedienung kann man doch relativ leicht verhindern in den man z.B. nur solche Tasten direkt vom Port des Tastaturcontrollers auswertet, die auch benötigt werden und vorher wird der IRQ 1 (unter DOS) deaktiviert. Mit der Mouse kann man auch nur auf jene Klickfelder anklicken die ich dafür ausgewählt habe und egal wo man dann klicken kann, es werden immer nur jene Dinge damit ausgeführt und entsprechende Routinen angesprungen die dafür vorgesehen sind. Ein abweichendes Verhalten ist damit völlig ausgeschlossen. Alle Mindestanforderungen des Rechners können vorher überprüft werden und wenn die Mindestanforderungen für die Anwendung nicht erfüllt werden, dann kann mit einer Fehlermeldung die Anwendung beendet werden.
Nicht alles ist direkt schlüssig, nicht alles funktioniert wie erwartet und bisher hat noch keiner vollkommen idiotensichere Software produziert.
Meine Anwendungen funktionieren so wie ich erwarte, wenn die Minimalanforderungen an die Hardware eingehalten werden.
Ob das nun als idiotensicher bezeichnet werden kann, wenn ein Anwender gar keine Eingabe macht, obwohl eine Eingabe erforderlich wird und darauf auch hingewiesen wird, das kann ich nicht beurteilen.
Von daher halte ich die Aussage "Windows taugt nichts" für nicht ganz angemessen: Es gibt wieviele Anwender? Wieviele haben keine Ahnung und klicken alles an, was nicht bei drei auf den Bäumen ist? Wieviel komische Hardware (auch China-Billig) ist im Einsatz? Da ein Betriebssystem einigermaßen hinzukriegen ist m.M.n. eine ordentliche Leistung.
Das Anwendungen unter Windows 7 immer noch den Kernel zum Abstürzen bringen können, ohne das man über den Taskmanager eine abgestürzte Anwendung beenden kann, das ist für mich ein konkreter Hinweis darauf das Windows nichts taugt und bestenfalls nur zum Spielen geeignet ist. Das ist in meinen Augen handwerklicher Pfusch und keinesfalls eine ordentliche Leistung.
Nein du hast nicht gesagt das du einen 80386+ kennst bei dem der Unrealmode nicht funktioniert. Ich vermute nun das du keinen einzigen Rechner kennst bei dem der Unrealmode nicht funktioniert. Soweit zu der von dir erwarteten Zuverlässigkeit.
Ich habe ziemlich weit oben ein Errata von Intel zitiert. Solche Bugs werden sicherlich auch weiterhin existieren. Moderne Betriebssysteme nutzen den Unrealmode nicht mehr, DOS hat auf BIOS-Update-CDs eine Berechtigung, dort aber ohne HIMEM. Der Unrealmode wird also überwiegend nicht mehr genutzt, entsprechend behaupte ich, dass Hard- & Firmware nicht mehr in dem Maße darauf getestet werden wie früher. Es gibt in dem Bereich also potentiell mehr Bugs.
Um ein Bios-Update auf meinem ASUS-Striker-MoBo zu machen braucht man nicht mal zu booten. Ein USB-Stick mit einem dort gespeicherten Bios genügt um innerhalb vom Bios-Setup noch vor dem Booten damit ein Bios-Update zu machen. Um DOS zu nutzen brauche ich keine Art der Berechtigung. Nur weil nicht jede Hardware/Firmware zusammen mit dem Unrealmode getestet wurde, bedeutet das noch lange nicht das es hierbei potentiell mehr Bugs damit zu erwarten sind.
Da der Unrealmode außerdem nicht offiziell existiert, rate ich von dessen dauerhafter Nutzung ab.
Offiziell darf man auch nicht bei roter Ampel die Strasse überqueren, aber das bedeutet nicht das man es nicht kann.
Wir haben hier so eine Ampel die von fast allen Anwohner eher ignoriert wird als beachtet. Es gab hier zwar auch schon einmal ein Unfall mit einem besoffenenn Fussgänger der angefahren wurde, aber das hier jeden Tag eine grosse Anzahl Anwohner die Strasse auch bei roter Ampel überqueren, das zeigt doch sehr deutlich das Regeln nicht überall angewendet werden und es trortzdem möglich ist relativ gefahrlos auch bei roter Ampel die Strasse zu überqueren. Ob das nun offiziell an die grosse Glocke gehängt wird, oder auch nicht, das ist dabei doch eher irrelevant.
Da der Unrealmode auf den meisten Rechner mit 80386+ keine Probleme macht und auch stabil läuft , gibt es keinen Grund ihn nicht zu verwenden.
Mal Spaß wieder beiseite, wir leben in einer Welt in der wir auf Computer nur sehr schwer wieder verzichten können. Da müssen wir uns ganz gewiss auf die Funktionsweise dieser Geräte auch verlassen können.
Richtig, und das geht nur im dokumentierten Umfang. Um mehr geht es hier nicht.
Es werden aber nicht alle Dinge umfangreich dokumentiert, weder Windows ist Opensource, noch die GraKa-Treiber von Nvidia/ATI-AMD.
So verwenden millionen Anwender täglich extrem spärlich dokumentierte Hardware/Software und trotzdem verlassen sich alle auf die Funktionsweise.
Wer also nur gut dokumentierte Dinge benutzen möchte, um sich wirklich auf die Funktionsweise hundertprozent verlassen zu können, der darf ja eigentlich weder Windows noch darin verwendete Treiber vertrauen. Das es trotzdem oft funktioniert haben wir somit nicht einer umfangreichen Dokumentation zu verdanken. Es geht wir wir sehen auch ohne eine konkrete Dokumentation. Der Anspruch nur durch eine umfassende Dokumenation eine stabile Funktionstüchtigkeit zu gewährleisten weicht hierbei doch erheblich von den tatsächlichen Gegebenheiten ab, auch wenn dank einer exelenten Werbemaschine solche gravierenden Unterschiede wohl wenig auffallen, das hier mehr Schein als Sein vorhanden ist.
Den LOADALL-Befehl gab es auch auf 286, hatten die etwa auch einen UnReal-Mode?
Mein erster PC war ein 80286er, nur leider kannte ich damals den Unrealmode noch nicht. Ich kann mir aber vorstellen das man damit im Unrealmode möglicherweise 16 MiB linear adressieren kann.
Auf dem 80286 kann es prinzipbedingt keinen Unrealmodus geben, da dessen Register nur 16 Bit breit sind. Damit kannst du sie auch durch Tricks nicht erweitern, sodaß jede lineare Adressierung von Blöcken jenseits der 64K nicht möglich ist.
Ok.
Doch das dieser Zulassungsprozess keine Bauteile erlaubt welche nicht spezifiziert wurden, das sagt über die Zuverlässigkeit nicht spezifizierter Bauteile eigentlich überhaupt gar nichts aus, bzw. nur das sie möglicherweise wegen zu geringer Nachfrage noch keine Spezifikation bekamen.
Du verwechselst spezifiziert mit zertifiziert.
Bauteile, die nicht spezifiziert sind, kann man nicht zertifizieren, da deren Funktionsweise nicht bekannt (gesichert) ist. Bauteile, die außerhalb ihrer Spzifikation betrieben werden (Unrealmode), werden nicht zertifiziert, da ihre Funktion nicht garantiert ist oder gewährleistet werden kann.
Ein nicht zertifiziertes Bauteil mag trotzdem funktionieren, aber ehrlich gesagt... der Z80 ist als Nachbau des 8080 bugkompatibel - und musste es auch sein, weil sich die Software auf Bugs verlassen hat; das war auf dem 6502 ebenfalls nicht anders.
Möchtest du diese Zeiten zurück haben?
Gruß,
Svenska
Nö.
Dirk
-
Hallo,
Von daher halte ich die Aussage "Windows taugt nichts" für nicht ganz angemessen: Es gibt wieviele Anwender? Wieviele haben keine Ahnung und klicken alles an, was nicht bei drei auf den Bäumen ist? Wieviel komische Hardware (auch China-Billig) ist im Einsatz? Da ein Betriebssystem einigermaßen hinzukriegen ist m.M.n. eine ordentliche Leistung.
Full ACK!
Ich bin selber absolut kein Freund von Windows aber das schmälert in keinster Weise die Leistung ein OS zu bauen das milliardenfach täglich benutzt wird und dabei meistens recht gut funktioniert. Wenn Windows wirklich so instabil wäre wie immer alle jammern dann würde es auch kaum einer benutzen.
Ich gehe davon aus das dieser Zustand ebenfalls zur Laufzeit herstellbar ist. Nur ohne Dokumentation wird es schwer.
Ich hab selber schon ein paar mal Schaltungen entwickelt die durchs Reset in einen Zustand gebracht wurden der zur Laufzeit nicht erreichbar ist. Das ist ein absolut übliches Vorgehen in der Entwicklung von Schaltungen. Man kann in Hardware durchaus eine State-Maschine entwickeln die durchs Reset in einen State gebracht wird der später nie wieder erreichbar ist (wenn er denn einmal verlassen wurde).
Ich hab mir mal die ersten 2 Google-Treffer zu "x86 loadall" angesehen:
http://www.rcollins.org/articles/loadall/tspec_a3_doc.html (http://www.rcollins.org/articles/loadall/tspec_a3_doc.html): da steht z.B.
According to Intel, each time the CPU loads a segment register in real mode, the base address is 16 times the segment value, while the access rights and size limit attributes are given fixed, "real-mode compatible" values. This is not true. In fact, only the CS descriptor cache access rights get loaded with fixed values each time the segment register is 1oaded - and even then only when a far jump is encountered. Loading any other segment register in real mode does not change the access rights or the segment size limit attributes stored in the descriptor cache registers. For these segments, the access rights and segment size limit attributes are honored from any previous setting.
So wie es der erste Satz meint kenne ich die Funktionsweise der Schattenregister auch aus den Intel-Manuals, daraus lässt sich IMHO schlussfolgern das der UnReal-Mode eigentlich ein Bug ist. Normalerweise wird bei einem Schreibzugriff auf eines der Segment-Register immer auch das komplette zugehörige Schattenregister neu geladen. Damit da nur im Real-Mode und nur für einen Teil der Schattenregister eine Ausname gemacht wird sind sicher ein paar Transistoren extra notwendig, wenn die morgen weg gelassen werden wäre die CPU immer noch so funktionsfähig wie laut Datenblatt zugesichert aber der UnReal-Mode würde nur noch so lange funktionieren bis das betreffende Segment-Register neu geladen wird (deswegen haben wir uns damals bewusst für FS und GS entschieden, in der Hoffnung das die möglichst selten von irgendwelchem anderen Code überschrieben werden und somit den UnReal-Mode möglichst lange ganz bleibt).
http://en.wikipedia.org/wiki/LOADALL (http://en.wikipedia.org/wiki/LOADALL): da stehen ein paar Beispiele wie der LOADALL-Befehl benutzt wurde, aber das sind im wesentlichen Beispiele für den 286 (inklusive Deiner HIMEM.SYS), auf dem 286 macht dieser Befehl auch richtig Sinn da es dort keinen offiziellen Weg gab um aus dem Protected-Mode wieder zurück in den Real-Mode zu kommen. Für den 286 hat Intel wohl auch mal eine Dokumentation für den LOADALL-Befehl verteilt damit der auch richtig benutzt werden kann. Ich vermute mal Intel hat den LOADALL im 386 vorsichtshalber neu aufgelegt weil die sich nicht sicher waren ob es dazu noch Bedarf gibt, schließlich hatte der 386 ja einen Virtual-8086-Mode und konnte auch wieder offiziell den Protected-Mode verlassen so das LOADALL eigentlich nicht mehr benötigt wird. Auch inoffiziell gab es von Intel nie eine Dokumentation zu dem 386-LOADALL-Befehl (Microsoft hat unter der Hand vermutlich trotzdem ein paar Infos bekommen und zwischen AMD und Intel gibt es schon seit vielen Jahren Patent-Austausch-Abkommen die sicher auch solche internen Infos beinhalten).
Ob der UnReal-Mode wirklich beabsichtigt war (und falls ja ob das auch vom Management abgesegnet war) oder ob der eher aus Zufall entstanden ist werden wir wohl nie erfahren. Fakt ist das dafür zusätzliche Transistoren erforderlich sind und es niemand garantiert das die nicht doch mal irgendwann raus fliegen, würde ja auch niemand vermissen.
Eine andere Bedienung als jene welche ich vorgesehen habe ist in meinen Anwendungen gar nicht möglich.
Das müssen aber sehr simple Programme sein, oder?
Sorry, aber bei Programmen in der Größenordnung eines kompletten OS (wie z.B. Windows aber auch Linux) ist eine Fehlbedienung grundsätzlich nicht auszuschließen. Selbst bei kleinen Mini-OSen, wie z.B. tyndur, gibt es sicher unzählige Möglichkeiten diese fehl zu bedienen. Solange der Computer nicht erahnen kann was der User wirklich will kann der User auch immer den Computer mit falschen Informationen füttern.
Nur weil nicht jede Hardware/Firmware zusammen mit dem Unrealmode getestet wurde, bedeutet das noch lange nicht das es hierbei potentiell mehr Bugs damit zu erwarten sind.
Doch, genau das bedeutet das! Wenn man Bugs mit möglichst hoher Wahrscheinlichkeit ausschließen möchte muss man viel Testen und wenn man bestimmte Aspekte nicht oder nur wenig testet dann ist einfach die Wahrscheinlichkeit für übersehene Bugs höher. Jeder erfahrene Entwickler, egal ob Software oder Hardware oder irgendwas anderes, kennt diesen Zusammenhang aus seiner real erlebten Praxis.
Offiziell darf man auch nicht bei roter Ampel die Strasse überqueren, aber das bedeutet nicht das man es nicht kann.
Richtig, das bedeutet auch nicht das sofort ein Unfall passiert wenn man es doch tut. Aber das bedeutet das dieses Verhalten auf Grund von rationalen Gründen unerwünscht ist und auch bestraft wird wenn man sich erwischen lässt. Für den UnReal-Mode wird man zwar nicht bestraft aber die Gründe die gegen seine Benutzung sprechen sind im wesentlichen die selben.
noch die GraKa-Treiber von Nvidia/ATI-AMD.
Was denkst Du warum Nvidia und AMD für ihre teureren (besseren) GraKas extra zertifizierte Treiber anbieten? Diese zertifizierten Treiber enhalten auch nicht unbedingt weniger Bugs aber sie wurden zumindest deutlich gründlicher getestet und Nvidia bzw. AMD sichern zu das bei gefundenen Fehler so schnell als möglich ein Fix geliefert wird (und die rufen dafür die entsprechenden Programmierer auch mal zu einer Nachtschicht an den Arbeitsplatz wenn der Kunde wichtig genug ist).
Meine Kenntnisse über Pointer-Arithmetik in C scheinen wohl doch ein paar Lücken aufzuweisen aber meine Kenntnisse bei der Schuld-Pointer-Arithmetik sind recht gut, ich hab es sogar mal geschafft das der Schuld-Pointer auf jemand anderes zeigt obwohl ich was verbockt hab. Genau deswegen gibt es in der Welt des Geldes so erquickende Gesetze wie die der Produkt-Haftung und wer in diesem Feld dauerhaft bestehen will muss sich mit der Schuld-Pointer-Arithmetik sehr gut auskennen. Eine wichtige Regel sagt das man immer jemanden benötigt auf den man diesen Pointer zeigen lassen kann und das geht nur wenn man sich streng an die "zugesicherten Eigenschaften" hält wenn man fremde Komponenten einsetzt. Wenn ich ein Bauteil einsetze dessen Funktionsfähigkeit nur von 0°C bis +70°C zugesichert wird und das Produkt wird aber bei anderen Temperaturen eingesetzt dann bleibt der Schuld-Pointer auf mir stehen egal ob dieses Bauteil nun wirklich die Ursache für einen Ausfall war oder nicht. Sachgutachter von Versicherungen finden solche Dinge garantiert immer.
Grüße
Erik
-
Hallo,
Von daher halte ich die Aussage "Windows taugt nichts" für nicht ganz angemessen: Es gibt wieviele Anwender? Wieviele haben keine Ahnung und klicken alles an, was nicht bei drei auf den Bäumen ist? Wieviel komische Hardware (auch China-Billig) ist im Einsatz? Da ein Betriebssystem einigermaßen hinzukriegen ist m.M.n. eine ordentliche Leistung.
Full ACK!
Ich bin selber absolut kein Freund von Windows aber das schmälert in keinster Weise die Leistung ein OS zu bauen das milliardenfach täglich benutzt wird und dabei meistens recht gut funktioniert. Wenn Windows wirklich so instabil wäre wie immer alle jammern dann würde es auch kaum einer benutzen.
Windows 7 ist so instabil, das eine Anwendung immer noch den Kernel zum Absturz bringen kann und trotzdem nutzen Windows sehr viele Anwender, wohl auch weil es für diverse Anwendungen inklusive Spiele keine Alternative für Windows gibt und millardenschwere Werbekampagnen eine Wirkung haben, so das man gestützt dadurch auch Produkte verkaufen kann, die sonst kaum einer kaufen würde und durch diese Manipulation bei der Kaufentscheidung durch eine ausgeklügelte Werbestrategie selbst einem König unsichtbare Kleider verkauft werden können. Die Entwicklung ist seit Till Eulenspiegel nicht stehen geblieben und der hat es ja allen gezeigt wie einfache es ist die Ahnungslosigkeit einfältiger Menschen auszuloten und mit immer absurderen Spielchen sie alle zu tolpatschigen Narren zu machen. Vergleichsweise läuft die Werbung ebenso nur nicht ganz so offensichtlich und dabei geht es schon lange nicht mehr darum nur ein Produkt bekannt zu machen, sondern es wird immer mit fantastischen Fähigkeiten präsentiert, wobei wir doch nur zu gut wissen, das dabei sehr viel heisse Luft abgelassen wird und hier nur ein erdachtes Image aufpoliert wird, den das Produkt niemals hatte und auch nie haben wird.
Ich gehe davon aus das dieser Zustand ebenfalls zur Laufzeit herstellbar ist. Nur ohne Dokumentation wird es schwer.
Ich hab selber schon ein paar mal Schaltungen entwickelt die durchs Reset in einen Zustand gebracht wurden der zur Laufzeit nicht erreichbar ist. Das ist ein absolut übliches Vorgehen in der Entwicklung von Schaltungen. Man kann in Hardware durchaus eine State-Maschine entwickeln die durchs Reset in einen State gebracht wird der später nie wieder erreichbar ist (wenn er denn einmal verlassen wurde).
Ok, möglich ist das auch beim x86er.
Ich hab mir mal die ersten 2 Google-Treffer zu "x86 loadall" angesehen:
http://www.rcollins.org/articles/loadall/tspec_a3_doc.html (http://www.rcollins.org/articles/loadall/tspec_a3_doc.html): da steht z.B.
According to Intel, each time the CPU loads a segment register in real mode, the base address is 16 times the segment value, while the access rights and size limit attributes are given fixed, "real-mode compatible" values. This is not true. In fact, only the CS descriptor cache access rights get loaded with fixed values each time the segment register is 1oaded - and even then only when a far jump is encountered. Loading any other segment register in real mode does not change the access rights or the segment size limit attributes stored in the descriptor cache registers. For these segments, the access rights and segment size limit attributes are honored from any previous setting.
So wie es der erste Satz meint kenne ich die Funktionsweise der Schattenregister auch aus den Intel-Manuals, daraus lässt sich IMHO schlussfolgern das der UnReal-Mode eigentlich ein Bug ist.
Ich habe es noch niemals erlebt das ein Laden eines Segmentregisters im RM die Einträge im Schattenregister überschreibt. Wie kann man denn daraus schlussfolgern das es ein Bug ist wenn Intel hierbei Fehlinformationen verbreitet?
Normalerweise wird bei einem Schreibzugriff auf eines der Segment-Register immer auch das komplette zugehörige Schattenregister neu geladen.
Offensichtlich ist das nicht so und ich kenne auch keinen einzigen 80386+ bei dem das so ist.
Damit da nur im Real-Mode und nur für einen Teil der Schattenregister eine Ausname gemacht wird sind sicher ein paar Transistoren extra notwendig,
Könnte es nicht auch anders herum sein, weil im RM beim Laden der Segmentregister die Schattenregister unberührt bleiben fehlen ein paar Transistoren?
wenn die morgen weg gelassen werden wäre die CPU immer noch so funktionsfähig wie laut Datenblatt zugesichert aber der UnReal-Mode würde nur noch so lange funktionieren bis das betreffende Segment-Register neu geladen wird
Vieleicht müssten auch damit die CPU laut Datenblatt funktioniert extra Transitoren eingebaut werden die jetzt überall fehlen und so den Unrrealmofde ermöglichen?
(deswegen haben wir uns damals bewusst für FS und GS entschieden, in der Hoffnung das die möglichst selten von irgendwelchem anderen Code überschrieben werden und somit den UnReal-Mode möglichst lange ganz bleibt).
Ich erweitere für den Unrealmode gewöhnlich nur "DS", da man für FS und GS jeweils ein zusätzliches Segment overide Prefix benötigt, welches man bei Speicherzugriffen über DS nicht benötigt.
http://en.wikipedia.org/wiki/LOADALL (http://en.wikipedia.org/wiki/LOADALL): da stehen ein paar Beispiele wie der LOADALL-Befehl benutzt wurde, aber das sind im wesentlichen Beispiele für den 286 (inklusive Deiner HIMEM.SYS), auf dem 286 macht dieser Befehl auch richtig Sinn da es dort keinen offiziellen Weg gab um aus dem Protected-Mode wieder zurück in den Real-Mode zu kommen.
Es gab aber den inoffiziellen Weg der vom PM in den RM zurückschaltet.
Für den 286 hat Intel wohl auch mal eine Dokumentation für den LOADALL-Befehl verteilt damit der auch richtig benutzt werden kann. Ich vermute mal Intel hat den LOADALL im 386 vorsichtshalber neu aufgelegt weil die sich nicht sicher waren ob es dazu noch Bedarf gibt, schließlich hatte der 386 ja einen Virtual-8086-Mode und konnte auch wieder offiziell den Protected-Mode verlassen so das LOADALL eigentlich nicht mehr benötigt wird. Auch inoffiziell gab es von Intel nie eine Dokumentation zu dem 386-LOADALL-Befehl (Microsoft hat unter der Hand vermutlich trotzdem ein paar Infos bekommen und zwischen AMD und Intel gibt es schon seit vielen Jahren Patent-Austausch-Abkommen die sicher auch solche internen Infos beinhalten).
Das wirkt schon lustig wie dort mit offiziellen und inoffiziellen Dingen herumschlawienert wird. Wenn man so etwas glauben möchte, bitte schön, Ich halte mich lieber an die Dinge die ich selber ausprobiert habe, egal ob es offiziel bekantgegeben wird, oder auch nicht.
Ob der UnReal-Mode wirklich beabsichtigt war (und falls ja ob das auch vom Management abgesegnet war) oder ob der eher aus Zufall entstanden ist werden wir wohl nie erfahren. Fakt ist das dafür zusätzliche Transistoren erforderlich sind und es niemand garantiert das die nicht doch mal irgendwann raus fliegen, würde ja auch niemand vermissen.
Bis du dir sicher das für den Unrealmode keine Transitoren weggelassen wurden damit die Schattenregister im RM nicht durch das Laden eines Segmentregisters überschreiben werden?
Eine andere Bedienung als jene welche ich vorgesehen habe ist in meinen Anwendungen gar nicht möglich.
Das müssen aber sehr simple Programme sein, oder?
Na klar.
Sorry, aber bei Programmen in der Größenordnung eines kompletten OS (wie z.B. Windows aber auch Linux) ist eine Fehlbedienung grundsätzlich nicht auszuschließen.
Es ist ganz gewiss handwerklich möglich nur solche Funktionen in eine Anwendung zu integrieren die man nicht fehlbedienen kann.
Am einfachsten kann man eine Fehlbedienung ausschliessen wenn man keine Closed-Source-Anwendung und kein Windows benutzt.
Selbst bei kleinen Mini-OSen, wie z.B. tyndur, gibt es sicher unzählige Möglichkeiten diese fehl zu bedienen. Solange der Computer nicht erahnen kann was der User wirklich will kann der User auch immer den Computer mit falschen Informationen füttern.
Ich kenne den Funktionsumfang von tyndur noch gar nicht, so kann ich darüber auch nichts sagen. Nun müsste man eine Fehlbedienung auch erst mal genauer definieren, um einzugrenzen was damit bei welcher Funktion gemeint ist.
Nur weil nicht jede Hardware/Firmware zusammen mit dem Unrealmode getestet wurde, bedeutet das noch lange nicht das es hierbei potentiell mehr Bugs damit zu erwarten sind.
Doch, genau das bedeutet das!
Solche rein mutmaßlichen Bugs konnte ich aber bisher nicht festellen. Mit dieser Definition stimmt also offenbar etwas nicht.
Wenn man Bugs mit möglichst hoher Wahrscheinlichkeit ausschließen möchte muss man viel Testen und wenn man bestimmte Aspekte nicht oder nur wenig testet dann ist einfach die Wahrscheinlichkeit für übersehene Bugs höher.
Nein, denn nur wenn tatsächlich Bugs bekannt werden ist die Wahrscheinlichkeit höher das man eine Hardware verwendet die beim Unrealmode nicht zuverlässig arbeitet. Wenn man nichts testet, dann ist die Warscheinlichkeit eher unbestimmbar. Nur weil etwas unbekannt ist kann man davon eben nicht ableiten das ein bestimmtes Verhalten hierbei vorliegt.
Jeder erfahrene Entwickler, egal ob Software oder Hardware oder irgendwas anderes, kennt diesen Zusammenhang aus seiner real erlebten Praxis.
Testen tut man deswegen weil das Resultat noch ungewiss ist, denn wenn das Resultat schon vorliegt, warum sollte man denn überhaupt noch testen?
Für mich sind das nur rein vermutete Bugs die im weiten Umfeld noch nicht angetroffen wurden, von wenigen Einzelfällen mal abgesehen.
Offiziell darf man auch nicht bei roter Ampel die Strasse überqueren, aber das bedeutet nicht das man es nicht kann.
Richtig, das bedeutet auch nicht das sofort ein Unfall passiert wenn man es doch tut.
Aber das bedeutet das dieses Verhalten auf Grund von rationalen Gründen unerwünscht ist und auch bestraft wird wenn man sich erwischen lässt.
Über den Sinn von Verkehrsregeln besteht also kein Zweifel.
Für den UnReal-Mode wird man zwar nicht bestraft aber die Gründe die gegen seine Benutzung sprechen sind im wesentlichen die selben.
Hier muss ich widersprechen, Verkehrsunfälle bzw. ein Fehlverhalten durch die Verwendung des Unrealmode sind nach meiner Meinung nach eine eher seltene Ausnahme die nur durch wenige Hardware und deren Bios verursacht wird. Auch gibt es kaum einen triftigen Grund den Unrealmode nicht zu verwenden. Denn anders als im Strassenverkehr und/oder bei Windows gibt es dort keine Kreuzung wo sich zwei Anwendungen in die Quere kommen können und hier gibt es auch keine roten Ampeln wie bei Windows und man bewegt sich auf der gesamten Strasse völlig alleine.
noch die GraKa-Treiber von Nvidia/ATI-AMD.
Was denkst Du warum Nvidia und AMD für ihre teureren (besseren) GraKas extra zertifizierte Treiber anbieten? Diese zertifizierten Treiber enhalten auch nicht unbedingt weniger Bugs aber sie wurden zumindest deutlich gründlicher getestet und Nvidia bzw. AMD sichern zu das bei gefundenen Fehler so schnell als möglich ein Fix geliefert wird (und die rufen dafür die entsprechenden Programmierer auch mal zu einer Nachtschicht an den Arbeitsplatz wenn der Kunde wichtig genug ist).
Weil hier trotz Zertifikat weniger auf Stabilität gesetzt wird und man eine Produktpallette nach der anderen auf den Markt werfen möchte, darum sind solche Bugs überhaupt erst möglich. Ohne die Last des Wettbewerbs wären langelebigere Produkte häufiger anzutreffen die man auch in aller Ruhe noch eher bugfrei bekomen könnte noch bevor sie verbreitet werden.
Meine Kenntnisse über Pointer-Arithmetik in C scheinen wohl doch ein paar Lücken aufzuweisen aber meine Kenntnisse bei der Schuld-Pointer-Arithmetik sind recht gut, ich hab es sogar mal geschafft das der Schuld-Pointer auf jemand anderes zeigt obwohl ich was verbockt hab. Genau deswegen gibt es in der Welt des Geldes so erquickende Gesetze wie die der Produkt-Haftung und wer in diesem Feld dauerhaft bestehen will muss sich mit der Schuld-Pointer-Arithmetik sehr gut auskennen. Eine wichtige Regel sagt das man immer jemanden benötigt auf den man diesen Pointer zeigen lassen kann und das geht nur wenn man sich streng an die "zugesicherten Eigenschaften" hält wenn man fremde Komponenten einsetzt. Wenn ich ein Bauteil einsetze dessen Funktionsfähigkeit nur von 0°C bis +70°C zugesichert wird und das Produkt wird aber bei anderen Temperaturen eingesetzt dann bleibt der Schuld-Pointer auf mir stehen egal ob dieses Bauteil nun wirklich die Ursache für einen Ausfall war oder nicht. Sachgutachter von Versicherungen finden solche Dinge garantiert immer.
Grüße
Erik
Ok danke für die Info, aber solche Probleme interessieren mich als privaten Programmieren eigentlich sehr wenig und sie sollten auch keinen privaten Programmierer davon abhalten können den Unrealmode zu verwenden. Hierbei geht es nicht darum etwas zu vermarkten, sondern darum eine weit verbreitete Möglichkeit zu verwenden die neben dem RM es erlaubt den gesamten 4 GiB Adressraum einer 32 Bit-x86-CPU zu adressieren, wobei alle gewöhnlichen Bios-Routinen die für den RM entwickelt wurden auch weiterhin benutzbar bleiben. So ist es für eine Anwendung nicht zwingend nötig den gesamten freien Speicher nur über den PM, oder einen Memmorymanager zu benutzen.
Dirk
-
Ohne einen Flamewar zu starten ist deine Aussage einfach falsch: Eine Anwendung kann den Kernel nicht mehr zum Absturz bringen (ich habe jetzt keinen Beweis dafür, du aber für deine Aussage ja auch nicht). Windows 7 ist ein stabiles System (und ich bin von arbeitswegen tagtäglicher Windows-User und auch bei Kunden, denen wir Windows 7 anbieten und installieren läuft es hervorragend), ich habe bisher keinerlei Probleme mit Windows 7 gehabt, im Gegenteil: Subjektiv läuft z.B. mein Laptop schneller als mit Windows XP.
Dennoch bevorzuge ich gerade im privaten und Programmierer-Umfeld Linux, aber nicht, weil Windows 7 instabil ist, sondern weil das Entwickeln eines OS unter Windows einfach zu Umständlich ist und unter Linux einem keine Fesseln gesetzt werden.
-
Hallo,
Wie kann man denn daraus schlussfolgern das es ein Bug ist wenn Intel hierbei Fehlinformationen verbreitet?
Was Intel verbreitet können niemals Fehlinformationen sein, sondern das sind die zugesicherten Eigenschaften. Wenn ich einen Taschenrechner verkaufe und ins Handbuch schreibe das dort 1+1=3 ist dann ist das die offizielle und zugesicherte Funktionsweise dieses Taschenrechners (dass das seinen Nutzwert einschränkt ist jetzt mal egal) und wenn er doch normal 1+1=2 rechnet dann ist das eineindeutig ein Bug.
Ein Bug ist alles das wo das reale Verhalten vom spezifizierten Verhalten abweicht! Egal wie idiotisch die Spezifikation auch sein mag. In der Welt des Geldes werden Produkte nach Spezifikation verkauft und nicht nach dem äußeren Anschein (oder irgendwie beobachteten Verhalten). Für das was in der Spezifikation drin steht muss der Hersteller auch haften (also der Schuld-Pointer zeigt auf ihn) wenn sich ein Kunde beschwert.
Normalerweise wird bei einem Schreibzugriff auf eines der Segment-Register immer auch das komplette zugehörige Schattenregister neu geladen.
Offensichtlich ist das nicht so und ich kenne auch keinen einzigen 80386+ bei dem das so ist.
Doch, im Protected-Mode und im Virtual-8086-Mode ist das genau so. Laut Spezifikation sollte das auch im Real-Mode so sein (nicht nur für CS sondern für alle Segmente) aber ist es nicht was eben den UnReal-Mode ermöglicht.
Könnte es nicht auch anders herum sein, weil im RM beim Laden der Segmentregister die Schattenregister unberührt bleiben fehlen ein paar Transistoren?
Das halte ich für extrem unwahrscheinlich. Für spezielle Extra-Ausnahmen benötigt man in den Chips üblicherweise auch spezielle Extra-Transistoren.
Ich erweitere für den Unrealmode gewöhnlich nur "DS", da man für FS und GS jeweils ein zusätzliches Segment overide Prefix benötigt, welches man bei Speicherzugriffen über DS nicht benötigt.
Aber DS wird von normalem Real-Mode-Code sehr häufig mit einem neuen Wert geladen so das sehr häufig das Risiko besteht das die Schattenregister von DS nicht mehr das gewünschte 4 GB-Limit enthalten (falls sich die CPU an die Spezifikation hält, wovon wir damals ausgegangen sind).
Es gab aber den inoffiziellen Weg der vom PM in den RM zurückschaltet.
Ja, über den harten Reset was unheimlich performant war (wimre auch eine Idee von IBM).
Ich halte mich lieber an die Dinge die ich selber ausprobiert habe, egal ob es offiziel bekantgegeben wird, oder auch nicht.
Was Du in Deinem privaten Hobby-Keller machst ist allein Deine private Angelegenheit (genau so wie in Deinem privaten Garten nicht auch automatisch die StVO gild), aber was in der großen weiten Welt passiert hängt von vielen Regeln und Gesetzen ab und wer da nicht unter die Räder kommen will tut gut daran sich an diese Spielregeln zu halten.
Es ist ganz gewiss handwerklich möglich nur solche Funktionen in eine Anwendung zu integrieren die man nicht fehlbedienen kann.
Am einfachsten kann man eine Fehlbedienung ausschliessen wenn man keine Closed-Source-Anwendung und kein Windows benutzt.
Ich bin mir ganz sicher das Du mit diesem Wissen für Projekte wie KDE, GNome u.ä. (und sicher auch bei Microsoft) ein sehr gefragter Mann bist. Die Genialität mit der absolute DAUs eine Software fehl bedienen können ist quasi unbegrenzt, die Dinge an die ein Programmierer alle denkt sind auf jeden Fall endlich.
Solche rein mutmaßlichen Bugs konnte ich aber bisher nicht festellen. Mit dieser Definition stimmt also offenbar etwas nicht.
Nur weil Du eine Definition nicht nachvollziehen kannst (im krassen Gegensatz zu allen anderen) heißt das nicht das diese Definition falsch ist.
Wenn man nichts testet, dann ist die Warscheinlichkeit eher unbestimmbar. Nur weil etwas unbekannt ist kann man davon eben nicht ableiten das ein bestimmtes Verhalten hierbei vorliegt.
Aber für Deine Programme möchtest Du doch kein unbekanntes Verhalten sondern ein bekannt funktionierendes, oder? Also kannst Du Dich nicht auf Dinge verlassen deren Funktion bzw. Funktionssicherheit nicht bekannt ist. Genau das ist eine der Spielregeln in der großen weiten Welt.
aber solche Probleme interessieren mich als privaten Programmieren eigentlich sehr wenig und sie sollten auch keinen privaten Programmierer davon abhalten können ....
Wie ich bereits schrieb, in Deinem privaten Hobby-Keller ist das völlig in Ordnung aber wenn Du mit dem was Du tust irgendwann mal Geld verdienen möchtest (und sei es nur als angestellter Lohnsklave) solltest Du Deine Einstellung noch mal überdenken.
Grüße
Erik
-
Hallo,
Windows 7 ist so instabil, das eine Anwendung immer noch den Kernel zum Absturz bringen kann
Geht unter Linux auch. Nennt sich Kernel-Bug und ist durch Updates behebbar.
Stützt du diese Aussage auf Faktenwissen, eigene Erfahrung oder Hörensagen?
wohl auch weil es für diverse Anwendungen inklusive Spiele keine Alternative für Windows gibt
Das hat Gründe, also kann Windows so schlecht nicht sein.
Es gab aber den inoffiziellen Weg der vom PM in den RM zurückschaltet.
Nein, der Weg über Reset oder Triple-Fault zurück in den RM war offiziell bekannt und dokumentiert. Nur die kreative Nutzung war nicht vorgesehen, aber es gibt in Spezifikationen keine Vorschriften, wie man gewisse Effekte zu nutzen hat... die Effekte sind aber beschrieben und damit verlässlich.
Es ist ganz gewiss handwerklich möglich nur solche Funktionen in eine Anwendung zu integrieren die man nicht fehlbedienen kann.
Beispielsweise "Datei löschen" darf in keine Anwendung integriert werden, denn man könnte ja die falsche Datei löschen, weil man das Programm falsch bedient. Aha.
Am einfachsten kann man eine Fehlbedienung ausschliessen wenn man keine Closed-Source-Anwendung und kein Windows benutzt.
Das ist Blödsinn.
Schonmal unter Linux in Shellscript programmiert und dabei eine Klammer falsch gesetzt? Das ist eine Fehlbedienung der Shell. Wenn man mit so Dingen wie "find -name ... | xargs rm -rf ..." hantiert, kann Fehlbedienung zu schwerwiegenden Konsequenzen führen. Das geht unter Linux sogar ganz besonders gut, da es kein "Sind Sie sicher?" gibt.
Solche rein mutmaßlichen Bugs konnte ich aber bisher nicht festellen. Mit dieser Definition stimmt also offenbar etwas nicht.
Ich habe dir oben einen solchen nicht mutmaßlichen Bug präsentiert. Der existierte. Mit deiner Definition stimmt also offenbar etwas nicht. "Hab ich noch nie gesehen" heißt nicht, dass es das nicht gibt!
Nur weil etwas unbekannt ist kann man davon eben nicht ableiten das ein bestimmtes Verhalten hierbei vorliegt.
Tust du aber. Der Unrealmode ist unbekannt (weil nicht offiziell dokumentiert) und du behauptest, dass es ihn gibt.
Du extrapolierst von den dir bekannten Prozessoren in wenigen, bei dir vorhandenen Umgebungen (Rechnern) auf sämtliche kompatible Prozessoren, inklusive aller Revisionen, inklusive aller Boot-ROMs, BIOS- und Firmware-Versionen dieser Welt. Und zwar ohne jeden Hintergrund. Und: Ohne jeden Beweis.
Testen tut man deswegen weil das Resultat noch ungewiss ist, denn wenn das Resultat schon vorliegt, warum sollte man denn überhaupt noch testen?
Das ist falsch. Man testet, ob das Resultat, was man kennt mit dem Resultat übereinstimmt, was man gern hätte. Durch Spezifizierung ist das Resultat bekannt, aber der reale Baustein muss dieses Resultat auch liefern und das wird getestet.
Für mich sind das nur rein vermutete Bugs die im weiten Umfeld noch nicht angetroffen wurden, von wenigen Einzelfällen mal abgesehen.
Dumm nur, wenn dein Rechner mal so ein Einzelfall ist, auf dem etwas nicht funktioniert und dir der Hersteller dann sagt "die große Masse ist aber korrekt, da haben Sie nunmal Pech gehabt".
Hier muss ich widersprechen, Verkehrsunfälle bzw. ein Fehlverhalten durch die Verwendung des Unrealmode sind nach meiner Meinung nach eine eher seltene Ausnahme die nur durch wenige Hardware und deren Bios verursacht wird.
Dann können wir die StVO abschaffen, denn Unfälle passieren nur selten und daher brauchen wir keine Regeln mehr. Oder meinst du was völlig anderes?
Auch gibt es kaum einen triftigen Grund den Unrealmode nicht zu verwenden. Denn anders als im Strassenverkehr und/oder bei Windows gibt es dort keine Kreuzung wo sich zwei Anwendungen in die Quere kommen können und hier gibt es auch keine roten Ampeln wie bei Windows und man bewegt sich auf der gesamten Strasse völlig alleine.
Och, mir fallen da schon Dinge ein, die dir in den Unrealmode pfuschen können. Von komischen Dingen wie dem SMM über Option-ROMs und Firmwares bis hin zu DOS-TSRs im Hintergrund gibt es da ganz viele Ansatzpunkte...
Ok danke für die Info, aber solche Probleme interessieren mich als privaten Programmieren eigentlich sehr wenig und sie sollten auch keinen privaten Programmierer davon abhalten können den Unrealmode zu verwenden.
Ich habe niemandem verboten, den Unrealmode zu verwenden. So wie auf deinem Privateigentum die StVO nicht gilt, kannst du im Hinterzimmer tun und lassen, was du willst.
Um ein Bios-Update auf meinem ASUS-Striker-MoBo zu machen braucht man nicht mal zu booten.
Das ist die Ausnahme. Ich habe schon genug Rechner mit BIOS-Updates versehen, um das zu wissen.
Richtig, und das geht nur im dokumentierten Umfang. Um mehr geht es hier nicht.
Es werden aber nicht alle Dinge umfangreich dokumentiert, weder Windows ist Opensource, noch die GraKa-Treiber von Nvidia/ATI-AMD.
Und?
Das Verhalten von Windows ist dokumentiert und spezifiziert, nennt man z.B. WinAPI. Um Windows zu benutzen, brauchst du keinen Quellcode. Das Verhalten von Grafikkarten ist übrigens auch dokumentiert (DirectX, OpenGL), sonst würden Spiele nicht funktionieren.
Die Schnittstelle zwischen Grafikkarte und Treiber, die Schnittstellen zwischen Hardware und Windows sind ebenfalls dokumentiert. Nur bekommst du diese Dokumente nicht.
So verwenden millionen Anwender täglich extrem spärlich dokumentierte Hardware/Software und trotzdem verlassen sich alle auf die Funktionsweise.
Sowohl Hard- als auch Software sind dokumentiert. Sämtliche externen Schnittstellen sind dokumentiert. Die Funktionsweise ist somit garantiert, was der Unrealmode übrigens nicht ist.
Die Interna spielen keine Rolle, die können von einer Revision zur nächsten auch wieder völlig anders aussehen und sind darum nicht verlässlich.
Wer also nur gut dokumentierte Dinge benutzen möchte, um sich wirklich auf die Funktionsweise hundertprozent verlassen zu können, der darf ja eigentlich weder Windows noch darin verwendete Treiber vertrauen.
Blödsinn. Windows garantiert mir die Funktionsweise der WinAPI. Treiber garantieren mir die Funktionsweise der dort verwendeten API (z.B. Netzwerk- oder WLAN-Zeug). Funktionieren die nicht, ist der Hersteller in der Pflicht.
Das es trotzdem oft funktioniert haben wir somit nicht einer umfangreichen Dokumentation zu verdanken. Es geht wir wir sehen auch ohne eine konkrete Dokumentation.
Falsch. Es gibt eine konkrete Dokumentation, wie es auch eine konkrete Spezifikation gibt. Ohne eine solche Dokumentation würde z.B. ein WLAN-Baustein garnicht erst in den Handel gelangen, da er gesetzliche Richtlinien (Sendeleistung, Frequenzen, ...) erfüllen muss. Außerdem verdanken wir die Funktion einer wohldefinierten und wohlspezifizierten API, die es ermöglicht, die Bausteine zu verwenden.
Gruß,
Svenska
-
Hallo,
.... kannst du im Hinterzimmer tun und lassen, was du willst.
So solltest du das nun auch wieder nicht formulieren. Es ist wimre in ganz Deutschland (also auch in Hinterzimmern oder Hobby-Kellern) gesetzlich verboten eine "atomare Kettenreaktion" (also eine Atombombe) auszulösen. ;)
Ich persönlich betrachte das Thema "UnReal-Mode" als erledigt.
Grüße
Erik
-
wohl auch weil es für diverse Anwendungen inklusive Spiele keine Alternative für Windows gibt
Das hat Gründe, also kann Windows so schlecht nicht sein.
Ja, das hat sicherlich Gründe. Aber daraus zu schließen das Windows nicht schlecht sein kann ist falsch.
Die meiste Software gibts nur für Windows weil es "alle" haben. Und jeder hat es weil es alle haben(wer kann schon *.odt öffnen) und weil die meiste Software nur darauf läuft. Mit Qualität hat das nichs zu tun.
Selbst wenn gewisse Bundesministerien feststellen, dass Linux und OpenSource die Bessere Lösung ist. Wird doch wieder zu MS gewechselt weil die Mitarbeiter das zu hause auch haben. (Maurern sollte man auch die Wasserwage wegnehmen; zuhause machen die auch alles nur π-mal-Daumen).
-
Hallo,
Ja, das hat sicherlich Gründe. Aber daraus zu schließen das Windows nicht schlecht sein kann ist falsch.
Ich habe geschrieben, dass es so schlecht nicht sein kann. Man kann damit arbeiten, es fliegt einem normalerweise nicht ständig um die Ohren und Windows 7 ist stabil. Jedenfalls kriege ich aus meiner Familie keine Absturzklagen mehr.
Die meiste Software gibts nur für Windows weil es "alle" haben. Und jeder hat es weil es alle haben(wer kann schon *.odt öffnen) und weil die meiste Software nur darauf läuft. Mit Qualität hat das nichs zu tun.
Richtig, du kannst aber auch RTF-Dateien benutzen. Die Funktionieren seit Windows 95. Die Durchschnittsqualität von Mac-Software ist höher als die von Windows-Software - aber hauptsächlich, weil die meiste Grütze auch für MacOS nicht existiert.
Selbst wenn gewisse Bundesministerien feststellen, dass Linux und OpenSource die Bessere Lösung ist. Wird doch wieder zu MS gewechselt weil die Mitarbeiter das zu hause auch haben.
Das unterschreibe ich so nicht. Eriks Schuld-Pointer ist hier anzuwenden: Wenn es nicht geht, dann kann Microsoft verklagt werden. Linux kann man nicht verklagen. Und wenn du professionelles Linux benutzen möchtest (ergo eine kommerzielle Distribution a la RedHat Enterprise), dann hast du recht heftige Kosten, die wahrscheinlich die Umstellung des gesamten Ökosystems (plus Schulung der Mitarbeiter) nicht rechtfertigen würden.
Linux gibt es nicht kostenlos, wenn du unterstellst, dass Zeit und Geld in dieser Gesellschaft teilweise ineinander umgewandelt werden können.
(Maurern sollte man auch die Wasserwage wegnehmen; zuhause machen die auch alles nur π-mal-Daumen).
Frage nach Aufwand gegen Nutzen. Aber ich bezweifle, dass ein Maurer mit Verstand ein mehrstöckiges Haus ohne Wasserwaage bauen würde. Mein Wandregal hab ich mit einer Kugel ausgerichtet, aber da ist es auch nicht so wichtig...
Gruß,
Svenska
-
Das unterschreibe ich so nicht. Eriks Schuld-Pointer ist hier anzuwenden: Wenn es nicht geht, dann kann Microsoft verklagt werden. Linux kann man nicht verklagen. Und wenn du professionelles Linux benutzen möchtest (ergo eine kommerzielle Distribution a la RedHat Enterprise), dann hast du recht heftige Kosten, die wahrscheinlich die Umstellung des gesamten Ökosystems (plus Schulung der Mitarbeiter) nicht rechtfertigen würden.
Linux gibt es nicht kostenlos, wenn du unterstellst, dass Zeit und Geld in dieser Gesellschaft teilweise ineinander umgewandelt werden können.
Er hat von besser geredet, nicht von billiger. Und teurer als MS sind die Enterprise-Distributionen auch nicht.
-
@Svenska:
Bei denen, die wissen, dass weder .doc noch .odt für veröffentlichungen geeignet sind bzw. das die Möglichkeit gibt das Dateiformat beim speichern auszuwälen, ist der Anteil der Windows-User um entliches geringer.
Win7 hab ich nie benutzt, auch wenn ich es dafür erst mal wegschmeißen musst. Aber ich bekomme ständig mit, dass das WinXP abschmirt(auch wenn den Nutzern nicht wirklich auffält, die warten ziehen den stecker und machen weiter), oder das es den arbeitsflüss hemmt, weil der Benutzer auf mal auf ein Symbol klickt und warted bis er feststellt das sich nichts tut, bevor es mit nem doppel-klick probiert, bzw. der Benutzer erschrickt weil plötzlich ganz merkwürdige sachen passieren weil er doppelt statt einfauch geklickt hat.
Und das bei Leuten, die beruflich auch an Windows-Rechnern sitzen(weil alle mitarbeiter das ja von zu Hause gewont sind).
Umschulung? Welscher art? Klicken Sie auf "Speichern als…" statt auf "Speichern unter…"? Für alles was kompliezierter ist müssen die Mitarbeiter sowieso geschuhlt werden.
Mit meinem Beispiel habe ich mich hierauf (http://www.heise.de/open/meldung/Kein-Linux-Desktop-im-Auswaertigen-Amt-1189344.html) bezogen.
Es war/ist schon umgestellt, die umstellungskosten, die "höher als erwartet" waren(was auch immer das heißen mag) zählen also nicht. Und die betriebskosten, sind ja scheinbar so gering wie nirgend wo sonst.
-
Hallo,
bevor das hier noch in einen richtigen Flame-War endet, können wir uns nicht auf folgendes einigen:
- Windows ist doof, uncool und recht buggy aber dafür ziemlich verbreitet und es läuft ne Menge Software drauf
- Linux ist etwas weniger doof, halbwegs cool und nicht ganz so buggy aber dafür eher selten und es gibt minimal weniger Software dafür
- unsere eigenen OSe sind nicht doof sondern obercool und dafür noch mehr verbuggt als Windows und Linux zusammen
Ich denke eine moderne und dynamische OS-Dever-Kommunity wie LowLevel.eu kann sich auch mal so ein konservatives Statement erlauben.
Also zur Abstimmung:
[ X ]Erik hat voll recht und wir haben uns alle wieder lieb
[ ]Erik ist ein nerviger Dummschwätzer und mein OS ist noch viel cooler als all Eure zusammen
[ ]Erik halt lieber die Finger still und ihr seit doch eh alle sch*§$&
Grüße
Erik
-
[ X ]Erik hat voll recht und wir haben uns alle wieder lieb
[ ]Erik ist ein nerviger Dummschwätzer und mein OS ist noch viel cooler als all Eure zusammen
[ ]Erik halt lieber die Finger still und ihr seit doch eh alle sch*§$&
-
[ X ]Erik hat voll recht und wir haben uns alle wieder lieb
[ Y ]Erik ist ein nerviger Dummschwätzer und mein OS ist noch viel cooler als all Eure zusammen
[ Z ]Erik halt lieber die Finger still und ihr seit doch eh alle sch*§$&
-
Ohne einen Flamewar zu starten ist deine Aussage einfach falsch: Eine Anwendung kann den Kernel nicht mehr zum Absturz bringen (ich habe jetzt keinen Beweis dafür, du aber für deine Aussage ja auch nicht). Windows 7 ist ein stabiles System (und ich bin von arbeitswegen tagtäglicher Windows-User und auch bei Kunden, denen wir Windows 7 anbieten und installieren läuft es hervorragend), ich habe bisher keinerlei Probleme mit Windows 7 gehabt, im Gegenteil: Subjektiv läuft z.B. mein Laptop schneller als mit Windows XP.
Dennoch bevorzuge ich gerade im privaten und Programmierer-Umfeld Linux, aber nicht, weil Windows 7 instabil ist, sondern weil das Entwickeln eines OS unter Windows einfach zu Umständlich ist und unter Linux einem keine Fesseln gesetzt werden.
Ich würde es als Absturz des Kernels von Windows 7(64 Bit) bezeichnen, wenn es nicht mehr möglich ist den Taskmanager zu öffnen, um eine abgestürzte Anwendung darüber zu Beenden und auch gar keine Reaktion beim Drücken der Tasten(auch Affengriff) mehr erfolgt und der Mousezeiger sich nicht mehr bewegen läßt.
Hallo,
Wie kann man denn daraus schlussfolgern das es ein Bug ist wenn Intel hierbei Fehlinformationen verbreitet?
Was Intel verbreitet können niemals Fehlinformationen sein, sondern das sind die zugesicherten Eigenschaften.
Ich habe noch auf keiner Intel-CPU (80386 SX/DX, 80486, Pentium 1,2,3,4, Core2) feststellen können das im RM beim Laden einer Segment-Adresse nach DS,ES,FS oder GS die Schattenregister davon beinflusst werder, oder die Segmentgrösse dadurch auf 64 KiB gesetzt wird. Welche Intel-CPU soll denn diese zugesicherte Eigenschaft überhaupt erfüllen, nur ein Intel Xeon?
Wenn ich einen Taschenrechner verkaufe und ins Handbuch schreibe das dort 1+1=3 ist dann ist das die offizielle und zugesicherte Funktionsweise dieses Taschenrechners (dass das seinen Nutzwert einschränkt ist jetzt mal egal) und wenn er doch normal 1+1=2 rechnet dann ist das eineindeutig ein Bug.
Ein Bug ist alles das wo das reale Verhalten vom spezifizierten Verhalten abweicht!
Nach dieser Definition müssen ja (fast) alle Intel(386+) so einen Bug enthalten. Wir brauchen uns aber nicht an diese Definition orientieren, wenn wir festgestellt haben das Intel nur eine Fehlinformation mit diesen speziellen zugesicherten Eingenschaften(wie die Schattenregister im RM arbeiten) verbreitet.
Egal wie idiotisch die Spezifikation auch sein mag. In der Welt des Geldes werden Produkte nach Spezifikation verkauft
Solche Pruduktbezeichnungen und zugesicherten Eigneschaften dürfen wir als Kunden auch gerne umdefinieren wie es und beliebt (Besipiel: Blödiamarkt).
Die Unternehmen können ihre als Perlen bezeichneten Produkte anpreisen wie sie möchten, wir finden dann schon eine passendere Bezeichnung. :lol:
und nicht nach dem äußeren Anschein (oder irgendwie beobachteten Verhalten). Für das was in der Spezifikation drin steht muss der Hersteller auch haften (also der Schuld-Pointer zeigt auf ihn) wenn sich ein Kunde beschwert.
Mir geht es hier aber nicht um eine Prudukthaftung, ich beschwere mich ja nicht das der Unrealmode auf Intel-Rechnern verfügbar ist, sondern in diesem Fall nur um eine Fehlinformation über zugesicherte Eigenschaften die nicht erfüllt werden. Der Inhalt der Schattenregister für DS,ES,FS,GS wird im RM nicht beinflusst. Auch nicht bei 32Bit-Rechner von AMD (K5, K6, Duron, TBred, Barton).
Normalerweise wird bei einem Schreibzugriff auf eines der Segment-Register immer auch das komplette zugehörige Schattenregister neu geladen.
Offensichtlich ist das nicht so und ich kenne auch keinen einzigen 80386+ bei dem das so ist.
Doch, im Protected-Mode und im Virtual-8086-Mode ist das genau so. Laut Spezifikation sollte das auch im Real-Mode so sein (nicht nur für CS sondern für alle Segmente) aber ist es nicht was eben den UnReal-Mode ermöglicht.
Welche Umstände auch immer den Unrealmode ermöglichen, wenn es mit den Schatenregister so spezifiziert wurde, aber es sich nicht so verhält, dann ist es eine Fehlinformation innerhalb der Spezifikation.
Könnte es nicht auch anders herum sein, weil im RM beim Laden der Segmentregister die Schattenregister unberührt bleiben fehlen ein paar Transistoren?
Das halte ich für extrem unwahrscheinlich. Für spezielle Extra-Ausnahmen benötigt man in den Chips üblicherweise auch spezielle Extra-Transistoren.
Vergessen wir mal für einen Moment die Spezifikation, denn hier geht es ja nicht darum ob wir ein grünes Fahrad als rot bemalt oder gelb bemalt bezeichenen, sondern um einen Sachverhalt, denn in der Regel funktioniert der Unrealmode auf den meisten Intel/AMD-CPUs und eine Ausnahme wäre es dann, wenn die Schattenregister im RM ebenfalls beinflusst werden. Werden sie aber in der Regel nicht und genau hierbei weicht die zugesichterte Eigenschaft von der Regel ab und damit können wir von einer von Intel verbreiteten Fehlinformation reden.
Ich erweitere für den Unrealmode gewöhnlich nur "DS", da man für FS und GS jeweils ein zusätzliches Segment overide Prefix benötigt, welches man bei Speicherzugriffen über DS nicht benötigt.
Aber DS wird von normalem Real-Mode-Code sehr häufig mit einem neuen Wert geladen so das sehr häufig das Risiko besteht das die Schattenregister von DS nicht mehr das gewünschte 4 GB-Limit enthalten (falls sich die CPU an die Spezifikation hält, wovon wir damals ausgegangen sind).
Das sehe ich auch so. Das DS-Segmentregister wird in sehr vielen Routinen die für den RM entwickelt wurden relativ oft mit neuen Segmentadressen geladen. Trotzdem wird die Segmentgröße im Schattenregister davon nicht beinflusst wenn vorher die Segmentgrösse für den Unrealmode auf 4 Gib erweitert wurden. (Für eigene Routinen im Unrealmode genügt es oft den jeweiligen Offset zu verändern, um darüber eine belibige lineare 32Bit-Adresse adressieren zu können.)
Ich halte mich lieber an die Dinge die ich selber ausprobiert habe, egal ob es offiziel bekantgegeben wird, oder auch nicht.
Was Du in Deinem privaten Hobby-Keller machst ist allein Deine private Angelegenheit (genau so wie in Deinem privaten Garten nicht auch automatisch die StVO gild), aber was in der großen weiten Welt passiert hängt von vielen Regeln und Gesetzen ab und wer da nicht unter die Räder kommen will tut gut daran sich an diese Spielregeln zu halten.
Schon klar, nur brauchen wir uns nicht an Definitionen von zugesicherten Eigenschaften halten und dürfen, wenn diese als faktisch falsch erkannt wurden, diese auch gerne als Fehlinformation bezeichnen.
Die Genialität mit der absolute DAUs eine Software fehl bedienen können ist quasi unbegrenzt, ......
Das halte ich für leicht übertreiben dargestellt.
Solche rein mutmaßlichen Bugs konnte ich aber bisher nicht festellen. Mit dieser Definition stimmt also offenbar etwas nicht.
Nur weil Du eine Definition nicht nachvollziehen kannst (im krassen Gegensatz zu allen anderen) heißt das nicht das diese Definition falsch ist.
Ich kann auch gut Intels Definition nachvollziehen, nur ist sie und das nicht nur in meinen Augen, eine Fehlinformetion auf die auch rund um den Unrealmode an manchen Stellen im internet in dieser Form darauf hingewisen wurde, das diese zugesichterte Eigenschaft das die Schattenregister auch im RM beeinflusst werden, so nicht wie von Intel beschrieben wurde vorhanden ist und was hier von Intel als Bug bezeichnet wurde, das der Unrealmode funktioniert, die in den meisten Fällen anzutreffende Regel auf Intel-CPUs ist. Dieser krasse Gegensatz ist somit nicht nur mir aufgefallen, sondern bereits anderen Programmieren von Intels 80386+. Damit läßt sich, ganz passend wie ich meine, diese zugesichterte Eigenschaft als Fehlinformation von Intel bezeichnen, um diesen Sachverhalt treffender darzustellen. Auch wenn nur wenige Interessierte sich mit solchen Detailfragen beschäftigen, ist es nicht so das alle anderen Programmierer rund um den Unrealmode andere Erfahrungen gesammalt haben.
Wenn man nichts testet, dann ist die Warscheinlichkeit eher unbestimmbar. Nur weil etwas unbekannt ist kann man davon eben nicht ableiten das ein bestimmtes Verhalten hierbei vorliegt.
Aber für Deine Programme möchtest Du doch kein unbekanntes Verhalten sondern ein bekannt funktionierendes, oder? Also kannst Du Dich nicht auf Dinge verlassen deren Funktion bzw. Funktionssicherheit nicht bekannt ist. Genau das ist eine der Spielregeln in der großen weiten Welt.
Ein mir bekanntes und funktionierendes Verhalten von verschiedenen Generationen von Intel-CPUs ist der Unrealmode und das die Schattenregister im RM/Unrealmode durch das Laden der Segmentregister(DS, ES, FS und GS) mit neuen Segmetnadressen dadurch nicht beinflusst wird.
Dieses Verhalten ist mir damit hinreichend bekannt. Allerdings würde ich nicht so gerne bei für mich unbekannten Dingen immer von den schlimmsten anzunehmenden Umständen ausgehen wollen. Denn so etwas könnte sich möglicherweise später als ein unbegründeter Vororteil heraustellen.
aber solche Probleme interessieren mich als privaten Programmieren eigentlich sehr wenig und sie sollten auch keinen privaten Programmierer davon abhalten können ....
Wie ich bereits schrieb, in Deinem privaten Hobby-Keller ist das völlig in Ordnung aber wenn Du mit dem was Du tust irgendwann mal Geld verdienen möchtest (und sei es nur als angestellter Lohnsklave) solltest Du Deine Einstellung noch mal überdenken.
Grüße
Erik
Ich denke nicht das sich meine Einstellung dazu je ändern könnte, das Intel hier rund um das Thema Unrealmode eine Fehlinformation verbreitet hat.
So wichtig ist für mich Intel nun auch wieder nicht, als das ich gezungen wäre für Intel zu lügen und Geld verdienen kann man auch als Lohnsklave ganz ohne zu lügen. Wer es trotzdem tut ist in meinen Augen bestimmt nicht beneidenswert. So kann man auch als Hobby-Programmieren derartige Fehlinformationen von Intel einfach ignorieren und es selber testen, ob diese zugesichte Eigenschaft (betreffende Funktionsweise der Schattenregister) wie Intel behauptet vorhanden ist, oder eben nicht, ob die verwendete Intel-CPU einen von Intel bezeichneten "Bug" hat (weil der "UnrealIntelbugmode" doch funktioniert), oder auf welcher Intel CPU eigentlich nicht.
Dirk
-
Unterm Strich eine lustige Diskussion, die mittlerweile soviel Nährwert hat wie eine alte Banane aus dem Mülleimer.
Freiheit für de Wa(h)le, die Programmierers und wir sollten eh alle OS/2 oder VMS nutzen und unsere Computer wegwerfen.
Danke und guten Hunger wünscht
Hartmut, Der.
-
Ach Dirk...
Dinge, die spezifiziert sind, existieren und funktionieren so wie in der Spezifikation beschrieben. Alles andere ist ein Bug.
Dinge, die nicht in der Spezifikation stehen, können trotzdem funktionieren. Nur sollte man sich darauf im Zweifelsfall halt nicht verlassen. Betonung auf "sollte", da steht nicht "muss".
Ende der Diskussion.
Gruß,
Svenska
-
Hallo,
[ X ]....
[ Y ]....
[ Z ]....
Also ich würde sagen Deine Stimme ist ungültig und damit Deine Meinung (mal wieder) irrelevant! ;)
und guten Hunger
Danke, gleichfalls!
Grüße
Erik