Hex editors

[helios]

Normally I use Hexplorer, but it has its inconveniences. It loads everything completely to memory, the interface is uncomfortable (e.g. ctrl+s doesn't save, it translates to a byte value), it doesn't have certain data functions (e.g. editing four bytes as a single little or big endian integer).
Does anyone know of a hex editor with all or most of the following?
* Partial file loading.
* It should not lock an open file for writing. This is a problem I've had with the partial loading editors I've tried. I'd open a file, run my program, and have it crap out because the stupid editor locks the file.
* Data edition, preferably including bit edition as well (i.e. being able to see A5 as 10100101 and toggle each bit separately).

[chrisname]

GHex?

GHex is a simple binary editor. It lets users view and edit a binary file in both hex and ascii with a multiple level undo/redo mechanism. Features include find and replace functions, conversion between binary, octal, decimal and hexadecimal values, and use of an alternative, user-configurable MDI concept that lets users edit multiple documents with multiple views of each.

* I don't know what you mean by partial file loading
* GHex doesn't lock files - I have a file open in GHex and gedit at the same time.
* You can change the data but I don't think you can flip each bit individually. You can change and insert stuff.
What are you going to use it for? Just curious.

[helios]

No good. I use Windows, and starting up a virtual machine just to view a file is not very efficient. Also, according to Wikipedia, it doesn't have partial loading, so it's not more useful than what I already have.

* I don't know what you mean by partial file loading

Loading only what is currently on the screen, rather than the entire file. Without it, you're restricted to your available memory.

* You can change the data but I don't think you can flip each bit individually. You can change and insert stuff.

That's what a hex editor is. What I'm talking about is

e.g. editing four bytes as a single little or big endian integer

Right now I'm writing a small ZIP reader and writer, which of course involves a lot of binary editing, and opening some pretty big files.
Aside from that, though, a good hex editor has endless uses.

[z05DSL3A]

Hex Editor Neo ? (various versions, ranging from free)
http://www.hhdsoftware.com/

[helios]

Using it already. Locks files.
Also doesn't let me edit bits (at least not as far as I know).

[Null]

How about FRHED?
http://frhed.sourceforge.net

[helios]

Loads to memory.

[S6k9GNh0]

A friend is bugging me with UltraEdit. I guess you could check it out.

[TaikoDragon]

Why are you trying to edit large zip files.. shouldn't you prefect your writer/reader on small files and then scale it up?

[helios]

How am I going to test the reliability of the program on small archives? Besides, by "large" I mean 50-100 MiB. Actually, that's a medium-sized archive for the program. It's just annoying to load completely to memory with a hex editor. If I'm talking truly large for my program -- the type of "large" I use for stress testing -- that would have to be several GiB long.

[TaikoDragon]

What I meant is why are you not using maybe a KiB size zip until you work out the main bugs and I agree although the apparent reasoning behind caching a file in ram is that you have better preformance when say scrolling from start to end in one operation..in which you'd have to query the hard drive and would have to lock the file if you were writing to it because it could change and say sudden become much smaller.. that probably is why they cache the file

[helios]

I know why they do it, I'd just like to have the option to leave the file unlocked. I know exactly when the file is going to change, so when or if I need to go back and take a closer look at it I could just make it reload the file. The hex viewer that comes with Total Commander does exactly does, minus the reloading, but the problem is that it's too awkward to use.

[chrisname]

Some text editors like Notepad++ and gedit are able to reload files automagically when it has been changed; so why can't a hex editor do that too?

Anyway, helios; surely you could just write your own hex editor if there isn't a good enough one out there?

[helios]

That's not a very efficient use of my time.

[chrisname]

Yes, true, but... if you can't find one you might need to.

[z05DSL3A]

...you could just write your own hex editor...

That is somthing that I have started many times, but never finished.

[chrisname]

Well... I might give it a go. It would be fun. I know how to convert between bases (iterative or recursive division/multiplication) and I guess I could implement a GUI once the rest of it's finished.

I'll try it.

[helios]

iterative or recursive division/multiplication

...What?

[chrisname]

Like this:

while (n /= base)
    int rem = n % base;

That kinda thing, for decimal to base conversion. E.g. for hex, base would be 16.

How many bytes should I load into memory at a time? 1MiB ok?

I'm using the opportunity to test myself on linked lists because that's how I'm keeping track of open files.

[helios]

I was asking about the recursive part.
In any case, std::stringstream+std::hex, or sprintf().

Load exactly what is shown.