Beiträge anzeigen

Diese Sektion erlaubt es dir alle Beiträge dieses Mitglieds zu sehen. Beachte, dass du nur solche Beiträge sehen kannst, zu denen du auch Zugriffsrechte hast.


Nachrichten - freecrac

Seiten: 1 [2] 3 4 5
21
Hallo,


.... and it will no longer be mandatory to support these old mode numbers.
Ein Grund mehr sich auf Weg (c) zu konzentrieren. Je nach dem welche Priorität bei neuen Graphikkarten noch das BIOS genießt kann es also durchaus sein das da nicht mehr viel geht und man eh die individuelle Liste auslesen muss. Der Großteil aller Graphikkarten der letzten 10 Jahre hat wimre VBE 2.0 (das solltest Du auch immer prüfen bevor Du weitere Funktionen benutzt!).

Ja genau.

Zitat
Ich habe die Batchdatei schnell unter XP geschrieben und während ich den Beitrag schrieb sie ausgeführt, um das Ergebniss(Inhalt von Vesa.info-Datei) dann mit einzufügen.
Na hoffentlich sind das dann auch die echten VESA-Modi die Dir da der DOS-Emulator von Windows XP angeboten hat,

Ohne GraKa-Treiber(unmitttelbar nach der Windowsinstallation) stimmen die Einträge aus Funktion 4F00h nicht. Aber wenn ein GraKa-Treiber installiert ist, dann werden auch die InIformationen aus Funktion 4F00h und 4F01h richtig emuliert. Mit Win2K konnte man sogar die EDID(4F15h) holen, mit XP geht es nicht mehr.

Zitat
wenn Du diese Information korrekt möchtest dann mach das unter purem DOS oder nutze Svenskas Vorschlag mit dem Linux-Kernel (ich vermute mal eine beliebige Linux-CD reicht aus um das hinzubekommen).

Danke. aber die Informationen stimmen schon und sind mit denen unter puren DOS identisch. Du kannst es ja selber ausprobieren, wenn du ein XP installiert hast.

Dirk
22
(a) Du nimmst die vordefinierten BIOS-Modi und den int 10h. Das sind VGA- und VESA-Modi. Größer als 1600x1200 geht allerdings nicht...
Das VBE-Bios auf meiner Colorfull GTX 295 und das VBE-Bios auf erik laptop unterstützt doch auch 1920x1200x32.
Das sind aber nicht die vordefinierten (standardisierten) VESA-Modi, sondern vom Grafikkartenhersteller dort eingetragene nicht-standard-Modi.

Ehe ich mit Debug rumspiele, um an die Liste zu kommen, hätte ich direkt einen Linux-Kernel mit dem Parameter "vga=ask" gebootet, dann zeigt der nämlich alle im Grafik-BIOS vorhandenen Modi an und man kann sie auch einfach eintragen. Das geschieht sogar, bevor der eigentliche Kernel bootet.

Ansonsten ist deine Lösung ziemlich technisch (die Angaben "10 Bit" und "20 Bit" betrachte ich mal als fehlerhafte Bit-Dekodierung, das sollen bestimmt 16 Bit bzw. 32 Bit Farbtiefe sein...) ;-)

Gruß,
Svenska

Bitte auch das kleingedruckte lesen: (alle Werte sind hexadezimal).

vbe3.pdf: Starting with VBE version 2.0, VESA will no longer define new VESA mode numbers and it will no longer be mandatory to support these old mode numbers.

Diese alte Mode-Liste wird ofiziel nur bis VBE 1.X unterstützt:

 100h   640x400x256
 101h   640x480x256
 102h   800x600x16
 103h   800x600x256
 104h   1024x768x16
 105h   1024x768x256
 106h   1280x1024x16
 107h   1280x1024x256
 108h   80x60 text
 109h   132x25 text
 10Ah   132x43 text
 10Bh   132x50 text
 10Ch   132x60 text
---VBE v1.2---
 10Dh   320x200x32K
 10Eh   320x200x64K
 10Fh   320x200x16M
 110h   640x480x32K
 111h   640x480x64K
 112h   640x480x16M
 113h   800x600x32K
 114h   800x600x64K
 115h   800x600x16M
 116h   1024x768x32K
 117h   1024x768x64K
 118h   1024x768x16M
 119h   1280x1024x32K
 11Ah   1280x1024x64K
 11Bh   1280x1024x16M

Bei VBE2 und VBE3 ist es nicht sicher ob es die alte Nummern noch gibt, oder eine andere Auflösung besitzen.

Edit:
Sorry, das abc-zitieren muss ich noch lernen.

