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

[mael]

Neue Version 2.4 (28.2.2020), siehe letzten Post

Links setzen
Wem mein Programm HxD gefällt, der kann gerne einen Link auf meine Seite ( http://mh-nexus.de/hxd/ ) setzen.

Beschreibung
HxD ist ein schneller Hexeditor, den ich jetzt schon eine Zeit lang entwickle.

Den Hexeditor habe ich komplett selbst geschrieben, er basiert nicht auf einem TCustomGrid oder Ähnlichem. (Also alles außer ToolBar2000/TBX und den Digests (SHA-1, MD-5,...))

Kurzer Funktionsüberblick:

• Öffnen/Bearbeiten von Dateien beliebiger Größe (auch > 4GB)
• Diskeditor zum direkten Lesen/Schreiben auf Festplatten, Disketten, USB-Sticks,... (WinNT und Win9x)
• RAM-Editor zum Lesen/Schreiben des virtuellen Arbeitsspeichers anderer Prozesse/Programme (inkl. Data-Folding)
• Schnelle Suchfunktion für Text (inkl. Unicode), Hex-Werte, Ganze Zahlen oder Gleitkommazahlen
• Ersetzenfunktion (schnell, auch für Millionen Ersetzungen)
• Bytes einfügen/Bereich füllen
• Dateien zerlegen/verketten
• Dateien sicher löschen
• Dateivergleich (einfach)
• Exportieren in verschiedene Formate, darunter Pascal, C, Java oder auch Intel Hex, Motorola SX Records
• Ansicht in verschiedenen Zeichensätzen (ANSI, DOS, EBCDIC, Macintosh)
• Gruppierung von Bytes
• Nur Hex- oder nur Text-Modus
• Prüfsummen-Generator: Checksum, CRC, Custom CRC und Digests SHA-1, MD-5, ...
• Hervorhebung von veränderten Daten
• und mehr (siehe auch Webseite)

Heute (04.02.2005) habe ich gerade die erste stabile Version veröffentlicht und würde mich über Tests und Vorschläge (natürlich auch Lob ) freuen.

ACHTUNG:
Verwende den Schreibmodus des Diskeditors nur wenn Du genau weißt was Du tust! Man kann leicht durch falsches Editieren der Festplatte ein System unbootbar machen.

http://mh-nexus.de/de/graphics/MiniShotHxD.png

Download portable und installierbare Version 2.4.0.0: http://mh-nexus.de/de/downloads.php?product=HxD20

Updates (Download oben):

• Version 2.4.0.0 (28.2.2020), Changelog
  
• Version 2.3.0.0 (6.7.2019), Changelog
  
• Version 2.2.0.0 (17.1.2019), Changelog
  
• Version 1.7.7.0 (3.4.2009), Changelog
  
• Version 1.7.6.6 (8.11.2008), Changelog
  
• Version 1.7.6.4 (8.8.2008), Changelog
  
• Version 1.7.6 (16.4.2008), Changelog
  
• Version 1.7.5 (21.3.2008), Changelog
  
• Version 1.7.1 (9.6.2007), Changelog
  
• Version 1.7.0 (4.4.2007), Changelog
  
• Version 1.6.1 (26.05.2006), Changelog
  
• Version 1.6.0 Beta (18.03.2006), Changelog
  
• Version 1.5.2 (7.10.2005), Changelog
  
• Version 1.5.1 Beta (27.09.2005), Changelog
  
• Version 1.5.0 Beta (21.09.2005), Changelog
  
• Version 1.4.2 (9.06.2005), Changelog
  
• Version 1.4.1 Beta (13.05.2005), Changelog
  
• Version 1.4 Beta (2.05.2005), Changelog
  
• Version 1.3 Beta (13.04.2005), Changelog
  
• Version 1.2.1 (1.03.2005), Changelog
  
• Version 1.2 (27.02.2005), Changelog

Also dann schreibt mal eifrig

[p80286]

Zitat von jaenicke:

Zitat von mael:

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

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

[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;