I thought about making a hex editor in the past as well.  I had a big list of features I was going to include but I forgot most of them.  Anyway I never got anywhere.  I can think of 2 features... one of which isn't really a feature though:

not really a feature)  Handle large files gracefully.  This was actually the biggest obstacle with my project attempt.  I ended up splitting files into 'blocks' and only loading blocks as needed rather than loading the whole file at startup.  Blocks were stored in a tree type structure.


a feature)  offset translations with a customizable string.  You could have some defaults for common types like SNES HiROM/LoROM.  Would be something like...

"{2:X>>16}:{4:X&0xFFFF}"  <-- an example format string for HiROM.  Would translate offset 0x12345 to "01:2345"

Would be more useful for other systems, like NES where CPU addresses and offsets often differ greatly

Current plans are to provide source once the code is written and documented to my personal satisfaction.  I'm working in unfamiliar territory with some of the things I'm trying to implement, and from time to time I'm likely to experiment.  Crappy hacks may enter into the picture, and I know better than to release such into the internet jungle.  People read that stuff.

Plugin architecture is planned from the beginning (working on the interfaces right now), so as long as this base gets written properly the project won't be outdated, regardless of what happens to me.


(Emphasis added)
Once again, TEEHEE!  Documenting the file is another key concept of what I'm working on, and the primary reason that I'm taking a plugin approach to this utility.  So I agree wholeheartedly with that concept.  I've had some good ideas for it, but any disassembly functionality is way after I get the initial bases done.  I don't want to bite off more than I can chew.

I also considered extending an existing hex editor, but then I tried to compile it, failed, looked at the source, and shuddered.  And here I am.

I'm liking that a lot of other people have these ideas, too.

-I have to say, I hadn't considered using a Photoshop "layer"-style approach to the hex application.  Although I've been considering change tracking for a while, loading and displaying all of that dynamically seemed that it would take an awful amount of resources.  I know a lot of people work on older machines, so I'm trying to keep resource usage low where I can.  And while I understand that we don't have to code for 640K anymore, I'm trying to reserve resources where possible for some future features and multiple views.  It's an interesting idea, for sure, but it could be troublesome once the project grows in both hours and size.  Diff files would be in a text format containing binary blobs, if/when implemented.  Maybe UPS support, if it meets my needs.
-Also noting a vote for large file support.


-large file handling is indeed important.  And I know that it's easy to implement wrong.  I'm not sure how I'm going to resolve it, but I do see the need.
-Please clarify this feature a bit more for me.  I have absolutely no idea what this is intended to do.



I know I might step on some toes by saying this (sorry), but I can't work with console hex editors like that.  The colors always seem grating, most of the time the windows are modal, etc.  I'm not saying that they're bad.  Just that I can't get any serious work done in a console hex editor.  I blame myself.  I'll roll around in the prompt all day, but for hexing I prefer a more modern interface.  But thank you for pointing it out to me. 

Tauwasser:
Yes, if you look hard enough you can find all features in this or that program. From what I understood, the point of this editor was to get it all together into one program that works, is stable and moreover (this is a HUGE plus over an unbearable console editor like Snesedit) to have a strong interface that makes it comfortable to work with.

And that's something really needed and that I'll support 100%.

Lleu:

• Relative Searching: Inverse pretty much nailed all the problems and important aspects. Many relative searchers were written by people who translate from English to other languages, so they all work only with the latin alphabet. They just search using words only and not values, so you can't search comfortably for Japanese.
• Table Files: It's very easy to support a basic table file, but it gets more tricky when you dive deeper into it.
  
  A table file can encode one byte entries, but also two or even more byte entries, all in the same file. For encoding the file, SJIS or Unicode should be possible, as well as ASCII of course.
  And yeah, searching for data should be possible using the values from the table file.
  
• Inserting Raw Data:
  I meant a data file. Just a binary file, shouldn't be hard to implement.
• Corrupting:
  Corrupting is changing an area of data in a ROM to systematically find where specific data is stored. Let's stay you want to find where the level data is stored in a jump and run game, but you have no idea where or how the data looks like. With corrupting, you can just change areas of the ROM to all zeroes or anything, until you find the data. Depending which data you overwrite the game might crash, the sound might stop, some graphics may be messed up or... the level layout might have been messed up. There, you just found it's location
  
• Byte fill: Should be possible at any given location. Corrupting is the same, just with different intentions. Changing the file size will automatically fill the new space with some data of course. It's just needed to expand ROMs. Should be simple.
  
• Searching: I don't know about the interface details yet, haven't thought about it. Sorry if I just ask for things without a clue how to implement them best
  
• File change notification: It would be kind of cool if it would notice it immediately. It should then ask if the file should be reloaded or not.
  

HxD has another method to circumvent accidentally changing the data with other programs... it locks the file completely. You can't open the file with anything else as long as you have it opened in HxD. Please don't follow that route... it's majorly annoying.







[/list]

I'll admit it, I only skimmed the thread, some of these might be duplicates.

• Adjustable byte spacing. It is occasionally helpful to display data in two byte or three byte or four byte clusters for data analysis
• Display binary conversion for selected bytes in the status bar at the bottom of the screen, or somewhere else easily visible. I am occasionally too stupid to do the conversion in my head.
• Second only to table support, searching. Like everything said above and more. Wildcards, hex search, text search via table, etcetcetc.

Ah! I see it now! It took a while though... is this standard regular expressions? Somehow I doubt this, but I was never really familiar with that either...

Also,... if this feature were to be incorporated, I would advise to have the option of showing both, the rom file offset and the cpu address at the same time as well as both alone. Also, in each mode (if you work with a address translation, regardless of what "offset view style" you are in), it should feature a boundary check (that is configurable turn off/on in the options - not annoying that way), so people don`t put stuff across banks when they don`t think for a minute or two.

@KaioShin: There is a windows version of snes edit, though it feels like the command line it is...

I don`t use it much/like it either, however it has many features, regardless of how you look at it (psx tim viewer and other gfx stuff, too!).
Also, for me Hex Workshop has never ever failed to function properly... It only ever crashed when I accidentially opened 20 GB and compared files or something... which I had created on the fly for...er...some unbeknownst purpose lol
I`m not against this or anything, I`m just saying where some good features are, so one could kinda copy from those hex editors

cYa,

Tauwasser

I like the idea of color coding chunks of data.

e.g: I have three chunks of data labeled "Text1", "Text2", "Text3" with the color "Blue".

The Hexeditor would need the ability to:
-Move to (Place that chunk of data beginning in a specific offset).
-Dump/Extract (Dump the chunks of data from a specific color in separate files with their labels as file names) 
-Insert from

And in a dream...

Your hexeditor would have the ability to link a "Pointer" to a chunk of data.

e.g: "Text1" linked to "Pointer1":

When tou drag or move that chunk of data (Text1) to a specific offset the linked pointer would recalculate itself to match the new offset of Text1.

the different types of pointers would be choosen from a drop-down menu and the user could add new types of pointers.

If I guessed what this is trying to accomplish, a system to handle pointers is of key importance.

This isn't the first time I see the idea of an editor configurable through a descriptor, but doing it as an enhanced hex editor is very ambitious. Hope to see this finished