Einzelnen Beitrag anzeigen

Benutzerbild von mael
mael

Registriert seit: 13. Jan 2005
391 Beiträge
 
Delphi XE3 Professional
 
#333

AW: HxD - schneller Hexeditor, Disk-Editor und RAM-Editor

  Alt 19. Jan 2016, 17:24
Zitat:
Aber das Problem ist auch die Rückkonvertierung, also aus der aktuellen Position der ScrollBar die Position innerhalb der Datei zu bestimmen.
Moment. Um den Fortschritt anzeigen zu können, musst du doch schon vorher wissen an welcher Position du in der Datei bist. Was muss man da wieder zurück konvertieren? Oder habe ich hier jetzt ein Verständnisproblem?
Ich bin da vielleicht etwas konfus in meiner Beschreibung. Fortschrittsanzeige und ScrollBars haben nicht direkt was miteinander zu tun, haben nur verwandte Probleme insofern dass ich Gleitkommazahlen benötige.

Wenn ich mit der ScrollBar Thumbtracking mache (also diesen "Schieber" die Leiste entlangbewege -- Hey! Schiebeleiste wäre doch eine gute Übersetzung für ScrollBar... naja Bildlaufleiste gibt es ja schon, oder Rollleiste wäre eine Idee, hört sich aber komisch an, dann wäre der "Schieber" ein "Roller"... Übersetzungen sind immer so eine Sache ).

Also, wenn man den "Schieber" die Bildlaufleiste entlangbewegt kann man so eine Art wahlfreien Zugriff (random access) auf die Datei erzeugen. Abhängig davon wo man den Schieber mit der Maus hinbewegt und wie schnell kann es deutliche Sprünge von TScrollBar.Position geben. Man kann also nicht wie beim Klicken der "Hoch"/"Runter"-Knöpfe oder Scrollen per Mausrad schrittweise inkrementieren und so das Problem umgehen.

Also muss sowas in der Art berechnet werden:
DateiPosition := Round(ScrollBar.Position * Skalierungsfaktor);
Kommst du überhaupt in diesen Größenbereich?

RAM und Festplatten/Dateigrößen im Bereich von paar Exabyte.
Ist natürlich ein berechtigter Einwand. Hätte halt gerne vermieden solche Abschätzungen machen zu müssen ab wann ich Probleme mit Doubles bekomme.

Theoretisch ist die Grenze des virtuellen Arbeitsspeichers 8 EiB, praktisch ist er momentan unter Windows bei 8TiB bzw. 128 TiB (Memory Limits for Windows and Windows Server Releases).
D.h. momentan sind alle virtuellen Adressen <= $800000000000 (128TiB). $8000000000000000 (8EiB) ist $10000 mal größer als 128TiB. 128TiB würde also wohl noch in einen Double passen. Hmm, wäre also zumindest für den Moment kein Problem. Zukunftssicher wäre natürlich schöner.

P.S.: Man kann die hohen Adressen auch nicht in den meisten Fällen ignorieren da dort die System-Dlls geladen werden oder auch Programme vom Speicherallozierer fordern können Speicher in hohen Adressen zu bekommen (also vom Maximum abwärts "wachsend").
HxD, schneller Hexeditor:
http://mh-nexus.de/hxd

Geändert von mael (19. Jan 2016 um 17:48 Uhr) Grund: Falscher Wert für 128TiB angegeben
  Mit Zitat antworten Zitat