Thema: BIOS-Interrupts

[freecrac]

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

[DerHartmut]

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.

[erik.vikinger]

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

[Svenska]

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

[erik.vikinger]

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

[MNemo]

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

[Svenska]

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

[kevin]

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.

[MNemo]

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

[erik.vikinger]

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

[PNoob]

[ 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*§$&

[kevin]

[ 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*§$&

[freecrac]

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.

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

[DerHartmut]

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.

[Svenska]

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

[erik.vikinger]

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