OSDev.org

On Mac I used 0xED (freeware)

http://www.suavetech.com/0xed/0xed.html

It's hex editor, quite fast, nothing less, nothing more.

berkus wrote:

Solar wrote:

berkus wrote:It's like Kate, but for 60 euros

Yeah, blanket statements in a thread about text editors. That's not flame-bait-ish at all.

I'm just saying that not everyone is lucky to have Windows installed. And ctags plugin is there, so no probs for me. awk replaces the macros

this is kind of off-topic, but as big of a geek as i am, i still love windows. i use both windows and linux about equally daily, but on my main desktop system, i always find myself using windows. imo, linux is for servers, windows is for desktops although that's starting to change a bit lately. linux is getting better for that.

this may be a personal issue more than anything else, but i find all my favorite software is for windows. plus it's just less of a hassle to do many things on the MS platform. before you say i just don't know how to use linux - wrong, i've been using it since the late 90's on a daily basis. there is just too much ninja'ing and keyboard-mashing to do some things than i'd like.

windows certainly has it's downsides, the biggest being it can be easy to get malware infections if you don't know what you're doing but in the end i prefer it.

</offtopic>

I didn't download 0.11 because it was failing and redirecting to 0.10 download for mac. I can try 0.11 if you say it's up now.

Yes it's already uploaded. I also redirect default download to v0.11 now. You can try and say if it's slow too...

I tried it on windows. It works well

Oh thanks. Primarily, I made it for Linux, since there is no good hex editor on it. God blasts Julian Smart (wxWidgets author), I made it with wx, so It's works on Windows, OSX and BeOS(soon)

It's just beta now, functions like comparison/search will be faster on later versions.. I don't have time for optimization. It's little heavy for a developer to build such a thing, at least for me

I don't know whats wrong on your computer. v0.11 is super fast on my Virtual Box. You can select a block as you mouse moves. No delay...
Think that I am using bare VESA driver due emulation. So it's needed to be much more faster on your computer.
I test this by 10.6.6. What OSX version do you have?

Ahhh ok.
Program doesn't use standard TextCtrl but draws hex region via bitmap. I implement keyboard actions so events are not optimized.
Since you press the arrow keys, there are too much events generated and each event needed to handled one by one. So response to arrows are slow specially on OSX... It takes 3 seconds to pass 16 bytes (00 to 0F) via hex editor view in OSX. I thought this be about my emulation layer. How it takes on you? In linux, it takes just a second to pass 16 hex bytes (32 bytes at text view region). I think it's acceptable. I use mouse to move cursor generally, doesn't feels such discomfort also it's 3x faster at linux...

It might be little faster on next releases. I don't optimize anything yet. Focused some other things. Will handle this after preferences panel to add some customization such as hex editor colours...

It's also bad thing that cursor vanishes on moving at OSX. It's visible on linux.
But at least we have open source cross compilable hex editor that could open any file

What tools do you wanted to have in wxHexEditor?
I am thinking on Disk device tools like fill random values or clone a disk image. (not needed on linux/osx since dd with us but might beneficial for Windows.)
Also thinking RAID-0 merging for read files from 2/3/4... raided drives.

berkus wrote:

EUA wrote:But at least we have open source cross compilable hex editor that could open any file

It's a pretty bad excuse. Would've been much better to cross-compile some existing editor (e.g. okteta) with a better architecture (bitmap? really?).

Could you try to open 4GB file with okteta? Or could you inject 100 byte into a 1 GB file without using temp file with okteta? I guess you cannot. As you can see, "arrow key response" is nothing that important and does not mean a better hex editor, specially when you have a mouse...
And about graphic architecture, your slowness does not come from bitmap processing. Every GUI handled on bitmap files on working programs. It's fastest... I guess slowness about OSX's event system speed. So things keep same speed when If upgrade that architecture to OpenGL driven engine...

berkus wrote:

EUA wrote:What tools do you wanted to have in wxHexEditor?
I am thinking on Disk device tools like fill random values or clone a disk image. (not needed on linux/osx since dd with us but might beneficial for Windows.)
Also thinking RAID-0 merging for read files from 2/3/4... raided drives.

This is absolutely not the tools for the hex editor. Something like in-place endianness conversion would be much more convenient.

What do you mean with "in-place endianness conversion"? Data interpreter has a switch for show data in bigendian too. But I think you mean something different...

berkus wrote:

EUA wrote:Could you try to open 4GB file with okteta? Or could you inject 100 byte into a 1 GB file without using temp file with okteta? I guess you cannot.

What I imply is you can add this functionality to an existing, already properly working hex editor instead of writing your own from scratch.

That's not so easy to do that after you have a working program. Because "the core" need big overhaul and might be/probably not compatible with existing one... It's easier to make it from scratch.

berkus wrote:

EUA wrote:What do you mean with "in-place endianness conversion"? Data interpreter has a switch for show data in bigendian too. But I think you mean something different...

Swapping bytes in a word/dword/qword between little- and big-endian...

Weird. Why someone need such a thing, I really wonder... Looks easy to do but might be it's better to create an interface that you can dynamically program what processing that you need... Will think on that.
Thanks

No one force you to use that. I just ask why do you need/use such an option since there is no meaning on swapping endiannes of data.
My program, is not slow or worse than xed. It's just your perception. No one measure `hex editor speed` by arrow keys response...

EUA wrote:No one measure `hex editor speed` by arrow keys response...

And you say that after someone even demonstrated the opposite, and I hereby want to disprove it again: Perceived speed is a combination of factors. You are essentially claiming that every button press or mouse click can take an hour as long as it wouldn't have to perform modifications. Not buying it.

Just to make a point, If I end up using a hex editor, I do 90% by keyboard, including moving around. Your editor would be (based on statistics posted) the only one where repeatedly switching between mouse and keyboard is faster than just using the keyboard, and thus slower than every other hex editor I know.

Just for form I want to add that berkus validly reported an issue, and dismissing it by calling him a bad user is about the worst you can do to your support's reputation (flaming does not help anybody). If you have to discard it, post a scientifically legitimate reason why a fix can not be performed.