wxHexEditor: wx-based Hex Editor!

[eua]

There are some cosmetics but I think it looks better.

r218 | erdem_ua | 2011-05-25 04:04:38 +0300 (Wed, 25 May 2011) | 2 lines
Changed OffsetCtrl for use less digits if hex mode in use.
Added Auto-Offset resizing by file length

I can integrate xdiff like engine or just put my own diff code to patch BIN files.
But that patch file is compatible with all OSses. Why do you think that will be break compatibility between Win and Linux?

I think next big thing is Memory Reading for windows (at least on XP) and Linux (don't know how to do on OSX)..

I think it's prohibited on linux but some users doesn’t think same.
Do you know any way to read whole physical memory at Linux?

[Makoto]

I'd gone off on a tangent and was thinking about (standalone) executable patches when I'd made that comment. (See, that's why I shouldn't try to make suggestions at 3AM, when I'm rather tired. )

I can't say I know anything about memory reading/addressing, unfortunately. Would that also require you to start considering having both a 32-bit and 64-bit version of wxHexEditor, due to the differences in the way they address memory? (Or can you do both within a 32-bit program? (I did say I knew very little about the subject... ))

(...then again, my posts in the middle of the day when I'm fully awake aren't necessarily all that coherent... )

[Makoto]

Okay, just remembered something I'd forgotten.

For copying text from the right-hand pane, a warning will pop up if the selection contains nulls, and the text will be truncated. Would an option (off by default) to automatically convert the nulls to copy-friendly characters (such as spaces, underscores?) be a good idea? That might also need a sub-option to warn (or keep the above warning) as a reminder if you were indeed going to paste the text in the same or another instance of the editor, though, to be safe.

Or, perhaps add the option to convert the nulls in the selection, in the existing warning. That way, you can keep the warning, and those who are going to paste the text into something other than a program don't have to end up taking a screenshot of the text they were trying to copy.

[disciple]

Makoto: FYI we also had a discussion going about that at http://sourceforge.net/tracker/index.ph ... tid=913065

It might be good to have an option to specify which character to replace them with. But I think in theory it should actually be possible to copy the whole string without replacing the null characters. Because if I correctly understand what Google is telling me, you can have a null character in a text file, or in a C++ string.

Here's another idea that would be nice: using a different colour (red?) in that panel for non-printing characters.

[disciple]

Here's another idea that would be nice: using a different colour (red?) in that panel for non-printing characters.

Nice, but probably not incredibly useful
-----------------------------

Erdem, are you developing primarily on Windows?
With current svn I get this error on Puppy:

Code: Select all

src/HexDialogs.cpp: In member function 'uint64_t FindDialog::FindText(wxString, uint64_t, unsigned int)':
src/HexDialogs.cpp:207: error: ISO C++ says that these are ambiguous, even though the worst conversion for the first is better than the worst conversion for the second:
/usr/include/wx-2.8/wx/buffer.h:127: note: candidate 1: char wxCharBuffer::operator[](size_t) const
src/HexDialogs.cpp:207: note: candidate 2: operator[](const char*, int) <built-in>
make: *** [src/HexDialogs.o] Error 1

Google takes me to places like this http://xania.org/200711/ambiguous-overloading, but I think I am still too ignorant to fix it.

[Makoto]

Re: colored text - I'd have it off by default, anyway, I'm sure. I'm probably too old-fashioned to stare at code or binary/hex file contents in anything but black and white.

[eua]

I don't know if changing null character is good thing.
I don't know actually but don't think if it's normal to have null at copied text. Better to keep current structure. At least for now... C++ might allow null on strings but I have doubts if gnome-clipboard supports it at text target...

@Disciple, I am developing on OpenSUSE 11.4.
That error might be about different gcc version.
I don't have such problems on gcc 4.5.1...
Are you using 4.6 ?

In this time I make some improvements to revision 226:

| erdem_ua
Added file owner change for non-windows OSes if permissions are not enough.
Added missing block indication to file comparison function.
Fixed Compare Dialog error on Win by using bigger stack.
Improved Dissassembly. Now decompiles selected block up to 100 bytes.
Fixed broken menus on OpenRecent menu repair.
Fixed Invisible SearchPanel and ComparePanel contents on File changes.
Fixed OpenRecent not working bug.

So you don't needed to change/adjust your disk permissions by hand...
I am gonna add a file checksum before giving a new release...

[Makoto]

Well, I meant more along the lines of letting the user choose from the warning dialog whether or not they'd want to go ahead and have it converted to a form that other programs (or the system clipboards) might not have a problem with.

If they read the warning, they'll know (hopefully) that attempting to copy either way into another hex-editing session isn't a good thing, so... hopefully, they'd be aware they should only do it if they're going to do something like copy-paste it to notes in a text file. (You don't want to see my handwritten notes... honest. )

[disciple]

@Disciple, I am developing on OpenSUSE 11.4.
That error might be about different gcc version.
I don't have such problems on gcc 4.5.1...
Are you using 4.6 ?

I have this error in my old version of Puppy, which uses gcc 4.2.2, and also in Arch Linux with gcc 4.6.
I'm only using the makefile. Maybe there's an option you're using in codeblocks which affects it.

[disciple]

Hmmm. I tried building it in codeblocks and it failed the same way.

[eua]

That error looks weird because cannot see an error over there.
It probably related with Unicode build... But I use unicode build also.
Weird.
Since I don't have same error. I couldn't help about it.

on svn trunk, File checksum calculation implemented via adding hashlib++

Now need a give release after bug fixing season...

[eua]

I found why you got error.

Code: Select all

wxCharBuffer a = target.ToUTF8(); //Convert to UTF8 Binary
int i=0;
while(a[i++] not_eq 0);					//Find stream size

this while tigers error.. But I don't know how can I count UTF8 length without it.
This function founds "real" length in bytes instead of character count...
Since that length is not equal with target.Len(), we needed to do that.
Will look what I can to remove that error.

Edit: Fixed on latest svn trunk. Please check...

[eua]

You can grab new version v0.11 Beta from http://wxhexeditor.sf.net

[muggins]

Thankyou eua,

I've uploaded wxHexEditor-v11b.pet in the first page of this thread.

[Makoto]

Oops - I keep forgetting to say thanks for the new .pet (and the new version). I installed it right away (in June), but haven't actually gotten around to testing it.

[sebus]

Anybody has x64 Fatdog version?

sebus

[darkcity]

PET file no longer downloads, forum error?

[muggins]

Uploaded latest beta as an sfs.