PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Gibt's wirklich keinen Hex-Editor der mit Find&Replace in wenigen Minuten fertig wird

Gast
2007-12-10, 16:45:43
Bestimmte Werte einer Datei zu ändern?


Ich habe jetzt hier mal mehere Hex Editoren ausprobiert.

Die meisten stürzen ab, weil sie die 600 MB große Datei ins Ram laden
und dann das RAM für die Search&Replace Funktion nicht mehr ausreicht.

Und die wenigen, die nicht abstürzen, die brauchen eine Ewigkeit
und liefern keine Rückmeldung.


Momentan benutze ich PowerHex und der durchkämt die 600 MB Datei
jetzt schon über 2 Stunden lang.

Das kann es doch nicht sein, daß die Programme von heute so lahm sind.


Ich spiele gerade mit dem Gedanken mir ein eigenes Programm zu schreiben, daß das schneller macht.

Wie schnell würdet ihr denn das theoretisch gesehen abschätzen, wie lange so ein Programm wirklich dazu brauchen könnte?
Eine 600 MB große Datei zu verändert?
Marscel
2007-12-10, 17:51:59
HxD probiert?
Gast
2007-12-10, 18:02:10
Ja, der stürzt bei Find&Replace ab bzw. hängt sich ohne Rückmeldung auf.
Der_Donnervogel
2007-12-10, 19:56:34
Die meisten stürzen ab, weil sie die 600 MB große Datei ins Ram laden
und dann das RAM für die Search&Replace Funktion nicht mehr ausreicht.
Wenn der Ramspeicherverbrauch das Problem ist, dann seh ich nur zwei Möglichkeiten. Entweder den Ram aufrüsten oder den Speicherverbrauch senken. Einfach mal versuchen die Datei in mehrere Teile zu splitten und dann für jeden Teil extra das Search&Replace vorzunehmen. Dann am Ende die Teile wieder zusammensetzen. Wenn wirklich der Ram zu knapp ist und massiv ausgelagert werden muss, wundert es mich nicht dass es sehr langsam geht.
Gast
2007-12-10, 22:20:36
Wenn der Ramspeicherverbrauch das Problem ist, dann seh ich nur zwei Möglichkeiten. Entweder den Ram aufrüsten oder den Speicherverbrauch senken. Einfach mal versuchen die Datei in mehrere Teile zu splitten und dann für jeden Teil extra das Search&Replace vorzunehmen. Dann am Ende die Teile wieder zusammensetzen. Wenn wirklich der Ram zu knapp ist und massiv ausgelagert werden muss, wundert es mich nicht dass es sehr langsam geht.

Das Problem ist das die meisten Hex Editoren einen Designfehler haben.

Die versuchen nämlich auch dann noch die Änderung im Speicher zu halten,
obwohl absehbar ist, daß der Speicher nicht ausreicht, anstatt einfach den Benutzer nachzufragen, ob das bisher gefundene in die Datei geschrieben werden soll, um dann mit dem nächsten Abschnitt fortzufahren.

Würde der Hex Editor also die Änderungen gleich in die Datei schreiben, dann gäbe es das Problem nicht.
Gast
2007-12-11, 00:04:11
http://www.catch22.net/software/hexedit2.asp schon probiert?
dariegel
2007-12-11, 14:25:59
mirkes.de Tiny Hexer (http://winfuture.de/news,30825.html)
Schon probiert? Die HP ist zur Zeit down, deshalb der Link bei WinFuture.de.
Coda
2007-12-11, 15:19:29
600MB sollten aber kein Problem sein im Speicher zu halten. Ich versteh das Problem nicht. Vielleicht wegen Undo?
Trap
2007-12-11, 15:51:08
Suchen und Ersetzen mit Längenänderung kann man einfach so implementieren, dass es bei 600 MB Daten nicht fertig wird. ;)

Es so zu implementieren, dass es auch bei 600 MB noch schnell läuft ist dagegen viel schwieriger.
Ganon
2007-12-11, 16:00:55
Es so zu implementieren, dass es auch bei 600 MB noch schnell läuft ist dagegen viel schwieriger.

Ist jetzt vllt. nicht die schönste und (Festplatten-)speicher sparenste Methode, aber kann man nicht einfach eine Kopie anlegen, welche man Stück für Stück schreibt und die entsprechenden Treffer einfach "anders" rein schreibt?

Mal eben so fix eingefallen, mag sein das ich etwas übersehe ^^
Trap
2007-12-11, 16:47:01
kann man nicht einfach eine Kopie anlegen, welche man Stück für Stück schreibt und die entsprechenden Treffer einfach "anders" rein schreibt?
Auf der Festplatte geht das so problemlos, da nimmt einem das Betriebssystem alle komplizierten Sachen ab.

Interessant wird die Aufgabe, wenn man es im Speicher machen möchte und man nicht 100% Speicheroverhead haben möchte (also in-place). Am besten auch noch so, dass es auch auf 32-bit Systemen zuverlässig läuft.
Gast
2007-12-11, 17:37:53
600MB sollten aber kein Problem sein im Speicher zu halten. Ich versteh das Problem nicht. Vielleicht wegen Undo?

Das ist auch meine Vermutung.

Ich denke ich werde mir ein kleines C++ Konsolen Programm schreiben,
daß die Aufgabe für mich erledigt.
Das dürfte dann auch am schnellsten gehen und auch funktionieren.
Gast
2007-12-11, 17:39:47
Suchen und Ersetzen mit Längenänderung kann man einfach so implementieren, dass es bei 600 MB Daten nicht fertig wird. ;)

Es so zu implementieren, dass es auch bei 600 MB noch schnell läuft ist dagegen viel schwieriger.

Wie würdest du das am besten machen?

Ich dachte daran Blockweise Häppchen zu laden, die zu ändern und dann den geänderten Block zurückzuschreiben, danach kommt der nächste Block dran.


Welche Blockgrößen währen hier für Festplatten ideal?
Mr.Magic
2007-12-11, 17:45:44
Eine Liste mit bereits getesteten Programmen wäre nicht verkehrt.

xvi32 schon ausprobiert?
Gast
2007-12-11, 17:59:40
Probiert habe ich:

ghex (stürzt ab)
khexedit (stürzt ab)
powerhex (dauert ewig > 10 h)
HxD (stürzt ab)
Biew (bietet nicht das was ich brauche)
MapEdit (stürzt ab)

Die habe ich bis jetzt ausprobiert.
PHuV
2007-12-11, 19:01:33
Es gibt noch

UltraEdit (http://www.idmcomp.com/index.php?name=UE_MoreFeatures)
WinHex (http://www.winhex.com/winhex/index-d.html)
TinyHexer (http://winfuture.de/news,14860.html)
HexWorkshop (http://www.bpsoft.com/downloads/download.jsp?dlfile=hw32v500.msi)

Ich würde mal HexWorkshop bzw. UltraEdit testen, die müßten das packen.