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

[p80286]

Zitat:

Zitat von jaenicke (Beitrag 1326358)

Zitat:

Zitat von mael (Beitrag 1326325)

Ich wollte nur mal fragen ob hier noch Interesse besteht, so als Endspurtmotivation ;)

Absolut! Insbesondere das Feature eine interne Struktur, einen record aus Delphi z.B., auszuwerten, wäre Gold wert. ;-)

AuJa, wobei mir schon reichen würde, wenn ich die Struktur definieren würde und die Anzeige wäre entsprechend.

Gruß
K-H

[mael]

Vielen Dank für die positiven Rückmeldungen :D

Mein Ziel ist es jetzt eine stabile Version in 2 Wochen rauszubringen. Weitere Features sind daher für später.

[Luckie]

Mach weiter! Es ist ein schöner light-weight Hex-Editor. Ich bin Geocacher und wenn ich bei Mysteries, also Rätsel-Caches, Dateien untersuchen muss, ist er meine erste Wahl. Ich kenne eigentlich gar keinen anderen. :roll:

[mael]

Ich komme gut voran und in einer Woche sollte die Beta tatsächlich bereit stehen.

Die 64-Bit Version könnte etwas länger dauern, weil ich einige x87-Funktionen implementieren und testen muss (der 64-Bit Delphi-Compiler hat "praktischerweise" keinen Support für den Extended-Datentyp mehr, es ist aber der einzige Gleitkomma-Datentyp der Int64 verlustfrei speichern kann, und sehr nützlich um einiges zu berechnen.)

[jaenicke]

Zitat:

Zitat von mael (Beitrag 1327229)

der 64-Bit Delphi-Compiler hat "praktischerweise" keinen Support für den Extended-Datentyp mehr, es ist aber der einzige Datentyp der Int64 verlustfrei speichern kann, und sehr nützlich um einiges zu berechnen.

Nur rein interessehalber: Warum braucht man dafür einen 10 Byte Datentyp? Ich hatte bisher mit Int64 noch keine Probleme.

[mael]

Zitat:

Zitat von jaenicke (Beitrag 1327236)

Zitat:

Zitat von mael (Beitrag 1327229)

der 64-Bit Delphi-Compiler hat "praktischerweise" keinen Support für den Extended-Datentyp mehr, es ist aber der einzige Datentyp der Int64 verlustfrei speichern kann, und sehr nützlich um einiges zu berechnen.

Nur rein interessehalber: Warum braucht man dafür einen 10 Byte Datentyp? Ich hatte bisher mit Int64 noch keine Probleme.

Ich verwende auch fast überall Int64. Aber z.B. bei der Berechnung des Fortschritts geht das so nicht. Anstatt langwieriger Erklärungen hier mal Pseudocode (einige Sonderfälle nicht beachtet):

Delphi-Quellcode:

var
  MinPos, MaxPos, Range: Int64;
  ProgressStep: Extended; // Feld einer Klasse, keine lokale Variable
begin
  Range := MaxPos - MinPos; // Repräsentiert z.B. die minimal und maximal mögliche Position innerhalb einer Datei
  ProgressStep := Range / ProgressBar.Max;
end;

procedure SetProgressBarPos(Pos: Int64);
begin
  ProgressBar.Position := Round(Pos * ProgressStep);
end;

Bei ganzzahligen Operationen kann ProgressStep den Nachkommaanteil nicht speichern und sich dieser Fehler in SetProgressBarPos() stark "summieren".

Warum ich diese Skalierung überhaupt brauche? ProgressBars können höchstens Int32 verarbeiten, aber HxD kann Dateien über 4GiB darstellen. Ähnliches gilt für Scrollbars oder andere Positionsbestimmungen im Code die relativ zu etwas anderem sind.

[jaenicke]

Danke für die Erklärung.
Ja, so ein Problem hatte ich auch schon. Bei mir ließ sich das so lösen, dass ich die Zwischenberechnungen weggelassen habe und direkt nur am Ende alles so berechnet habe, dass keine zu großen Zahlen entstehen. Aber das geht natürlich nicht immer...

[mael]

Durch deine Frage ist mir ein Vergleich zu Arduino eingefallen, hatte nie genauer darüber nachgedacht.

Interessanter Weise hat die map()-Funktion dort ein paar Probleme, und ich dachte schon die löst das clever :/ :
http://www.jetmore.org/john/blog/201...-distribution/
http://forum.arduino.cc/index.php/topic,72153.0.html

[Blup]

Gerade beim Progressbar ist eine hohe Genauigkeit nicht erforderlich, mehr als 100 Positionen sind optisch kaum unterscheidbar.
Die Berechnung der neuen Progressbarposition darf sich dabei aber nur auf den neuen Absolutwert stützen.

Delphi-Quellcode:

{Die resultierende Position des Progressbar mit Wertebereich 0..1}
function NormalProgress(ACurrentPos, AMinPos, AMaxPos: Int64): Float;
begin
  Result := (ACurrentPos - AMinPos) / (AMaxPos - AMinPos);
end;

procedure SetProgressBarPos(APos, AMinPos, AMaxPos: Int64);
begin
  {z.B. Progressbar.Max = 100}
  ProgressBar.Position := Round(NormalProgress(Pos, AMinPos, AMaxPos) *  ProgressBar.Max);
end;

[mael]

Theoretisch sind so viele Stellen relevant wie Pixel am Schirm für den Fortschrittsbalken/Scrollleiste dargestellt werden, wird natürlich trotzdem < 10000 bleiben bei üblichen Auflösungen.

Aber das Problem ist auch die Rückkonvertierung, also aus der aktuellen Position der ScrollBar die Position innerhalb der Datei zu bestimmen. Ein Int64 kann nur näherungsweise in einem Double gespeichert werden. Da passiert es auch mal das hochgerundet wird und man dann nicht mehr in ein Int64 konvertieren kann, obwohl es gehen sollte. High(Int64) = 9223372036854775807 wird zu 9223372036854780000 wenn man es in ein Double konvertiert. Also größer als der größte Int64-Wert.

Delphi-Quellcode:

procedure FloatTests;
var
  i, i2: Int64;
  e: extended;
begin
  i := High(Int64);
  e := i;
  assert(e <= i); // wird nicht bemängelt obwohl eindeutig falsch unter x64
  i2 := Trunc(e); // erzeugt exception unter x64 (überlauf)
  assert(i = i2); // stimmt immer unter x86, egal welche Int64 man dem e zugewiesen hat
end;

Das könnte man vielleicht noch umgehen indem man zusichert dass der Double-Wert immer kleiner als der maximale Int64-Wert ist vor der Konvertierung.
Da Trunc und andere Rundungsmethoden aber alle Exceptions werfen, muss man also immer vorhersagen wann es (implizite) Rundungen geben könnte die den Wertebereich überschreiten. In diesem Fall wäre es problemlos bis High(Int64) - 512. 10-byte Extended hat das Problem nicht.


Also, so oder so, es sind deutlich mehr Prüfungen und Codereviews notwendig, da auch häufig mal implizit in Extended gerechnet wird in Delphi, wenn man keine expliziten Gleitkommatypen angibt. Also etwa sowas:

Delphi-Quellcode:

var
  i: Integer;
begin
  i := Round(i / 20);
end;