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

[mael]

Vielen Dank für die positiven Rückmeldungen

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.

[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 von mael:

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

Zitat von mael:

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