Hallo,
Es ist aber ein Unterschied ob in ein (Schatten-)Register beim Reset ein bestimmter Wert geladen wird oder ob zur Laufzeit ein bestimmter Wert geladen wird, hängt mit dem physischen Aufbau der D-FlipFlops zusammen aus denen die Register zusammengesetzt sind. Sobald das erste mal CS neu geladen wird (also durch einen FAR-JMP/CALL) kommt eine normale RM-Basis in das zugehörige Schatten-Register (das Limit war ja schon vorher auf 64 kB).
Solch einen Unterschied im Verhalten der Schattenregister habe ich noch auf keinen der von mir benutzen 80386 bishin zu Core2-Architektur festellen können.
Was für einen Unterschied möchtest Du feststellen?
Ich möchte im Verhalten der Schatten-Register eigentlich gar keinen Unterschied feststellen. Ich bin nur überascht davon, das es dabei überhaupt einen Unterschied geben soll zwischen der Laufzeit und einem Reset.
Wie sich die Transistoren in den CPUs verhalten? Das folgt zum einen den Gesetzen der Physik und ist zum anderen so umfangreich das sich das nicht von außen betrachtet auf einzelne Transistoren runter brechen lässt.
Und wie macht sich der Unterschied im Verhalten der CPU programmtechnisch bemerkbar?
Welcher 80386+ soll sich denn hier anders verhalten, so das man ich nicht im Unrealmode betreiben kann?
Habe ich irgenwo geschrieben das ich eine 80386+ CPU kenne die den UnReal-Mode nicht unterstützt?
Abgeleitet von dem von dir erwähnten Unterschied zwischen den Schatten-Register einmal zur Laufzeit und einmal beim Reset erschien es mir naheliegend, das du hier auch ein abweichendes Verhalten bezüglich des Unrealmodes hättest andeuten können. Daher frage ich nun einmal gezielt nach, ob du das damit meintest. Wenn du das jedoch gar nicht so meintest, dann freue ich mich darüber.
Aber von welchen Unterschied redest du denn nun genau?
Ich weise lediglich darauf hin das diese Betriebsart nicht zugesichert wird und damit eine Unterstützung möglicherweise in Zukunft nicht mehr vorhanden sein könnte (wenn z.B. mal Transistoren gespart werden müssen).
Damit rechne ich auch das zukünftlige Rechner auch nicht mehr im RM starten und auch kein RM-Bios mehr mitbringen. Ich denke Rechner mit EFI-Bios sind bisher immer noch zweigleisig aufgebaut und bringen über den Kompatibilitätsmode auch den RM mit. Die Entwicklung geht aber ständig weiter. Doch es dauert noch eine Weile bis alle Retro-Museums-Rechner kaputt gehen und ganz genau so lange wird es auch den RM und auch den Unrealmode geben. Ich denke nicht das eine Sparmassnahme nur den Unrealmode verhindert, nicht aber den RM. Also wenn, dann geht beides nicht mehr, denn ich denke das es keine speziellen Transistoren nur für den Unrealmode gibt ganz ohne das sie nicht ebenso anders benutzt werden.
Ich benutze Computer nur rein privat.
Auch bei meinem privaten Computer ist für mich Zuverlässigkeit ein sehr wichtiges Kriterium.
Meine Unrealmode-Anwendungen laufen stets zu 100% zuverlässig. Das kann man von Windows und Anwendungen die dort laufen leider nicht immer behaupten, denn dafür ist selbst Windows 7 einfach immer noch zu fehlerhaft, als das man hier von einer hohen Zuverlässigkeit reden kann.
Wenn Du das für Dich persönlich anders entscheidest ist das völlig in Ordnung, aber deswegen kannst Du nicht auf andere schließen.
Aaaah, du möchtest damit andeuten das der Unrealmode weniger zuverlassig sein soll und stütz diese Vermutung einzig und alleine auf den Umstand das der Unrealmode nicht dokumentiert wurde, weil MS das Windows 95 damals vermarkten wollte und wie du schon sagtest sehr eng mit Intel und AMD zusammen arbeitet und man sich dann wohl darauf geeinigt hat, hier ein Mantel des Stillschweigens über den Unrealmode auszubreiten, obwohl MS den Unrealmode selber vor Jahren im Himem.sys benutzt hat und fast alle x86-Rechner damit betrieben wurden. Nun gut, wenn es das ist was dich zuverlässig werden läßt, ich stütze mich auf meine eigenen Erfahrungen und höre nicht
nur auf das was uns Großkonzerne veraten.
Nein du hast nicht gesagt das du einen 80386+ kennst bei dem der Unrealmode nicht funktioniert. Ich vermute nun das du keinen einzigen Rechner kennst bei dem der Unrealmode nicht funktioniert. Soweit zu der von dir erwarteten Zuverlässigkeit.
Es gab zwischen 1990-1995 DOS-Spiele die den Unrealmode benutzen.
Beispiele Bitte!
Es ist ja nicht gerade so das DOS-Spiele als Opensource den Markt überschwemmt haben.
So wüßte ich auch gerne mehr über die Spiele und kann dir leider auch kein konkretes Beispiel nennen.
Bei der gesetzlicher Gewährleistung darf ein Händler vorher noch nachbessern ....
Wenn es sich wirklich um eine Software handelt die den UnReal-Mode nutzt und meine x86-CPU den aber nicht unterstützt (egal aus welchen Grund) dann dürfte es schwer für den Händler werden ein funktionsfähiges Exemplar dieser Software aus dem Regal zu nehmen und das Nachbessern würde einem Neuentwickeln gleich kommen und das kostet unter Umständen sehr viel Geld.
Ja wenn der UnReal-Mode bei dir nicht funktioniert. Hast du eine funktionstüchtige Anwendung die den Unrealmode unterstützt auf deinem Rechner überhaupt schon einmal ausprobiert?
Leider kann ich nur den Sourcode von Version 2.06 finden in dem aber auf den Big Mode von Version 2.03 hingewiesen wird:
http://202.129.48.214/CD3003/Source/XMMAPI/XMS20/HIMEM.ASM
; 2.03 - Added 386 Big Mode MoveBlock 8/04/88
Okay, Microsoft hat also tatsächlich mal in einer Version von HIMEM.SYS den UnReal-Mode benutzt. Warum nur in einer Version? Gab es da etwa Probleme mit?
Soweit war ich noch gar nicht Suchen. Woraus wird denn ersichtlich das bereits in der nächsten Version der Unrealmode nicht mehr benutz wurde?
Ich spekuliere mal, die CPUs wurden immer schneller und es sollte mehr Protection geben, so das der V86-Mode immer beliebter wurde?
Ob der verantwortliche Programmierer, der das eingebaut hat, heute noch für MS arbeitet?
Nicht das es mich wirklich interessieren würde, aber arbeitet denn heute aus der damaligen Zeit überhaupt noch einer der damaligen Programmierer bei MS?
Von mir aus kann auf modernen CPUs auch gerne kompatibel mit Linux stehen, denn an derartige Plfichten brauche ich mich ja nicht gebunden fühlen.
Andere fühlen sich an solche Dinge gebunden. Z.B. Hersteller von Bankautomaten legen extrem großen Wert darauf die verwendete Hardware sehr gründlich zu validieren, die testen wirklich jeden einzelnen Rechen-Befehl in der verwendeten CPU damit die auch alle gehen und wenn die CPU in einer neuen Masken-Revision raus kommt wird noch mal von vorne Validiert. Das machen die (obwohl das viel Geld kostet) weil der Image-Verlust für die Bank (die diesen Automaten für sich einsetzt) durch eine Fehlbuchung deutlich schlimmer wäre.
[Ironie]Ok das überzeugt mich, das Betrügen mit rein virtuellen Werten an den Börsen ist sicherlich sehr viel einfacher, da es ja kaum jemand zu bemerken scheint. So ein minimaler Rechenfehler ist im Vergleich dazu natürlich sehr viel mehr beachtenswerter.[/Ironie]
Mal Spaß wieder beiseite, wir leben in einer Welt in der wir auf Computer nur sehr schwer wieder verzichten können. Da müssen wir uns ganz gewiss auf die Funktionsweise dieser Geräte auch verlassen können. Doch ich programmiere nur für rein private Zwecke und ich habe es auch zukünftig nicht vor einen gewerblichen Zweck damit zu erfüllen. So fühle ich mich auch in keinster Weise daran gebunden nur spezifizierte Verfahren zu benutzen. Ich vermute auch, das die meisten Programmierer ebenfalls nur aus rein privater Natur heraus Spaß daran haben ein klein wenig zu programmieren und diese brauchen für sich eben nicht wirklich eine so hohe Zuverlässigkeit das ihre Anwendung auf allen Rechner nur mit spezifizierten Verfahren läuft. Es genügt das es funktioniert, wir brauchen keinen Intel-Papst der unser Verfahren im nachherein noch segnet.
Welche Spiele nun genau den Unrealmode benutzten ist mir auch nicht bekannt. Es gab aber zahlreiche Spiele im Zeitraum von 1990 - 1995 die den Unrealmode benutzten, das ist allgemein bekannt.
Also mir ist davon nichts bekannt und ich hab in dieser Zeit viele Spiele ausprobiert (natürlich hab ich nicht in jedes reingesehen aber bei vielen hat man bekannte Anzeichen bestimmter DOS-Extender gefunden). Also von "allgemein bekannt" kann man da wirklich nicht reden. Ich will ja gar nicht bestreiten das es nicht doch einzelne kommerzielle Programme gab die den UnReal-Mode genutzt haben aber echte Bedeutung hatte davon sicher keines.
Genau davon ist aber die Rede das eine erhebliche Anzahl an DOS-Spiele im Zeitraum von 1990-1995 den Unrealmode benutzt haben.
Ich weiss nun nicht welche Spiele für dich überhaupt bedeutsam sind, oder einmal waren. Ich habe unter DOS eigentlich sehr wenig gespielt und eher programmiert. Auch fand ich DOS-Spiele bisher nie besonders reizvoll. Heute spiele ich sehr viele mehr mit dem Spiele-Windows, denn für alles Andere ist mir Windows einfach zu unsicher. Beruflich würde ich mich daher nie mit Windows beschäftigen wollen.
Hä, warum sollte man HIMEM.SYS (und darüber XMS-Speicher) nicht selber aktiv benutzen können (ohne EMS)?
Klar kannst Du den XMS selber aktiv benutzen (nachdem Du Deinen Block gelockt hast um auch seine physische Adresse zu kennen)
Ok, das meine ich.
aber HIMEM.SYS benutzt Deinen Block nicht für sich.
Braucht er ja auch nicht.
Im Vergleich zu einer linearen Adressierung im Unrealmode (beispielsweise über DS:Reg32) sind DOS-Extender aber nur sehr umständlich benutzbar.
Hast Du Dich denn damit schon mal wirklich richtig beschäftigt? Auf was für eigenen Erfahrungen beruht dieses Urteil von Dir?
Vor 10 Jahren hab ich einige große Programme mit Hilfe von verschiedenen DOS-Extendern entwickelt und das ist nicht schwieriger als würde man ein Programm für Windows oder für POSIX entwickeln, DOS-Extender sind einfach nur eine andere Laufzeitumgebung (mit spezifischen Schwächen aber auch Stärken).
Einfacher als selber den gesamten linearen Speicher im Unrealmode zu adressieren geht es nun mal nicht und bei der Verwendung von Speichermanager(ob nun XMS oder EMS) muss man Speicher erst relativ umständlich anfordern. Das kostet nicht nur Zeit, sondern bläht auch den gesamten Code auf, weit mehr als eine kleine Routine die in den Unrealmode schaltet und nur ein einziges Mal am Anfang angesprungen wird.
Es ist einfach unwichtig ob der LOADALL-Befehl je offiziell spezifiziert wurde, er war vorhanden und das genügt um zu zeigen das es für den Unrealmode eine Unterstützung gab die beabsichtigt implementiert wurde
Den LOADALL-Befehl gab es auch auf 286, hatten die etwa auch einen UnReal-Mode?
Mein erster PC war ein 80286er, nur leider kannte ich damals den Unrealmode noch nicht. Ich kann mir aber vorstellen das man damit im Unrealmode möglicherweise 16 MiB linear adressieren kann.
Das es den LOADALL-Befehl gab hat ganz sicher andere Gründe.
Wenn du dir hierbei so sicher bist, dann kanst du uns auch mögliche Gründe dafür nennen, anderfalls bist du dir eben auch nicht sicherer und spekulierst hier ebenso wie ich es jetzt tue.
.... Mir genügt das.
Es gibt Bereiche wo das nicht genügt. Wenn Du z.B. für ein medizinisches Gerät eine Zulassung haben möchtest und der Prüfer sieht das Du irgend ein Bauteil außerhalb der Spezifikation betreibst kannst Du Dir sicher sein das die Zulassung nicht allzu bald erteilt werden wird. Ich hab schon mal ein medizinisches Gerät durch den Zulassungsprozess begleitet (ich hab bei einer der Komponenten den FPGA-Inhalt und Teile des Schaltplans entwickelt) und das ist wahrlich kein Zuckerschlecken.
Das glaube ich dir.
Doch das dieser Zulassungsprozess keine Bauteile erlaubt welche nicht spezifiziert wurden, das sagt über die Zuverlässigkeit nicht spezifizierter Bauteile eigentlich überhaupt gar nichts aus, bzw. nur das sie möglicherweise wegen zu geringer Nachfrage noch keine Spezifikation bekamen. Auch wenn bestimmte Bauteile nicht vermarktet werden bedeutet das ja nicht in jedem Fall, das sie nur schlecht waren.
Eine Verantwortung für die Sachen die ich programmiert haben lehne ich grundsätzlich ab.
Alles darf jeder Anwender in völliger Eigenverantwortung benutzen.
Stell Dir vor Dein Stromanbieter würde das auch so handhaben.
Dieser Vergleich hinkt aber etwas. Ich bin zur Zeit kein Stromanbieter und wenn ich mal einer werden sollte, na dann bekommen alle Menschen von mir kostenlos Strom und am besten gleich vorort völlig dezentral und individuell so viel wie benötigt wird. Die Frage ist wohl wie lange es dauert so etwas zu entwickeln, wenn es keine Spezifikation von den Stromanbietern dafür gibt.
Ich bin mir sicher Du findest Dinge in Deinem Leben wo es Dir doch extrem wichtig ist das die 100% Zuverlässig funktionieren bzw. das die verantwortlichen Entwickler zumindest alles menschenmögliche Unternommen haben um die Zuverlässigkeit zu hoch wie nur irgend möglich zu bringen.
Sorry, aber solange Du so eine Meinung vertrittst hoffe ich wirklich das ich nie auf Dinge von Dir angewiesen bin.
Grüße
Erik
Hilfe nein, ich bin kein Mensch der nach 100 prozentiger Sicherheit sucht. So ein Denken ist mir eher fremd. Für mich ist die Freiheit auch mal nicht so sichere Dinge tun zu dürfen weit aus wichtiger als für einen Kontrollfreak. So einer bin ich ganz bestimmt nicht, auch wenn ich eine gewisse Ordnung in meinem Leben zu schätzen gelernt habe Ich würde mich jetzt auch nicht gerade aufdrängen wollen, so das du in irgendeiner Abhängigkeit auf mich angewiesen wärest.
100% Sicherheit ist für mich eh nur eine fiktive Illusion und dabei sollte man meiner Meinung nach schon abwägen können wie viele solcher Illusionen man verträgt ohne selber in eine Traumwelt abzudriften. Es ist noch gar nicht so lange Zeit her da hat man sich zur Tageschau einen Anzug angezogen und dem Sprecher auch mit einem Guten Abend begrüsst, so als wenn der Tagesschau-Sprecher jeden Zuschauer ganz persöhnlich hören und auch sehen könne. Im Nachherein klinkt das jetzt eher lustig, doch das war es in Wirklichkeit zu keiner Zeit. Damals wurde dann auch der Begriff einer Elektronenstrahl-Marionette gebildet, um so einen fremdgesteuerten Menschen zu beschreiben der unter einem zu grossem Einfluss von vorgesetzten Dingen steht und dabei völlig kritikunfähig sich verhält. Vergleichsweise wie Menschen die unter einer frühkindlichen Suggestiv-Erziehung bis ins hohe Alter an den Folgen davon leiden.
Dirk
Übersicht
Wiki
Hilfe
Suche
Einloggen
Registrieren
Drucken
Thema: BIOS-Interrupts (Gelesen 33696 mal)