Es wäre doch etwas unpraktisch dafür neu zu booten während ich einen Beitrag schreibe.
Ich habe die Batchdatei schnell unter XP geschrieben und während ich den Beitrag schrieb sie ausgeführt, um das Ergebniss(Inhalt von Vesa.info-Datei) dann mit einzufügen.

In Deiner Tabelle fangen die interessanten Modi auch erst bei 0130 an
Das stimmt leider, aber verwenden tue ich meist nur 1920x1200x32 native Auflösung meines LCD und kleinere Modi sehen damit eher bescheiden aus.

Dirk
23
(a) Du nimmst die vordefinierten BIOS-Modi und den int 10h. Das sind VGA- und VESA-Modi. Größer als 1600x1200 geht allerdings nicht...
Das VBE-Bios auf meiner Colorfull GTX 295 und das VBE-Bios auf erik laptop unterstützt doch auch 1920x1200x32.

VesaInfo.bat
@echo off
echo e cs:0100>tmp.deb
echo B8 00 4F BF 00 02 CD 10>>tmp.deb
echo g=cs:0100 0108>>tmp.deb
echo d cs:0200>>tmp.deb
echo q>>tmp.deb
debug <tmp.deb >Vesa.info
del tmp.deb

[Vesa.info von Colorfull GTX 295]
-e cs:0100

1537:0100 00.B8 00.00 00.4f 00.BF 00.00 00.02 00.CD 00.10

-g=cs:0100 0108


AX=004F BX=0000 CX=0000 DX=0000 SP=FFEE BP=0000 SI=0000 DI=0200
DS=1537 ES=1537 SS=1537 CS=1537 IP=0108 NV UP EI PL NZ NA PO NC
1537:0108 0000 ADD [BX+SI],AL DS:0000=CD
-d cs:200

