While adding support for editing and viewing text encoded in UTF-8 to HxD’s hex editor control itself, it turns out I have to query Unicode property tables, that go beyond the basic ones included with Delphi (and most other languages / default libraries).
Parsing the structured text files, provided by the Unicode consortium, at each startup is too inefficient, and merely storing the parsed text into a simple integer array wastes too much memory.
A more efficient storage uses a dictionary-like approach, to compress the needed data using a few layers of indirections, while still giving array-like performance with constant (and negligible) overhead.
In the following, I’ll briefly present the solution I found.
HxD will extend character encoding support, and I am looking for the best way to name character encodings. So far, you can only pick between the following four to affect the text display in the editor window:
- Windows (ANSI)
- DOS/IBM-PC (OEM)
Additionally, in the Search window, Unicode (UCS-2LE) can be selected using a checkbox to override the current editor window encoding. I’d like the character encoding selection to be more uniform, flexible, and clear in future. Continue reading
One of the most common questions I get regarding HxD is about obtaining source code to understand and reproduce some of its basic functionality. The most frequent points of interest are how the RAM editor reads / writes memory of other running programs (i.e., processes) and how the disk editor reads from / writes to storage media.
Yesterday, when Mohamed A. Mansour, who will teach an Operating Systems class, suggested this information might be useful for his students, I thought it was a good opportunity to start my blog and write it up in a proper way.
This post is about reading memory that belongs to another running program (aka. process), and will be the first in a series of posts about the implementation and design of HxD.