ImHex uses capstone to map hex values to opcodes, depending on which ISA (Instruction Set Architecture) you have choosen. That makes it a nifty little tool for reverse engineering.
http://www.capstone-engine.org/
I've given ImHex a test run on an Amiga binary and it kind of works. However, the Amiga Hunk format (equivalent of ELF) is not recognized, and is interpreted as opcodes. Also there are issues with copper lists.
I recently learned that it has a ”Template” feature that lets you write Tcl scripts to interpret the data in the file. It’s very easy to use and very useful too! I’ve written scripts to parse our internal file formats and pretty-print the interesting bits.
Submitted title ("ImHex – A Hex Editor for people that value their eye sight") seems distracting and baity, so I've shortened it for now. If there's a better (more accurate and neutral) title, we can change it again.
Yeah, the "for people that value their eye sight when working at 3 AM" got to me. I knew it had to mean that dark mode was a big feature here.
I don't know if this editor offers a light mode. I hope it does. I love good hex editors, and this one looks very interesting. But light mode is a necessity for me because of my vision.
I have no quarrel with anyone who only wants to implement dark modes, it just means I won't be able to use their products.
If it is a really good product you want to use anyway, there are programs that can invert the screen for you so you can use them. And the gamma settings in some display drivers can be set to invert too. Not so handy if it's an art program though...
Not all "reverse engineers" are programmers. When I was younger, I liked hacking game saves, it isn't programming, you don't write programs, you don't even touch machine code, only data.
There is a strong overlap, but it is still a different set of skills and different tools (ex: hex editor vs IDE)
The union of "humans" and "animals" is just "animals". Does that make a "home for humans and animals" basically the same thing as a "home for animals"?
You should know better than to draw that equivalence, dang.
What animals consider a home varies a lot. What programmers consider a hex editor, not so much.
If someone wants to point out what about this hex editor makes it more suitable for reverse engineers than the median text editor, I'll happily edit the title. The point is there needs to be something.
It has constant-dark-mode tag, so can be called "constant dark mode hex editor". The eyesight part is simply misleading, dark mode is the last thing I would associate with that.
There have been discussions here about modern C++ example code. Lots of projects that use C++11, C++14 and a few C++17 codebases are suggested, but I've not seen a recommendation for a C++20 codebase to study - this might be one.
Quote: "Doesn't burn out your retinas when used in late-night sessions"
I like white background and bright color themes, as in I like my retina "burned". Does it has settings where you can choose your own color scheme or this tool is on the same par with all "cool kids" who think anyone not using dark mode is unworthy?
I have quite strong astigmatism (although I've never heard it referred to as a "disability"). I am completely unable to use software with a dark background.
If dark mode is enforced, then me and a lot of other people are excluded from using it.
What are you talking about? Where, in God's name, on my above comment I even hinted at that? All I am saying is if you go the trouble to create something that has different color scheme than your underlying operating system, then be smart enough to create settings to let users select their own colors.
You either create your app with default coloring and you let the operating system set your colors according to the user's theme preference OR add these in settings. I hate programmers who think their color preference should be the only one, and not just that, but also state it proudly with a "it doesn't burn your eyes".
Apparently you still beat a dead horse. Lemme make it clear for you, so there is no misunderstanding. I do not nor have said anywhere that I have disdain for people with disabilities.
Furthermore, coloring is an end-user business, not yours as programmer. Lemme explain this as well, since I am somehow under the assumption you are missing a full point of how modern operating systems works.
All modern operating systems have a window manager that is in charge of setting, among a lot other stuff, also the colors. They get those colors from the end-user current selected theme. If the end-user wants in his theme a memo to be red and a combobox to be black, then all the programs running on that end-user better have memos red and comboboxes black. Any one of those programs that do not let the operating system set their font, font color and background color of various components are breaking the end-user trust. And here is the amazing kicker! You, as a programmer, have to do absolutely nothing about it. All modern IDE's/compilers will do this by default.
Now, if you mess around and change that because you, as programmer, "know better" then you're a poor programmer. One way to redeem yourself is to let your users set the colors in your program under a Settings page.
Final thought. In regards to user with disabilities, they have different disabilities and different coloring needs. So this "cool kid" who thought dark mode is not burning their eyes, is the one disregarding them, not me.
A little stretch ... yet I needed a decompiler for Mac a while ago and used https://www.hopperapp.com/ (also recommended on the German fanboys.fm podcast). found it was doing its job quite well (with a couple of helpful features, espcially the flow control graph).
Sorry, I hate dark mode apps. Too much eye strain for me. Give me a terminal screen with dark grey letters against a not quite white background and I'm good. Too many books when I was younger I guess.
I used to criticize those who use dark modes, but then after trying it I think I cannot go back again. At the end of the day, it's like when we were using monochrome screens back in the 80's/90's. I don't think anyone at that time used a screen filled with green phosphor color in the background with black characters on top. It was green/amber chars over black background.
I think that the difference in comfort when reading is that in the case of a book the light is reflected, instead of emitted, like in a monitor.
Recently I had a series of very intensive sessions with Ghidra, and jumping through hex code for hours was really hurtful, until I learn Ghidra has a dark mode (an ugly one, just colors inverted).
Yeah, but in those days we did that because there wasn't any other option. It's not like the colour scheme of the monochrome terminal was chosen for ergonomic reasons.
If anything, amber terminals were easier on the eyes. Or the white on black ones. Those were nice.
When I go outside green is the color my eyes are looking for to relax. Also pixels in the white background emit the maximum energy. One reason Apple introduced the dark mode is the pixels to emit mostly the valuable information and save energy , thus saving the battery life.
The white background is fine for the eyes, so long as the brightness is set properly - minimum brightness for the surrounding lighting with medium-high contrast. IME, this setup in a well lighted office makes a marked difference in eyestrain at the end of the day when compared to dark modes, dark rooms, and high-brightness light modes.
It's totally individual though. Back when we finally got terminals with white background I was very pleased. A co-worker was completely unable to use them though - he had to set the terminal to reverse mode. We talked about it and it was clear his eyesight was completely different from mine. There's no "one size fits all" here, and I for one have problems with dark mode - I see "flares".
This is precisely why I use f.lux[0] on every computer. As the blue light is reduced toward evening, the screen becomes much less bright. Works great for eye comfort and is maybe even beneficial for sleep.
There is no evidence dark mode is better. In fact, human eyes don't have good night vision, we see best in daylight.
Light text on a dark background makes the eye work harder and open wider, since it needs to absorb more light. When this happens, the light letters can bleed into the dark background and cause halation. Our eyes focus better when the iris is narrow.
Additionally, most people are born with some form of astigmatism, a misshaped cornea that blurs vision. For people that have the worst forms of astigmatism, light text on dark backgrounds aggravates the condition. When looking at a light display, the iris closes more, decreasing the effect of the deformed cornea. When using a dark display the iris opens to receive more light and the deformation of the cornea makes halation worse.
On the flip side, dark mode helps with floaters, tiny fibers or spots that appear in a person's vision. These are caused by changes to the fluid in the eye which cause shadows to be cast on the retina. Floaters distort vision in light mode. This condition tends to increase with age.
Also, people with light sensitivity might be better served by a dark background.
I have found that dark mode works best in low light, 100% contrast can be harder to read with more eye strain, reading large amounts of text in dark mode is harder.
It is frustrating when people who work in IT don't take accessibility seriously. Not everybody is young and in perfect health. Both light and dark mode should be offered for accessibility reasons.
Green letters doesn't seem eye friendly at least to my eye. My eye much prefers white on dark grey for emissive screens (LCD, LED) or black on white for reflective screens (e-Ink).
I had the impression that pre-1980's screens were green for chemical reasons not for eye-strain optimization (?)
Under the hood, Capstone use LLVM's TableGen as a source for descriptions of registers and opcodes. http://llvm.org/docs/TableGen/index.html
I've given ImHex a test run on an Amiga binary and it kind of works. However, the Amiga Hunk format (equivalent of ELF) is not recognized, and is interpreted as opcodes. Also there are issues with copper lists.