1537:0200 56 45 53 41 00 03 1E B5-00 C0 01 00 00 00 22 02 VESA..........".
1537:0210 37 15 E0 00 00 00 00 00-00 00 00 00 00 00 00 00 7...............
1537:0220 00 00 00 01 01 01 02 01-03 01 04 01 05 01 06 01 ................
1537:0230 07 01 0E 01 0F 01 11 01-12 01 14 01 15 01 17 01 ................
1537:0240 18 01 1A 01 1B 01 30 01-31 01 32 01 33 01 34 01 ......0.1.2.3.4.
1537:0250 35 01 36 01 3D 01 3E 01-45 01 46 01 4A 01 60 01 5.6.=.>.E.F.J.`.
1537:0260 61 01 62 01 66 01 67 01-70 01 7B 01 7C 01 7D 01 a.b.f.g.p.{.|.}.
1537:0270 FF FF 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
-q

Die Modeliste habe ich rot markiert und blau den Pointer der auf die Modeliste zeigt.

0100 X=0280 Y=0190 8Bit
0101 X=0280 Y=01E0 8Bit
0102 X=0320 Y=0258 4Bit
0103 X=0320 Y=0258 8Bit
0104 X=0400 Y=0300 4Bit
0105 X=0400 Y=0300 8Bit
0106 X=0500 Y=0400 4Bit
0107 X=0500 Y=0400 8Bit
010E X=0140 Y=00C8 10Bit
010F X=0140 Y=00C8 20Bit
0111 X=0280 Y=01E0 10Bit
0112 X=0280 Y=01E0 20Bit
0114 X=0320 Y=0258 10Bit
0115 X=0320 Y=0258 20Bit
0117 X=0400 Y=0300 10Bit
0118 X=0400 Y=0300 20Bit
011A X=0500 Y=0400 10Bit
011B X=0500 Y=0400 20Bit
0130 X=0140 Y=00C8 8Bit
0131 X=0140 Y=0190 8Bit
0132 X=0140 Y=0190 10Bit
0133 X=0140 Y=0190 20Bit
0134 X=0140 Y=00F0 8Bit
0135 X=0140 Y=00F0 10Bit
0136 X=0140 Y=00F0 20Bit
013D X=0280 Y=0190 10Bit
013E X=0280 Y=0190 20Bit
0145 X=0640 Y=04B0 8Bit
0146 X=0640 Y=04B0 10Bit
014A X=0640 Y=04B0 20Bit
0160 X=0500 Y=0320 8Bit
0161 X=0500 Y=0320 20Bit
0162 X=0300 Y=01E0 8Bit
017B X=0500 Y=02D0 20Bit
017C X=0780 Y=04B0 8Bit
017D X=0780 Y=04B0 20Bit
(alle Werte sind hexadezimal)

Edit:
Quelle: vbe3.pdf von vesa.org (Zum Downloaden registrieren und/oder einloggen nötig.)
VESA PUBLIC STANDARDS DOWNLOAD REGISTRATION: https://fs16.formsite.com/VESA/form714826558/secure_index.html

Dirk
24
Lowlevel-Coding / Re:C Kernel starten
« am: 23. June 2011, 09:24 »
http://de.wikipedia.org/wiki/Extensible_Firmware_Interface
Zitat
EFI wurde dafür kritisiert, mehr Komplexität ins System zu bringen, ohne nennenswerte Vorteile zu bieten[13] und das vollständige Ersetzen mit einem Open-Source-BIOS wie OpenBIOS und Coreboot unmöglich zu machen[14]. Es löse nicht eines der langjährigen Probleme des BIOS - nämlich, dass die meiste Hardware zwei unterschiedliche Treiber benötigt.[15] Es sei nicht klar, warum es nützlich sein soll, zwei komplett unterschiedliche Betriebssysteme gleichzeitig in Betrieb zu haben, die im Grunde die selben Aufgaben erledigen, oder warum ein neues Betriebssystem von Grund auf neu geschrieben werden müsste.[15] EFI gilt einem Entwickler von Coreboot zufolge in sicherheitskritischen Einsatzumgebungen - wie etwa in Banken - als ein mögliches Sicherheitsrisiko, da etwa mit dem implementierten Netzwerkstack die theoretische Möglichkeit bestünde, Daten unbemerkt vom Betriebssystem an eine beliebige Adresse zu senden. Auch für DRM-Zwecke könnte EFI benutzt werden, um etwa den I/O-Datenstrom auf digitale Wasserzeichen hin zu überwachen. Aus diesen Gründen plädieren einige Anwender eher für ein quelloffenes System wie Coreboot (ehemals LinuxBIOS).

Ich denke das es nur sehr wenige PC-Benutzer geben wird die ihr neu eworbenes UEFI-Bios gegen ein Coreboot-Bios austauschen werden und so werden wohl die Nachteile dieser Entwicklung sich am Markt durchsetzen, so das die meisten Kunden hierbei durch restriktive Gängelungen von Seiten der Konzerne bei der Frage der individuellen Selbstbestimmung, sich über den Tisch ziehen lassen werden und nur ein bedeutungsloser Anteil an kritikfähigen Individualisten sich dieser Sache entziehen werden.

Im weitem Umfeld sieht man ja auch schon am Vertrag von Maastricht deutlich genug in welche Richtung es nach dem Willen unser führenden Entscheidungsträger geht. (Kontroverse Kritik darüber findet man u.A. in Beiträgen von Karl Albrecht Schachtschneider. http://www.kaschachtschneider.de/)

Dirk
25
Lowlevel-Coding / Re:C Kernel starten
« am: 23. June 2011, 01:55 »
Wenn UEFI sich weiter verbreitet ...

Grüße
Erik

Ich habe allerdings die Befürchtung das mit UEFI auch Digital Rights Management(DRM) immer weiter verbreitet wird und so alle User zukünftig für jeden Mouseklick beim Klickibunti zigfach zahlen müssen. Ob diese feindliche Übernahme unserer PCs dann noch zu stoppen ist bleibt abzuwarten. So sehe ich die Entwicklung mit gemischten Gefühlen entgegen und ich frage mich, ob so ein Hobby mir dann überhaupt noch Spaß macht, denn Fernsehen sehe ich auch, wegen nur noch 24 Stunden Teletubie-Folter auf allen Kanälen, schon seit einigen Jahren überhaupt gar nicht mehr. Das ganze erinnert mich immer mehr an den Begriff einer Kathodenstrahl-Marionette, denn es ist ja auch noch gar nicht so lange her, da hat man sich noch zur Tageschau einen Anzug angezogen und den Nachrichtensprechen ebenfalls mit einem "guten Abend" vor der Glotze begrüßt, so als wenn man im Fernsehstudio die Zuschauer ebenfalls sehen und hören könnte. Nun haben wir ja schon freiwillig unsere Radio-Hypnotic Intracereberal Mindcontrol-Transmitter-Handicaps akzeptiert. Morgen gibt es dann wohl gleich nach der Geburt den Gutmenschen-Chip implantiert.

Dirk
26
Lowlevel-Coding / Re:C Kernel starten
« am: 22. June 2011, 11:49 »
Meines Erachtens ist ein OS, das in den PM schaltet, kein RM-OS mehr.

Ein OS das nur kurzzeitig in den PM schaltet, um den XMS-Speicher zu verwalten und unmittelbar danach wieder zurück in den RM schaltet, um alles Andere im RM zu erledigen, wie z.B. Bios-Interrupts zu benutzen, um darüber Geräte zu steuern, das würde ich nicht als PM-OS bezeichnen. DOS wird aus diesem Grund als ein RM-OS bezeichnet, auch dann wenn es Treiber zur Verfügung stellt die kurzzeitig in den PM und wieder zurück in den RM schalten.

Wenn du allerdings DOS, oder eine anderes OS das ebenfalls nur kurzzeitig in den PM und dann gleich wieder zurück in den RM wechselt als PM-OS bezeichnest,  dann weicht deine Definition aber erheblich von der allgemeinen Definition hierbei ab.

Zitat
Aber selbst wenn man es so sieht, dass alles ein RM-OS ist, in dem die Anwendungen (aber nicht zwingend der Kernel oder Treiber) im RM laufen, welchen Vorteil hat der RM denn bitte gegenüber dem PM? Ich sehe keinen anständigen Grund, das zu tun. Außer vielleicht Nostalgie.

Einen Vorteil sehe ich darin das es im RM keine Protection gibt und man sich daher mit solchen Begebenheiten wie Zugriffsrechte und deren Verletzung überhaupt nicht kümmern muss. So ist es vergleichsweise einfacher für einen noch relativ unerfahrenen Entwickler eines OS mit dem RM zu beginnen, als mit dem PM. Dann kann man im RM auch diverse Bios-Funktionen benutzen, die einem im PM nicht zur Verfügung stehen. So muss man sich um solche Dinge im PM selber kümmern, womit der gesamte Aufwand ein OS zu entwickleln erheblich ansteigt.

Zitat
Die Möglichkeit für den Realmode den gesamten XMS-Speicher zu benutzen zeigt ja nur das es eben möglich ist weit aus mehr Speicher zu verwenden, als nur die erwähnten 640 KByte.
Der RM-Code kann den gesamten XMS-Speicher eben nicht direkt nutzen. Er kann PM-Code aufrufen, der die Daten für ihn im Speicher herumschiebt. Das ist aus Sicht des RM-Programmieres maximal eine Art schneller Swapspeicher, aber kein direkt nutzbarer RAM.

Ja genau, der nutzbare XMS-Speicher kann nur indirekt dem RM zur Verfügung gestellt werden. Trotzdem bleibt damit DOS ein RM-OS laut allgemeiner Definition. Ob das nun über einen Treiber erledigt wird, oder bereits im Kernel eines RM-OS selber integriert wurde ist dabei nicht von Bedeutung, sondern nur ob die meisten Funktionen des Kernels auf dem RM basieren, oder eben nicht.

Zitat
EMS kommt dem direkt nutzen schon näher, aber das ist dann endgültig PM.

Auch EMS-Speicher wird von DOS über einen entsprechenden Treiber zur Verfügung gestellt. Trotzdem wird DOS auch weiterhin als ein RM-OS bezeichnet, weil der V86-Mode sich eben ähnlich wie der RM verhält.

Zitat
Zitat
LOL. Was möchtest du uns damit eigentlich sagen, dass ein Rechner ohne PM nicht in den PM schalten kann und es somit besser wäre, ein RM-OS zu entwickeln für den Fall, das man gelegentlich auch mal solche exotische Retro-Hardware verwendet
Gibt es denn andere Gründe, sich den RM anzutun als "exotische Retro-Hardware"?

Ich verwende den RM mit Vorliebe auch auf moderner Rechnern, wie z.B. auf meinen Asus Striker 2-Rechner mit Intel Core2quad @2.8Ghz und einer Nvidia GTX 295 mit VBE3 Bios und einen daran angeschlossenen 28"LCD in 1920x1200x32. Ist dir diese Hardware modern genug?

Gerne könnte die CPU für mich und meine RM-Anwendungen noch 1000 fach schneller sein, solange der RM auch weiterhin zur Verfügung steht. Der wichtigste Grund für mich ist es Spaß damit zu haben etwas Eigenes zu entwickeln, ohne mich mit den Einschränkungen und Richtlinien eines bereits vorhandenenes OS und deren in Stein gemeisselten Funktionsweise herumplagen zu müssen. Hierbei kann man doch bei der Verwendung von Closed-Source-Treiber es nur lernen wie man, im übertragenen Sinne, einen Lichtschalter an und aus schaltet, nicht jedoch wie man einen solchen Schalter sich selber baut. Für mich ist das einfach zu unbefriedigend etwas für Windows, oder Linux (+Derivate) zu programmieren.

Ich hatte auch noch nie das Bedürfniss mir eine eigenes OS zu entwickeln, mir genügt es wenn meine Anwendungen auch ohne ein PM-OS funktionstüchtig zum laufen zu bringen sind.

Zitat von: Svenska
Aber wie nennst du es, wenn man schon vorher weiß, dass es ein Holzweg sein wird und es trotzdem tut?
Entweder ist es dann noch keine Holzweg und/oder man erhofft sich noch andere Merkmale daran zu finden die einen wichtig erscheinen.

Dirk
27
Lowlevel-Coding / Re:C Kernel starten
« am: 22. June 2011, 10:34 »
Zitat
LOL. Was möchtest du uns damit eigentlich sagen, dass ein Rechner ohne PM nicht in den PM schalten kann und es somit besser wäre, ein RM-OS zu entwickeln für den Fall, das man gelegentlich auch mal solche exotische Retro-Hardware verwendet
Gibt es denn andere Gründe, sich den RM anzutun als "exotische Retro-Hardware"?
Eventuell langeweile.  :wink:

Was ist das, kann man das auch essen :? Die Worte kommen mir zwar bekannt vor, aber dessen Bedeutung habe ich bis heute immer noch nicht begriffen.
Ich selber habe so viele verschiedene Interessen, die ich zu meiner Lebzeit wohl niemals alle auch nur Ansatzweise nachgehen könnte.
So fällt es mir auch sehr schwer eine Langeweile zu verstehen was damit überhaupt gemeint ist.

Zitat
Das ist zumindest bei mir immer mal wieder ein Grund, warum ich teilweise ziemlich bescheuerte Projekte starte.  :-D

Ich würde ein Projekt dessen ich mich widme niemals als bescheuert bezeichnen. Auch wenn man sich damit quasei auf einem Holzweg begibt ist es doch zumindestens dafür nützlich zu erkennen, dass es nicht der richtige Weg war und um dieses erkennen zu können, dafür muss man halt auch mal solche Wege einschlagen.

Dirk
28
Das Wiki / Re:VESA-Tutorial (noch sehr primitiv)
« am: 22. June 2011, 09:51 »
Lieber Dirk,

erstens: Sechs Jahre alte Themen belebt man nicht wieder, es sei denn, man hat einen ganz speziellen Grund. Sonst macht man einfach ein neues Thema auf, dann gibts auch wenig Aufreger.

zweitens: seitenlange Codelistings (zumal in Assembler) bringen nichts. Das hatte ich dir schonmal versucht zu erklären. Besonders ausgeschrieben bringen die gar nichts. Dann lade sie lieber bei Rapidshare hoch und verlinke sie oder stelle sie ins Wiki.

drittens: DOS-Anwendungen bleiben DOS-Anwendungen. Die gehören inhaltlich nicht zum OS-Development und insbesondere nicht zum Thema "Tutorial".

Gruß,
Sebastian
Huch habe ich ein Dejavou, oder waren diese beiden Themen "alte Threads wieder aufwärmen" und "lange Listings" nicht schon lange und bereits zufriedenstellend abgehandelt?

Um es noch einmal deutlich zu machen: Ich wärme dieses Thema nun nicht wesentlich mehr auf, als du selber es mit deinem erneuten Posting, auf das ich nun antworte, gerade getan hast.

Ich bin mit dem Thema VESA doch auch gar nicht angefangen, auch wurde bis zu meinem ersten Posting zu diesem Thema es noch gar nicht erwähnt, dass dieses Thema überhaupt gar nicht (mehr) erwünscht ist. Auf Grund der erneuten Beteiligung an diesem Thema gehe ich allerdings jetzt davon aus, dass hier doch ein gewisses Interesse vorhanden ist und auch weiterhin besteht. Auch sind die von mir verwendeten Vesafunktionen nicht alleine nur auf DOS beschränkt, denn jeder Entwickler eines RM-OS, oder auch eines RM-Bootmanagers kann die relevanten Teile aus meinen Vesa-Demo herausnehmen und ebenfalls für sich verwenden. Mir erschien es aber zweckmäßig für die Demonstration hierbei DOS zu verwenden, um die genaue Funktionsweise auf eine einfache und relativ leicht verständliche Weise darstellen zu können.

Dirk
29
Das Wiki / Re:VESA-Tutorial (noch sehr primitiv)
« am: 22. June 2011, 09:23 »
Alle hier genannten Links unterhalb von http://www.8ung.at/paulhaerle/ sind entweder 404 not found oder vorbidden!

bitte korrigier das mal, damit die neulinge auch "mitlesen" können. :cry:

danke
marantis

Die Doku zum VBE(vbe3.pdf) holt man sich am besten direkt von vesa.org(registrieren und einloggen).
Vesa Public Standards Download Registration: https://fs16.formsite.com/VESA/form714826558/secure_index.html

Ein "Vesa.doc" habe ich hier gefunden:
http://www.google.de/url?sa=t&source=web&cd=36&ved=0CD0QFjAFOB4&url=http%3A%2F%2Ft0ast3r.t0.ohost.de%2Fknow%2520how%2Fvesa.doc&ei=-SDITa62MtCKswbc_fD6Dg&usg=AFQjCNHx2Sv4EFl6t57q0E_cIwCHfehbKA

Das von mir geschriebene Vesa-Demo(mit Quellcode für MASM5) kann man von meiner Hompage herunterladen: http://www.alice-dsl.net/freecracmaps/Tool/Neutrip.zip

Dirk
30
Lowlevel-Coding / Re:C Kernel starten
« am: 22. June 2011, 09:03 »
Hallo,


Keinen Texteditor. :-P
Stimmt.

Wenn Du möchtest das ich zur nächsten Präzisionshaarspaltung ansetze wüste ich aber schon gerne was Du mit "irgendwas einschränkendes" meinst. ;)


Grüße
Erik
Ich vermute das damit die Möglichkeit eines RM-OS jederzeit auch in den PM schalten zu können gemeint ist und das dieser Punkt bei der Betrachtung, dass man vom RM nur ein MByte adressieren kann, dadurch eingeschränkt wird. So habe ich es verstanden.

Dirk
31
Lowlevel-Coding / Re:C Kernel starten
« am: 22. June 2011, 08:48 »
Was wollte Herr Torvalds eigentlich entwickeln als Linux entstand?
SCNR ;)
Keinen Texteditor. :-P

Ich habe noch daran gedacht und mir überlegt, ob ich irgendwas einschränkendes dazuschreiben soll. Hätte ich wohl doch besser gemacht, so viele Haarspalter wie hier inzwischen rumlaufen. ;)
Ja ich verstehe was du meinst, du hast dich etwas unglücklich ausgedrückt, aber du kannst doch jederzeit erneut darauf Antworten und deine Sichtweise hierbei vertiefen, bzw. entstandene Missverständnisse aufklären.

Um eine kleine Anwendung(wie einen schlichten Texteditor) zur Ausführung zu bringen braucht man nicht unbedingt ein OS!!!
Deine Aussage das jeder Texteditor auch immer ein OS benötigt ist somit falsch und auch im verwendeten Beispiel daher irreführend. Ein OS kann nun mal ohne ein Booteintrag auf einem Datenträger nicht gestartet werden, wobei ein schlichter Texteditor auch ohne ein OS zur Ausführung gebracht werden kann. Mir geht es hierbei darum solche Fehlinformationen rund um den Realmode richtig zu stellen, damit eine Entscheidung des zu verwendenden Betriebsmodes für ein OS auch mit allen relevanten Fakten vollzogen werden kann und nicht nur einem Teil davon, der alleine ein doch eher schiefes Bild auf diesen Teilbereich wirft. Also das mit den nur verfügbaren 640 KB die man angeblich bei der Verwendung eines RM-OS nur zur Verfügung stehen hat wird hierbei völlig ausser acht gelassen, dass man vom einem RM-OS jederzeit ebenfalls in den PM schalten kann und trotzdem können wir diese OS als ein RM-OS bezeichnen.

Ich finde es daher besser alle Möglichkeiten auszuloten, um eine Entscheidung des zu verwendenden Betriebsmodes machen zu können. Hierbei wären dann auch die Möglichkeiten des PM anzugeben, dessen Fähighkeiten weit über den des RM hinausgehen, als nur den RM mit unzulänglichen Fehlinformationen schlechter dastehen zu lassen als er in Wirklichkeit ist.

Dirk
32
Lowlevel-Coding / Re:C Kernel starten
« am: 22. June 2011, 08:13 »
Hallo,


Jeder Texteditor braucht ein OS, um zu laufen, aber wenn du einen Editor schreibst, wirst du nicht auf die Idee kommen, erst noch das passende OS dazu zu schreiben.
Was wollte Herr Torvalds eigentlich entwickeln als Linux entstand?
SCNR ;)


Jedes Realmode OS welches einen vergleichbaren XMS-Extender verwendet, kann auch den gesamten verfügbaren oberen Speicherbereich für den RM verwalten.
DOS verwendet den XMS aber nicht, auch die Verwaltung des XMS wird von himem.sys und nicht von DOS erledigt. Für DOS ist himem.sys einfach nur ein Treiber/TSR der irgendeinen Service anbietet. Das es Speicher hinter der HMA gibt weiß DOS (also der Kernel msdos.sys) noch nicht einmal. Es gibt aber im Lieferumfang von DOS (als OS-Distribution) einige Tools die XMS benutzen können (z.B. smartdrv.exe).
Jedes Realmode-OS das einen vergleichbaren XMS-Extender direkt in seinen Kernel implementiert kann aber den Speicher selber verwalten und auch selber nutzen. Es muss ja nicht ein Treiber werden und ausgehend von Thema (selber ein OS zu entwickeln) ist es doch eher unwichtig ob DOS es hier mit einem Treiber macht, oder auch nicht. Die Möglichkeit für den Realmode den gesamten XMS-Speicher zu benutzen zeigt ja nur das es eben möglich ist weit aus mehr Speicher zu verwenden, als nur die erwähnten 640 KByte.

Zitat
Das man den oberen Speicher vom RM aus nicht direkt adressieren kann ist hierbei völlig irrelevant.
Das ist sehr wohl relevant! Speicher der nicht direkt nutzbar ist läst sich weder für Code noch für statische Daten oder Heap oder Stack nutzen. Der XMS kann von reinen Real-Mode-Programmen/OSen nur als große externe Datenablage (wie z.B. eine Datei) benutzt werden aber nicht als aktiven Teil des Programms.
Für den Benutzer eines verwendenten Realmode-OS ist es irrelevant wie nun auf den XMS-Speicher zugegriffen werden kann. Auch kann ein beliebiger RM-Opcode von einem langsameren Datenträger in den XMS-Speicher zunächst als Daten eingelagert werden und bei Bedarf heruntergeholt und dann ausgeführt werden, ganz ohne sich dabei um Privilege levels und möglichen Schutzverletzungen zu kümmern, wenn im Datenbereich nun ein Opcode zur Ausführung kommt.

Zitat
Mit EMS ist das etwas anders aber auch ziemlich umständlich.
Auch wird hierbei ja nur kurzzeitig in den PM dafür geschaltet und dann wieder zurück in den Real Mode.
Egal ob kurz oder lang, wenn das OS auch auf Systemen ohne Protected-Mode laufen können soll dann ist der einfach nicht verfügbar und fertig.


Grüße
Erik
LOL. Was möchtest du uns damit eigentlich sagen, dass ein Rechner ohne PM nicht in den PM schalten kann und es somit besser wäre, ein RM-OS zu entwickeln für den Fall, das man gelegentlich auch mal solche exotische Retro-Hardware verwendet?

Dirk
33
Lowlevel-Coding / Re:C Kernel starten
« am: 21. June 2011, 16:09 »
Ich bleibe lieber im eigenen Wiki: http://www.lowlevel.eu/wiki/MS-DOS#Zugriff_auf_hohen_Speicher

Zitat
Extended Memory Blocks beginnen nach dem Ende der HMA. Die API erlaubt es, im erweiterten Speicher Blöcke zu reservieren, freizugeben und zu kopieren (die Speicherverwaltung schaltet dazu kurzzeitig in den Protected Mode).

Also nichts mit Real Mode.

Aber sicher doch mit dem Real Mode! Himem.sys verwalten den Speicher für den Real Mode und nicht für den Protect Mode und so kann man im RM sehr wohl mehr als die untersten 640 KByte an Speicher verwenden. Jedes Realmode OS welches einen vergleichbaren XMS-Extender verwendet, kann auch den gesamten verfügbaren oberen Speicherbereich für den RM verwalten. Das man den oberen Speicher vom RM aus nicht direkt adressieren kann ist hierbei völlig irrelevant. Auch wird hierbei ja nur kurzzeitig in den PM dafür geschaltet und dann wieder zurück in den Real Mode.

Dirk
34
Lowlevel-Coding / Re:C Kernel starten
« am: 21. June 2011, 14:04 »
.....Jeder Texteditor braucht ein OS, um zu laufen, aber wenn du einen Editor schreibst, wirst du nicht auf die Idee kommen, erst noch das passende OS dazu zu schreiben....

Wie jetzt, einen einfachen Texteditor kann man gar nicht ohne ein OS zur Ausführung bringen, wie kommst du denn auf diese Idee?

Zitat
Wenn du speichersparend programmieren willst, ist Real Mode übrigens nicht so toll: Von im Moment vielleicht 4096 MB Speicher, die ein Rechner hat, wirft dein OS allein durch die Einschränkungen des RM 4095 MB gleich mal weg.

Wer wirft denn im RM 4095 MByte Speicher weg?

Bereits seit MS-DOS 6.22 konnte HIMEM.SYS 64 MByte Speicher für den RM verwalten. Mit MS-DOS 7.0 (Windows 95) bereits 256 MByte und ab der Version 3.0 von Himem.sys (MS-DOS 7.1/Windows98) 4 GByte verwalten: http://de.wikipedia.org/wiki/Himem.sys

Dirk
35
Lowlevel-Coding / Re:BIOS-Interrupts
« am: 05. May 2011, 12:59 »
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?

Zitat
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.

Zitat
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:

Zitat
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).

Zitat
Zitat
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.

Zitat
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.

Zitat
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.)

Zitat
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.

Zitat
Die Genialität mit der absolute DAUs eine Software fehl bedienen können ist quasi unbegrenzt, ......

Das halte ich für leicht übertreiben dargestellt.

Zitat
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.

Zitat
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.

Zitat
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
36
Lowlevel-Coding / Re:BIOS-Interrupts
« am: 02. May 2011, 23:02 »
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.

Zitat
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.

Zitat
Ich hab mir mal die ersten 2 Google-Treffer zu "x86 loadall" angesehen:

http://www.rcollins.org/articles/loadall/tspec_a3_doc.html: da steht z.B.
Zitat
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?

Zitat
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.

Zitat
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?

Zitat
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?

Zitat
(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: 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.

Zitat
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.

Zitat
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?

Zitat
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.

Zitat
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.

Zitat
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.

Zitat
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.

Zitat
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.

Zitat
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.

Zitat
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.

Zitat
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.

Zitat
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.


Zitat
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
37
Lowlevel-Coding / Re:BIOS-Interrupts
« am: 02. May 2011, 10:42 »
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.

Zitat
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.

Zitat
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.

Zitat
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.

Zitat
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.

Zitat
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.

Zitat
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.

Zitat
Zitat
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.

Zitat
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
38
Lowlevel-Coding / Re:BIOS-Interrupts
« am: 29. April 2011, 02:45 »
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.

Zitat
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?

Zitat
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?

Zitat
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.

Zitat
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.

Zitat
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.

Zitat
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?

Zitat
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?

Zitat
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?

Zitat
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.

Zitat
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.

Zitat
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.

Zitat
aber HIMEM.SYS benutzt Deinen Block nicht für sich.

Braucht er ja auch nicht.

Zitat
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.

Zitat
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.

Zitat
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.

Zitat
.... 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.

Zitat
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.

Zitat
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
39
Lowlevel-Coding / Re:BIOS-Interrupts
« am: 28. April 2011, 18:47 »
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?

Zitat
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.

Zitat
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.

Zitat
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


Zitat
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.

Zitat
Auch arbeitet MS schon immer eng mit Intel und auch AMD zusammen.

Davon merkt man aber sehr wenig so verbugt wie Windows immer ist.

Zitat
Zitat
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.

Zitat
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.

Zitat
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)?

Zitat
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.

Zitat
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.

Zitat
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.

Zitat
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.

Zitat
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
40
Also ich benutze den GNU C Compiler, und ich hab jetzt ein bisschen recherchiert und rausgefunden, dass es beim gcc gar keine FAR LAbels oder Makros gibt :(

Danke an erik.vikinger, ich habe mich noch mal um die Segmentierung gekümmert, aber ich versteh das immer noch nicht so wirklich.
Mit einem 32-Bit Prozessor kann ich doch bis zu 4GB RAM direkt adressieren (also 0x00000000 bis 0xFFFFFFFF), und da ich im Realmode arbeite müsste ich doch jede beliebige Adresse per Zeiger erreichen können oder (also ohne Segmentierung)?

Tut mir Leid wenn das vielleicht eine ziemlich kiddiemäßige Frage zur Adressierung ist  :oops:

Im 16 Bit Realmode ist die 21. Adressleitung abgeschaltet und alle Segmente(ohne die man nicht adressieren kann) sind auf 64 Kib begrenzt.  Die jeweilige Adresse bildet sich aus dem Inhalt  eines 16 Bit Segmentregisters zusamen mit einem 16 Bit Offset. Auch wenn man 32 Bit Offsetregister zur Adressierung kombinieren kann muss man darauf achten, das die berechnete Adresse nicht das jeweilige 64 Kib grosse Segment überschreitet.

Dirk
Seiten: 1 [2] 3 4 5

Einloggen