Cross platform for obvious reasons.

Features most general purpose hex editors are lacking that you need for romhacking:

- Table support (compatible with Japanese!)
- Relative Searching (with values, not just letters so it's working for Japanese too)

Features that shouldn't be missing:

- Compare files
- Inserting raw data

Features that would be very nice:

- Built-In corrupting functionality
- Bookmarks
- Byte fill + Ability to change file size (to expand Roms)
- Lot's of data searching options (Raw bytes or text using the table - should also work with Japanese)

Another feature I just remembered that would really had saved the ass of a ton of us in the past...

When saving a file, check for edits since the file was opened and warn the user about it. I can't count how often I accidentally killed changes I made due to a hex editor that had the file opened for hours while I worked on the file with other programs in the meanwhile...

Responses for everyone in one post.  Yay!


I'm not adverse to aiming for multiple platforms.  However, would using Mono be alright with you?  Some BSD-folk dislike the ramifications of it.  And I'm targeting C# because I really want to speed development (both for myself and for later extensibility by others).


It's entirely open-ended.  I'm asking for changes that people think should be implemented to make the work easier.  Are you looking for RegEx support, or what?  Detail roughly what you would like the search mechanism to support.


Let me check my understanding of your terms and how to implement them.

Table file:
This is a multi-line text file that has a hexadecimal number followed by the character it represents.  Example:
15=L

You want this to be able to handle Japanese text, so I'd need to be able to parse a unicode text file with the table information.  I can also assume that table support implies displaying characters in the hex view using the characters designated in the table file, right?  Would I need to have table file editing/creation capability in the application, or would loading table files suffice? 
I do plan on internally implementing Unicode, ASCII and SJIS viewing support as well as user-defined encodings.  Since I'd planned on working with .NET, I should theoretically be able to allow the user to specify any valid system encoding and use that, as well.  Theoretically...
Another thought that came to me from the relative search comment was that you'd probably like to be able to search for text using the encodings of the table file, right?

Relative search:
Searching for an array of values (such as a text string) based on the difference between the provided values, as opposed to searching for the absolute value.  Very useful for finding known text/values in a game.  As I understand the concept, it uses the numerical difference between the provided values.  Is there another definition of relative searching that does not, where it's easy to only implement English support?
I assume with this you'd like to use * as the wildcard, Like in Relative Searcher, right?  Should I ignore whitespace?

File comparison:
You mean binary comparison of two files, right?  This is one of my big frustrations with hex editors, as the ones that support it often have bad interfaces.  Or crash a lot.

Inserting raw data:
Would this be covered by 1) allowing the user to edit the hexadecimal display, and not just the text representation and 2) allowing the user to switch from Insert to Overwrite mode?  Or are you wanting the capability to insert a file at a given location?

Corrupting functionality:
Not very familiar with this.  I checked the utilities section, and it looks like it allows you to specify a range of data and "corrupt" (or replace) that data using various methods.  Is this correct?  Is the corruption method used important?  Any additional details would be appreciated.  I'll check the utilities for any readmes on what they do later.

Bookmarks:
Are you wanting something simple like specifying a point in the data and associating a name with it, or something else?  Would you want a dedicated menu or a sidebar for going to those bookmarks, or some other navigation method (like keystroke combinations for skipping around)?  I'm particularly interested in bookmarking, as I think it can boost productivity if done right.

Byte fill + size adjustment:
Just fill in a specified place with zeroes?  Should it always be at the end, or configurable?  Also, are you wanting a mode to lock in the file size?  Or a warning if you're about to change the file size?  Because allowing data insertion in the first place will require adjusting the file size.

Search options:
I guess I answered my table searching question.  Basically, allow for raw searching, relative searching, text searching, and allow the user to specify which text format they're using for the search.  Should relative searching have its own dialog box, or should it be integrated in the same window?  Should search dialogs be modal or not?

File change notification:
Should the program keep a watch on the file and ask if you want to refresh on changes, like Visual Studio, or simply wait until saving to notify the user?  I'm guessing a nice feature would be a temporary save + binary comparison here, although it'd be tricky to implement.  Can't really think of another way to "merge" files.


-Alright, so stability is a must.  Understood.  Is auto-saving required, or should it just be careful saving?  Is it alright to sacrifice HD space for safer options (such as saving to a temp file first, before overwriting the original, incremental files, etc)?
-Why is setting up your own character set slow?  Can you think of ways that you would speed it up?  E.g. instead of providing each individual character, allowing a range of characters to be set at once.
-Not sure that I understand the "byte for byte character set" issue.  Please elaborate.
-Please review prior comments on bookmarks and byte-filling and see if you can clarify what you're wanting further.
-I can't make any promises on the interface, as that's where I'm likely to make a lot of changes.  Let me know if there's something specific that you like about it, though.


As long as it implemented undo/redo from the last save like Visual Studio (as opposed to unlimited), you'd be alright?  Would it be allowable to maintain this on the disk, sacrificing HD space and speed for RAM?  If done this way, it could be transformed into a change log based on options.

Everyone feel free to drop opinions on any of this, as I'd like to see any differences in styles, or features that are considered universally important.  Any (calm) debate is welcome.  I think feedback would be useful on search capabilities and sacrificing HD space for functionality, as these features are likely to have long-term effects on how the program works.

WindHex32 is my main Hex Editor because it supports table files. What I don't like about it is I can't highlight text and copy it so I can paste it into Google Translate. In order to get a copy of the text I have to go to Edit->Dump Text. This is time consuming if I am merely translating a few sentences here and there.

Lately I've been using MadEdit because the game that I'm editing has it's text encoded in Japanese Shift-Jis (this Hex Editor supports standard encodings, but it would be better if it supported custom encodings). This Hex Editor allows me to quickly highlight text and paste into whatever I want. The only thing I don't like about it is when you paste something back INTO the hex editor it inserts it rather than overwriting the text. This is bad for ROM editing because the filesize cannot change.

To Compare files I use mirkes.de Tiny Hexer. This Hex Editor is awesome for comparing two files (see screenshot), I just wish it supported Table Files.



Now if there was a single Hex Editor that would replace all these I would be very happy.

I use ultraedit for almost all my text and hex needs.. the only thing it doesnt have is undo in hex mode which is kind of a pain in the ass sometimes  :banghead:

Hmm.  I can see your point.  It sounds like session-based unto streams might be more useful.  I'll think about revert capabilities in addition to this.


-Alright, so each individual view (hex, text, etc) needs to be copy/pasteable.  Even though the views should have synchronized selections, the actual data copied should come from the view selected.
-Another vote for custom encodings/table files.
-Insert/Overwrite support for pasting.  Sounds logical, but I'm glad you pointed it out.
-Ooo!  Tiny Hexer has a rather good binary compare interface.  That's way better than the current program I've been using.  /me takes notes.

Thanks for the clarification on the crashing.
-I haven't used the character filter in Hex Workshop, but it does sound cumbersome.  Apparently, table file support will meet your needs, then?
-Ah.  You need support for multiple-character encoding in the table files.  Gotcha.


-Ok, all views need to support undo/redo.


Hmm.  I'll take both Translhextion and Monkey-Moore into account when working on relative search.  I like the interface of Monkey-Moore.  Maybe if it wasn't too much trouble I could allow for creation of a partial table file from the relative search window...


-TEEHEE!  I like your interest in bookmarks.  I also like that you're headed in a similar direction to what I envisioned with them.  It's part of the idea behind this thing.

-Oh yeah, command-line execution of files would be a big help.