|
DEUTSCHE VERSION |
|
 |
| Links | | | Forums | | | Comments | | | Report news |
|
| Chat | | | Polls | | | Newsticker | | | Archive |
|
| amiga-news.de Forum > Amiga, AmigaOS 4 > OS3.9 AnzeigeBugs | [ - Search - New posts - Register - Login - ] |
| -1- 2 | [ - Post reply - ] |
|
2006-04-30, 18:16 h Stefan Posts: 936 User |
Hallo, Folgendes ist mir aufgefallen. Ich habe hier offensichtlich Anzeigebugs in der Titel bzw. Füllstandsanzeige von Fenstern und das betrifft nur die grossen Partitionen. Bild: http://people.freenet.de/smoebius/ami/Bugs/Anzeige-Bug_01.png Bild: http://people.freenet.de/smoebius/ami/Bugs/Anzeige-Bug_02.png Ändere ich die Fenstergröße auf wirklich sehr klein, stimmt zumindest die Füllstandsanzeige wieder. Bild: http://people.freenet.de/smoebius/ami/Bugs/Richtig_01.png ClassAction gibt den richtigen Wert aus. Bild: http://people.freenet.de/smoebius/ami/Bugs/Richtig_02.png Das ist zwar nur ein kosmetischer Fehler, aber kann das jemand bestätigen oder auch dementieren? Dann könnte die Fehlerursache auch bei mir liegen. Gruß Stefan  [ Dieser Beitrag wurde von Stefan am 16.05.2007 um 17:31 Uhr geändert. ] [ - Answer - Quote - Direct link - ] |
|
2006-04-30, 18:29 h Brunadi Posts: 1365 User |
@Stefan: Ich habe jetzt mal die Füllstandsanzeige eingeschaltet, ist alles in Ordnung, egal ob Fenster groß oder klein. Gruß Brunadi  -- http://brunadi.8ung.at [ - Answer - Quote - Direct link - ] |
|
2006-04-30, 18:31 h Stefan Posts: 936 User |
Zitat: Und die Titelzeile der Fenster? [ - Answer - Quote - Direct link - ] |
|
2006-04-30, 18:35 h Brunadi Posts: 1365 User |
@Stefan: Die Werte in der Titelzeile stimmen auch. Dazu muß ich noch sagen, so große Partitionen habe ich nicht. Meine Festplatte hat im ganzen 20 GB. Gruß Brunadi -- http://brunadi.8ung.at [ Dieser Beitrag wurde von Brunadi am 30.04.2006 um 18:37 Uhr geändert. ] [ - Answer - Quote - Direct link - ] |
|
2006-04-30, 18:44 h R-TEAM Posts: 1030 User |
Hi, WOW ! Ist mir noch nie aufgefallen ... Habe das auch .. muss aber die fenster weit größer machen das der bug auftritt .. und hängt nur von der höhe ab ! Die breite ist egal ... könnte sein das es bei einen bestimmten WB/Screen<>Fenster/Höhe ratio auftritt ?? Oder muß ich die fenster so groß ziehen wegen CyGFX .. ? Aber echt noch nie aufgefallen .. habe normal meine laufwerks fenster nicht sooo groß  Grüße R-TEAM -- My Hardware Config and GFX-Work on my HomePage. Fax : (+49) 09191 702028 Long Live T H E [|D|A|R|K^><^E|M|P|I|R|E|] [ - Answer - Quote - Direct link - ] |
|
2006-05-01, 07:50 h Stefan Posts: 936 User |
Zitat: Das ist auch noch eine Frage, ob die Füllstandzeige etwas mit der Auflösung zu tun hat. Aber selbst wenn das sein **Edit: Habe jetzt mal die WB in PAL-Hires gebootet, keine Änderung --> Auflösung spielt keine Rolle.** könnte, erklärt es nicht die falschen Werte in der Titelzeile der Fenster. Und wie schon geschrieben, es tritt bei mir nur auf den grossen Partitionen auf, weder bei der 2 GB, 3 GB oder 8 GB ist der Fehler. Ich fahre hier ein Auflösung von 1024x768x16 mit CGX 4.2, cgxsystem.library 42.7, BVision (ShowcgxConfig gibt aus DriverVersion 4.3). Auch das Deaktivieren von WBStartup + auskommentieren von Sachen in der Startup und User-Startup ändert nichts. Gruß Stefan [ Dieser Beitrag wurde von Stefan am 01.05.2006 um 08:01 Uhr geändert. ] [ - Answer - Quote - Direct link - ] |
|
2006-05-01, 09:56 h GREX Posts: 509 User |
Interessant, das ist mir auch noch nie aufgefallen. Habe das Problem auch nur bei meiner 65 GB Partition. Das mit den Titelzeilen kann ich aber nicht nachvollziehen, die Angaben stimmen bei mir. Schätze also, dass dein Problem mit der Größenangabe vielleicht ganz andere Ursachen als das Problem mit der Füllstandsanzeige hat. Hast du beide Boingbags installiert? [ - Answer - Quote - Direct link - ] |
|
2006-05-01, 10:28 h MaikG Posts: 5172 User |
Hab nur 25 GB Partionen, da tritt es nicht auf. Kannst ja mal die letzte workbench.library aus dem Aminet probieren vielleicht behebt die den Bug. [ - Answer - Quote - Direct link - ] |
|
2006-05-01, 10:59 h Stefan Posts: 936 User |
@ Ich habe beide BoingBags + die inoff. Updates aus dem Aminet + andere Updates (Shell, Ram-handler) installiert. workbench.library 45.131 (15-04-2006) icon.library 45.4 (24-01-2006) Gruß Stefan [ - Answer - Quote - Direct link - ] |
|
2006-05-01, 18:31 h MaikG Posts: 5172 User |
>Ich habe beide BoingBags + die inoff. Updates aus dem Aminet >+ andere Updates (Shell, Ram-handler) installiert. >workbench.library 45.131 (15-04-2006) >icon.library 45.4 (24-01-2006) Probiere es mal mit den Originalen Librarys, die neuen hatten früher schon einige Bugs, evtl. sind da nochmehr. [ - Answer - Quote - Direct link - ] |
|
2006-05-01, 18:49 h Stefan Posts: 936 User |
Zitat: Bringt keine Änderung. [ - Answer - Quote - Direct link - ] |
|
2006-05-01, 20:12 h Holger Posts: 8116 User |
Zitat: Es handelt sich offensichtlich um einen Überlauf bei Integer Arithmetik. Zur Berechnung der Füllstandsanzeige rechnet man üblicherweise x=belegte Blöcke * Fensterhöhe / Gesamtgröße der Partition. Genaugenommen nimmt man nicht die Fensterhöhe, sondern die Höhe der Füllstandsanzeige, sprich abzüglich des Fensterrahmens. Alternativ kann man statt der belegten Blöcke auch die freien Blöcke benutzen, je nach dem wie das Ding am Ende gezeichnet wird. Da hier ein 3D-Rahmen für die belegten in den Gesamtrahmen gezeichnet wird, wird vermutlich dessen Höhe berechnet. Charakteristisch ist aber in jedem Fall, daß zuerst multipliziert und dann dividiert wird, weil sonst aufgrund der fehlenden Nachkommastellen immer null rauskommen würde. Wenn das Ergebnis der Multiplikation größer als der maximale Integerbereich ist, gibt's einen Überlauf und es kommt ein wesentlich kleinerer Wert heraus. Die Frage ist jetzt nur, in welcher Einheit die Workbench hierbei rechnet kB, MB oder Blöcke, wobei im letzteren Fall die Frage nach der Blockgröße entscheidend ist. Hat man also 26 GB belegten Platz und ist die Einheit 1kB wären das 27262976 Einheiten. Der int-Bereich verkraftet Zahlen kleiner als 4294967296, das heißt, der Überlauf entsteht, sobald die Füllstandsanzeige eine Höhe von 4294967296 / 27262976 = 157 Pixel überschreitet. Hängt wie gesagt, von der Größe der Einheit, dem belegten Platz und der Fensterhöhe ab, aber auch davon, ob die workbench, wie hier angenommen mit unsigned int arbeitet. Bei signed int würde sich der Schwellwert noch mal halbieren. mfg -- Good coders do not comment. What was hard to write should be hard to read too. [ - Answer - Quote - Direct link - ] |
|
2006-05-01, 20:26 h Holger Posts: 8116 User |
Ähnliches gilt natürlich auch für die Prozentangabe in der Titelzeile. Da hier der Gesamtwert 100 ist, kann man ziemlich eindeutig zurückrechnen, daß der Überlauf bei den typisch 512 byte großen Blöcken bei einem belegtem Platz ab 20,48 GB stattfindet. Das scheint mit den Screenshots übereinzustimmen. mfg -- Good coders do not comment. What was hard to write should be hard to read too. [ - Answer - Quote - Direct link - ] |
|
2006-05-01, 21:13 h whose Posts: 2156 User |
@Holger: Schon darauf gekommen, daß es sich hier um AmigaOS < V 4.0 handelt? Natürlich gibt es da bei der Workbench einen Überlauf-Fehler, wenn die Partitionsgrößen 2GB überschreiten. Da die Workbench immer noch mit der guten, alten dos.library zusammenarbeitet, wird auch hier (intern) mit einem vorzeichenbehafteten 32 Bit-Wert für die Anzahl der belegten/freien Blöcke gearbeitet. Immerhin war man schon so schlau, der Workbench eine ausschließlich auf positive Zahlen ausgelegte Ausgabe mitzugeben, sonst hätts statt der merkwürdigen Anzeige evtl. einen Knall gegeben (z.B. wenn die Füllstandsanzeige "nach unten aus dem Fenster gelaufen" wäre). Dieser "Bug" ist aber schon länger bekannt und es steht immer noch geschrieben, daß Partitionsgrößen >2GB unter AmigaOS bis einschließlich Version 3.9 grundsätzlich keine gute Idee sind. Prinzipiell funktioniert das Ganze zwar auch mit größeren Partitionen, die Größenangaben, die von der dos.library stammen, sind nichts desto trotz mit größter Vorsicht zu genießen. So lange die dos.library und/oder die Workbench für AmigaOS Version 3.x nicht runderneuert werden, wird sich an der merkwürdigen Anzeige der Workbench (und anderer Programme) für Partitionen jenseits der 2GB (bzw. >2G Blockanzahl) nichts ändern. @Stefan: Schau doch mal, was "info (Partitionsname):" im CLI so ergibt. Jede Wette, für die große Partitionen erscheinen negative Größenangaben. Genau aus dem Grund habe ich meine Platten nur noch mit Partitionen bis 2GB eingerichtet. Weil mir die seltsamen Größenangaben auf den Geist gingen Grüße -- --- µA1 PPC 750GX-800 A4000 PPC 604e-233[ Dieser Beitrag wurde von whose am 01.05.2006 um 21:32 Uhr geändert. ] [ - Answer - Quote - Direct link - ] |
|
2006-05-01, 21:42 h Brunadi Posts: 1365 User |
@whose: Bei mir zeigt info Partit. folgendes an: Size = MB used = Blöcke free = Blöcke Gruß Brunadi -- http://brunadi.8ung.at [ - Answer - Quote - Direct link - ] |
|
2006-05-01, 21:47 h whose Posts: 2156 User |
@Brunadi: Soso... ganz ohne Zahlenangaben dazu? Bei mir zeigts bei Partitionen >2GB negative Zahlen bei den Blockangaben Grüße -- --- µA1 PPC 750GX-800 A4000 PPC 604e-233[ - Answer - Quote - Direct link - ] |
|
2006-05-01, 21:58 h Brunadi Posts: 1365 User |
@whose: So stehts ganz genau: Unit DHB: Size 6258 MB Used 3022025 Free 9795700 Full 24% Errs 0 Status Read/Write Name Backup Natürlich nebeneinander. Ganz korrekt werden die Werte nur in OpusMagellan bei Datenträger- Information angezeigt. Gruß Brunadi -- http://brunadi.8ung.at [ Dieser Beitrag wurde von Brunadi am 01.05.2006 um 22:03 Uhr geändert. ] [ - Answer - Quote - Direct link - ] |
|
2006-05-01, 22:03 h malte2 Posts: 148 User |
@whose: Du kannst problemlos Partitionen größer 2GB unter OS3.5/9 anlegen. Nur deine Bootpartition darf nicht größer 2GB sein, da von dort die neuen Treiber geladen werden müssen. Max. Partitionsgröße und max. Dateigröße sind zwei Paar Schuhe... Was die Füllstandsanzeige angeht, so ist dort offentsichtlich ein "Overflow-Fehler" drin. Die textuelle Anzeige sollte korrekt sein, da Olaf Barthel damals 64bit Mathe eingebaut hatte. [ - Answer - Quote - Direct link - ] |
|
2006-05-01, 22:06 h whose Posts: 2156 User |
@Brunadi: Meine ich doch Hast 2KB-Blöcke verwendet, also gehts bei Dir bis 8GB Partitionsgröße gut Magellan verwendet eigene Routinen für diesen Zweck, genau wie z.B. Diavolo Backup 2000 und ein paar andere Programme. Grüße -- --- µA1 PPC 750GX-800 A4000 PPC 604e-233[ - Answer - Quote - Direct link - ] |
|
2006-05-01, 22:14 h whose Posts: 2156 User |
@malte2: Wenn Du nochmal genau liest, siehst Du, daß ich das erwähnt habe. Es ist halt nur keine besonders gute Idee das zu tun weils ältere Programme in den Fuß schießt (u.A. ältere Installer-Versionen). Soweit ich mich erinnern kann, war die Füllstandsanzeige ein reaktiviertes Goodie, an dem er, wegen der komplizierten "Verdrahtung" der WB, keine größeren Änderungen vornehmen wollte. Wie auch immer, bei Blockangaben, die >2G geraten, gibts massig Probleme mit dem Vorzeichen. Grüße -- --- µA1 PPC 750GX-800 A4000 PPC 604e-233[ Dieser Beitrag wurde von whose am 01.05.2006 um 22:18 Uhr geändert. ] [ - Answer - Quote - Direct link - ] |
|
2006-05-02, 08:10 h thomas Posts: 7718 User |
Zitat: Das ist, mit Verlaub gesagt, Blödsinn. Du schreibst es selbst: es wird mit der Anzahl Blöcke gearbeitet. Selbst mit vorzeichenbehafteten Zahlen kann man mit 2 hoch 31 Blöcken a 512 Bytes immerhin 1 TB Daten speichern, so große Festplatten gibt es noch gar nicht. Wenn man in der Anwendung (hier: Workbench) berücksichtigt, daß es Partitionen größer als 2GB gibt, kann man auch mit der guten, alten dos.library die Werte korrekt angeben. Sogar mit 32bit-Arithmetik. Vielleicht nicht die genaue Anzahl Bytes, aber für Kilobytes oder gar Megabytes reicht es vollkommen. Und für eine korrekte Grafik, die gerade mal einige hundert Pixel hoch ist, allemal. Gruß Thomas -- Email: thomas-rapp@web.de Home: thomas-rapp.homepage.t-online.de/ [ - Answer - Quote - Direct link - ] |
|
2006-05-02, 09:13 h Stefan Posts: 936 User |
@whose >Immerhin war man schon so schlau, der Workbench eine ausschließlich >auf positive Zahlen ausgelegte Ausgabe mitzugeben, sonst hätts statt >der merkwürdigen Anzeige evtl. einen Knall gegeben (z.B. wenn die >Füllstandsanzeige "nach unten aus dem Fenster gelaufen" wäre). Du machst mir Angst , nicht das sich wirklich irgendwann auf Grunddes Fehlers meine Partitionen ins Nirvana verabschieden. >Schau doch mal, was "info (Partitionsname):" im CLI so ergibt. Jede >Wette, für die große Partitionen erscheinen negative Größenangaben. SDH1: 33G 31344834 38098854 45% 0 Read/Write Daten MDH0: 40G 55867732 28965306 66% 0 Read/Write Multimedia Das passt, dafür finde ich die Ausgaben von SimpleFinds Requester sehr interessant. Eine wunderschöne Ausgabe  , das aber stört Bild: http://people.freenet.de/smoebius/amiga/Bugs/SimpleFind.png kaum, denn den Requester verwende ich nicht. Irgendein CLI-Only Tool zeigte auch falsche Werte. Ich weiss nur nicht mehr, welches Tool es war, vielleicht finde ich es wieder. @ Folgendes verstehe ich aber nicht. GREX schrieb: |Habe das Problem auch nur bei meiner 65 GB Partition. |Das mit den Titelzeilen kann ich aber nicht nachvollziehen, |die Angaben stimmen bei mir. Bei mir stimmt aber auch die Titelzeile nicht!  Gruß Stefan [ - Answer - Quote - Direct link - ] |
|
2006-05-02, 10:04 h GREX Posts: 509 User |
Bei mir gibt info folgendes aus. Ich muss aber dazusagen, dass ich auch eine Blockgröße von 1024 verwende, vielleicht kommt der Bug also noch, wenn sich die Platte weiterfüllt. Ich weiß nicht, ob das eine Rolle spielt, aber ich wollte auch darauf hinweisen, dass ich mir die Platte (eine 80 GB Western Digital) gekauft habe, als bei mir schon OS3.9 BB2 installiert war. Soll heißen, sie ist von Anfang an mit den neuesten Programen/Treibern des OS eingerichtet worden. Dh3 bzw. Pcc sind übrigens für die Mac bzw. Pc-Emulation (pcc geht aber nicht mit PCx/PC Task, die müsste wohl unterhalb der 4 GB liegen; dh3 geht problemlos mit Fusion 3.2). Mounted disks: Unit Size Used Free Full Errs Status Name CD0: No disk present RAM: 892K 892 0 100% 0 Read/Write Ram Disk DH0: 1101M 985995 141955 87% 0 Read/Write AmigaOS DF0: No disk present DH1: 4036M 1408090 2725716 34% 0 Read/Write WORK DH2: 65G 11205266 57924884 16% 0 Read/Write FUN DH3: Unreadable disk PCC: Unreadable disk [ Dieser Beitrag wurde von GREX am 02.05.2006 um 10:05 Uhr geändert. ] [ - Answer - Quote - Direct link - ] |
|
2006-05-02, 10:10 h MaikG Posts: 5172 User |
>Meine ich doch Hast 2KB-Blöcke verwendet, also gehts bei Dir >bis 8GB Partitionsgröße gut Ich hab auf der einen 2k und auf der anderen 4k. Beide 25 GB, keine Probleme. [ - Answer - Quote - Direct link - ] |
|
2006-05-02, 11:12 h thomas Posts: 7718 User |
Du kannst auch 512 Byte-Blöcke benutzen, kein Problem. Info wird auch die richtige Daten ausgeben. Es wurde mit OS3.9 ja entsprechend angepaßt (alle CLI-Programme wurden angepaßt). Darüberhinaus brauchst du, wie gesagt, eine Partition von 1 Terabyte Größe, um auf die 2 hoch 31 Blöcke zu kommen, die negativ angezeigt würden. Bei 512 Byte-Blöcken. Mit 2K-Blöcken müssen es 4 TB sein ! Auf *einer* Partition ! Gruß Thomas -- Email: thomas-rapp@web.de Home: thomas-rapp.homepage.t-online.de/ [ - Answer - Quote - Direct link - ] |
|
2006-05-02, 17:39 h Holger Posts: 8116 User |
Zitat:Danke für die Richtigstellung, so kann ich mir Tipparbeit sparen  ...und wenn man dann noch die Blockgröße erhöht, ändert sich am Code (und somit an der Kompatiblität) gar nichts. Zitat:Vollkommen richtig. Bei der Prozentwertberechnung sind es genau 100, die es zu berücksichtigen gilt. Wie wir ja beim Einsetzen des Fehlers bei ~20GB erkennen können, wird hier vorzeichenlos (bei 512 byte-Blöcken) gerechnet, das sind ja ~2TB / 100. Selbst bei maximaler Grafikgröße würde das noch funktionieren, da AmigaOS Screengrößen in 16Bit speichert. Allerdings würde das die Berechnung etwas komplizierter machen und letztendlich (fast) den gleichen Code erzeugen, als wenn man 64Bit Datentypen benutzt und den Compiler machen läßt... Zumal diese Stelle gewiß nicht performancerelevant ist. Zitat:Hab ich doch schon erklärt, das hängt von der verwendeten Blockgröße ab. Je größer die Blöcke, desto später setzt der Fehler ein. Bei doppelt so großen Blöcken tritt der Fehler also nicht bei 20GB, sondern ab 40 GB belegtem Partitionsplatz auf. mfg -- Good coders do not comment. What was hard to write should be hard to read too. [ - Answer - Quote - Direct link - ] |
|
2006-05-02, 17:51 h Holger Posts: 8116 User |
Zitat:Der Überlauf der Füllstandsanzeige bzw. der Prozentangabe entsteht durch die Multiplikation von belegter Blockanzahl mit dem Grundwert, also >100< bei Prozentangaben und >Pixelhöhe< bei der Füllstandsanzeige. Durch die Gesamtanzahl wird nur dividiert. Bei 2k-Blöcken gibt's also bei der Prozentanzeige erst Probleme, wenn a) der belegte Platz 81 GB oder die Gesamtgröße 8 TB überschreitet. Bei 4k-Blöcken verdoppelt sich diese Zahl. Für die Füllstandsanzeige gelten die gleichen Werte, wenn sie 100 Pixel groß ist. Für jede Verdoppelung der Fensterhöhe halbiert sich der Grenzwert für den belegten Platz (Grenzwert für Gesamtgröße ändert sich nicht), usw. mfg -- Good coders do not comment. What was hard to write should be hard to read too. [ - Answer - Quote - Direct link - ] |
|
2006-05-02, 18:10 h bubblebobble Posts: 707 User |
Der Fehler ist mir auch schon öfters aufgefallen. Grund zur Panik besteht aber nicht. Ich habe Partitionen über 60GB und keine Probleme. Das ist nur die Anzeige. Die dos.library gibt soweit ich damit gearbeitet habe nie die Größe oder Füllstand in Bytes aus, sondern immer nur in Blöcken, und dazu die Blockgröße. Ältere Programme machen oft den Fehler, diese zwei 32Bit Zahlen einfach miteinander zu multiplizieren, das geht dann ab 2 oder 4GB schief. Bei der WB anzeige wird vermutlich auch erstmal mit der Fensterhöhe multipliziert, was dann leicht überläuft. Da sollte man erstmal durch 1024 oder 1024*1024 Teilen, so genau muss es ja nicht sein. Oder 64 bit verwenden, oder einen tollen Trick mit Rest: Das berechnet result = x * a / b, wobei x*a bis zu 48 bit verbrauchen kann. a und b müssen kleiner als 16 bit sein. q = x / b r = x-q*b result = a*q + (r*a/ b) -- Thilo Köhler, Author von: HD-Rec, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, TKUnpacker Homepage: http://www.hd-rec.de [ - Answer - Quote - Direct link - ] |
|
2006-05-02, 22:28 h whose Posts: 2156 User |
@thomas: >Das ist, mit Verlaub gesagt, Blödsinn. Du schreibst es selbst: es wird mit der Anzahl Blöcke gearbeitet. >Selbst mit vorzeichenbehafteten Zahlen kann man mit 2 hoch 31 Blöcken a 512 Bytes immerhin 1 TB >Daten speichern, so große Festplatten gibt es noch gar nicht. Wenn man in der Anwendung (hier: Workbench) >berücksichtigt, daß es Partitionen größer als 2GB gibt, kann man auch mit der guten, alten dos.library die >Werte korrekt angeben. Sogar mit 32bit-Arithmetik. Vielleicht nicht die genaue Anzahl Bytes, aber für >Kilobytes oder gar Megabytes reicht es vollkommen. Und für eine korrekte Grafik, die gerade mal einige >hundert Pixel hoch ist, allemal. Ist es nicht, wenn man die historischen Gegebenheiten berücksichtigt. Wie "Schlaumeier" Holger schon (wieder)entdeckt hat, ist es eben doch ein Problem mit vorzeichenbehafteter Arithmetik. Die stammt immer noch von der dos.library, mit der der Unfug ihren Anfang nahm. Sicher kann man mit der Blockanzahl unglaublich große Partitionen darstellen bzw. ihre Größen wiedergeben, nur rechnen läßt sich damit sehr schlecht, erst Recht, wenn man in uraltem Assemblercode rumdoktern muß (Workbench). Mir ist bekannt, daß das eigentliche Partitionsgrößenproblem vom scsi.device bzw. allen anderen devices für blockorientierte Medien stammt und mit dem NSD Patch bzw. TD64 behoben wurde. Hast Du Dir übrigens mal das info der Erstausgabe von OS3.9 und dessen Ausgabe angesehen? @Holger: >Danke für die Richtigstellung, so kann ich mir Tipparbeit sparen Leider sparst Du Dir auch mal wieder Denkarbeit, sonst würde es die Diskussion nicht geben. Wie ich schon sagte, ist der Anzeige"bug" (der eigentlich keiner ist) schon ziemlich lange bekannt. Wo das Problem herrührt ist ebenfalls bekannt, wird aber halt nicht mehr beseitigt (weder die eine Ursache (dos.library, vorzeichenbehafteter Wert) noch die andere (Workbench und deren Nichtbeachtung des Vorzeichenproblems bei der Füllstandsanzeige, die im Code schlicht "reaktiviert" wurde, also technisch von 1986 stammt). Der "Fehler" ist da, wird für OS3.9 voraussichtlich nicht mehr behoben, der ist nicht lebensbedrohlich. Nur nervig. Grüße -- --- µA1 PPC 750GX-800 A4000 PPC 604e-233[ - Answer - Quote - Direct link - ] |
|
2006-05-02, 22:39 h whose Posts: 2156 User |
Zitat: Quatsch, da passiert nix mit. Im "schlimmsten" Fall (der ja nicht eintreten wird), würde der Amiga halt recht effektvoll abstürzen, weil beim Zeichnen der Füllstandsanzeige außerhalb des Fensters "rumgemalt" würde. Das passiert aber, wie gesagt, nicht.  Zitat: Ok, dann besitzt Du entweder OS3.9 zweite Ausgabe oder hast alle BoingBags installiert. Das wollte ich u.A. wissen wegen Deiner "verbogenen" Titelzeilenanzeige. Kannst Du mal bitte schauen, welche Version bei Dir für die workbench.library ausgegeben wird? Zitat: Da gibt es noch einige. Und diverse Programme, die Dich einiges nicht speichern lassen wollen. Das ist aber meist recht altes Geraffel, das kaum noch in Gebrauch ist. Zitat: Deswegen schau doch mal nach, welche workbench.library bei Dir zum Einsatz kommt. Hast Du das ROM Update komplett abgeschaltet evtl.? Edit: Hab gerade gesehen, daß Du die Patches aus dem Aminet für die workbench.library installiert hattest. Ist das ROM Update denn bei Dir aktiv? Grüße -- --- µA1 PPC 750GX-800 A4000 PPC 604e-233[ Dieser Beitrag wurde von whose am 02.05.2006 um 23:19 Uhr geändert. ] [ - Answer - Quote - Direct link - ] |
| -1- 2 | [ - Post reply - ] |
| amiga-news.de Forum > Amiga, AmigaOS 4 > OS3.9 AnzeigeBugs | [ - Search - New posts - Register - Login - ] |
|
|
Masthead |
Privacy policy |
Netiquette |
Advertising |
Contact
Copyright © 1998-2024 by amiga-news.de - all rights reserved. |
|
