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

[himitsu]

Kommst du überhaupt in diesen Größenbereich?

RAM und Festplatten/Dateigrößen im Bereich von paar Exabyte.

[Luckie]

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?

[mael]

Zitat von Luckie:

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

Zitat von himitsu:

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").

[himitsu]

In Windows ist bei 16/128 TB (44/48 Bit) scheinbar einfach so Schluß, auch wenn 64 Bit mehr könnte.
https://msdn.microsoft.com/de-de/lib...#memory_limits

[edit] ups, nicht fertig gelesen und schon angefangen mit schreiben .... aber so als Bestätigung



Du kannst auch die Maus nur um ganze Pixel verschieben, so dass selbst in FMX die unscharfen Fließkommapixel nix helfen.

[Medium]

Zitat von himitsu:

Du kannst auch die Maus nur um ganze Pixel verschieben, so dass selbst in FMX die unscharfen Fließkommapixel nix helfen.

Nicht ganz richtig. Wenn man einen LowLevel-Hook auf die Maus macht, bekommt man deren Koordinaten immer im Intervall 0..65535. Das ist was intern immer als Basis benutzt wird. Für die Benutzung in höheren Schichten wird das dann erst auf die Desktopgrenzen gemapped.

(Interessant wird das, wenn Desktops mit real mehr als 32767 Pixeln in Breite oder Höhe gebraucht werden, weil dann wird nach Shannon-Nyquist (bei linearem Mapping und naiver Rundung) nicht mehr jeder Pixel garantiert abbildbar )

[mael]

Ich dachte schon ich hätte nun so gut wie alles durchgesehen, da ist mir aufgefallen dass die Logik für Locking/Sharing von Dateien/Disks noch unvollständig war.

Es funktioniert zwar, aber so dass sie permanent acquired/released werden, was zu unheimlichen Lags führt. War schon Jahre her dass ich diesen (damals unfreiwillig unbeendeten Teil) geschrieben hatte, und daher nicht mehr klar.

Kurz gesagt: mehr Design ist notwendig um das abzuschließen :/

Aber die nächste Version kommt auf jeden Fall, das wird jetzt bis zum Schluss durchgezogen.

(P.S.: Entschuldigung für das Denglisch.)

[himitsu]

So lange es noch in diesem Jahrtausend kommt, ist doch alles in Ordnung.

Ansonsten solltest du schon mal langsam Three-State-Quantenbits implementieren. (True, False, Maybe )

[mael]

Zitat von himitsu:

So lange es noch in diesem Jahrtausend kommt, ist doch alles in Ordnung.

Ansonsten solltest du schon mal langsam Three-State-Quantenbits implementieren. (True, False, Maybe )

Das sollte sich einrichten lassen, ebenso wie ein paar Heisenbugs

[Delphi-Laie]

Zitat von mael:

Aber die nächste Version kommt auf jeden Fall, das wird jetzt bis zum Schluss durchgezogen.

Was heißt das - ist eine Ende abzusehen?

Oder ist der "Schluss" aus heutiger Sicht offen?

[mael]

Zitat von Delphi-Laie:

Zitat von mael:

Aber die nächste Version kommt auf jeden Fall, das wird jetzt bis zum Schluss durchgezogen.

Was heißt das - ist eine Ende abzusehen?

Oder ist der "Schluss" aus heutiger Sicht offen?

Das heißt dass das Ende abzusehen ist, aber länger dauert als ich vermutet habe und ich gerne hätte dass es schneller geht