A revisit of an older article. You can view the original here.

Before ddhx, there was 0xdd.

0xdd

I always had a knack for TUI (text user interface) applications out of the MS-DOS era of computing. While learning C#, I’ve always had an itch to write my own for the fun of it. And so, my 0xdd utility was born.

0.1 – First Version

Released October 25, 2015, the first version of 0xdd saw its first release.

It featured an interface close to GNU nano, since it was (and still is) my TUI text editor of choice. Main functionality were opening files to view them, moving the camera forward (down, towards end of file) and backward (up, towards start of file). None of the shortcuts shown on-screen worked, they were placeholders, except to exit (Ctrl+X).

Fun fact: A development build introduced a bug where bytes 0xe0 to 0xff were not properly rendered into the character column at times, rendering it as a space instead of a dot.

When this version was released, my old GitHub username was guitarxhero.

0.6.2 – Last of GNU nano-like

Released April 13, 2016, this featured the position percentage field. Version 0.6.2 was the last version to use a GNU nano-like interface, because it was taking too much vertical space on the screen.

Once again, ^E (Ctrl+E) for “Edit mode” was a placeholder. Call it optimism.

0.7.0.2 – EDIT-like

Version 0.7.0.2, released February 15, 2017, was the last version released of 0xdd.

By then, the hex viewer was reskinned to an EDIT-like interface (as in, the MS-DOS command), boasting a menu bar and various dialog boxes.

The percentage position marker was aligned to the right of the screen. I believe this forced some excuse out of me to write across the entirety of the console buffer.

ddhx

For a need to learn a system programming language, I started learning the D programming language some time in 2016.

After toying around the inlined assembler and released ddcpuid in 2016, I looked for other personal projects to rewrite in D. ddhx is the result of my second long-term project, born in 2017.

0.0.0-2 – Reborn

Released September 24, 2017, ddhx — for “dd’s Hex viewer” — saw the world with version 0.0.0-2.

Because a GNU nano or EDIT interface would take too much time to implement, ddhx has stronger design choices closer to vim, the text editor. Accidentally, this also allows trimming off the menu bar for an additional row to be displayed.

The status bar indicated the size of the view buffer in bytes, the current position in binary size, the total size of the document, and the position reported as a percentage.

A command-prompt system was introduced. This allowed a wider selection of features to be used quicker, because, well, this is a TUI, it is already keyboard-oriented.

The reason why the command prompt is at the top of the screen is due to the std.stdio.readln function. When hitting the Enter or Return key, it printed a newline character, which, if placed at the bottom, would scroll the actual screen downwards, and mess up the screen.

Messages were printed at the bottom, where the status bar is, as a custom to pretty much every other text editors.

ddhx was still, in principle, a hexadecimal file viewer.

0.3.3

Version 0.3.3 was released November 27, 2021.

So far, we’ve seen small, incremental updates. Visually, only the hexadecimal formatting was relaxed to use lowercase characters, and the offset addresses are now prepended using spaces instead of being filled with zeroes (but not columns, oops!).

0.4 – The Last Viewer

The last “hex viewer”, version 0.4.2, was released April 28, 2022.

Version 0.4 saw a bit of an uplift in its design. The left offset column is wider (11 columns) to avoid moving the screen sideways less often when navigating in large files (>=1 TiB, not that it’s a realistic issue…).

The status bar is now more informative, displaying the current data formatting (Hex), character set (ascii), view buffer size (368 Bytes), position as a binary size (1.1 KB), and the percent offset marker.

The Idea for 0.5

After version 0.4.2 was released, I was already thinking to introduce editing features into the hex viewer.

At the time, I was comfortable using HxD (and HxD2), so it wasn’t really stressed onto me that, you know, that I might move out of Windows as my main operating system, or x86 as my main machine platform. Even if HxD seems to work fine under WINE, that’s still a setup requirement that might not work in some eventual future.

And then, it happened: In mid-January 2025, I finally moved my main desktop computer onto a Linux operating system.

Mid-way through 2025, after realizing that I needed a hex editor, and seeing the current options on Linux were rather disappointing in some way or another, it’s only at this moment when I restarted my efforts to add editing features into ddhx.

Back when I wrote the first version of this article after releasing 0.4.2, I knew I wanted to add editing features, half-knowing what I wanted. Things like adding more crap to the status bar:

Speaking of, here is an example design for the new statusbar:

ins | hex | ascii | 368 B | 1.1 KiB (0.093516%)

And even then, I somewhat observed that:

Comparing this to HxD2, this is already more information than necessary, but crucial in a tightly packed TUI app, since I have much less space.

I figured this can’t work out. There is no way to keep polluting the statusbar with useless information. I used to like having as much information as possible, but as one might add, that’s the old me.

I needed an anchor to take design hints from… Oh, right, text editors.

0.5 – Finally, an Editor

After multiple attempts at software architecture (rewrites), version 0.5 was released September 25, 2025, almost exactly 8 years since the first release of ddhx.

Version 0.5 revamped the look and functionality, finally making ddhx a hex editor, even if it only supported append and overwrite operations.

The address marker was renamed from “Offset(hex)” to “hex” for compactness.

A virtual cursor was added, highlighting the current element (byte) to edit.

After checking out a few text and code editors, I settled with a more appropriate statusbar:

• A write mode indicator: OVR (overwrite), INS (insert), and R/O (read-only).
• Data mode: “x8” is a short name for 8-bit unsigned hexadecimal.
• Character set: Same as data mode, but for the current text encoding.
• Position: Absolute cursor position in the current address format.

Write mode indicators are an artifact of an older era, but since I didn’t want to introduce operation errors, write mode indicators were chosen over cursor shapes. While cursor shapes in modern editors are mostly figured out, there is still ambiguity among some programs and terminal. The mode indicator in the statusbar are both more explicit and reduces complexity in rendering. It’s immediately recognizable, and needs to be known whenever switching modes, just like in Notepad++, VSCode, Visual Studio, Xed, gedit, and many others.

The data mode “x8” is simply an identifier. “x” and “8”, while more descriptive than just “hex”, are used for two things: Type and Width, but identifiers can have any name of their own. And “ascii” is in lowercase because it is the identifier name for the character set in use, since there’s no need to type it in capital letters in the command-line. Eventually, more formats and encodings will be supported.

Position alone was chosen because most text editors do not include the total size of the document in their statusbar, and remains closest to a COLUMN:LINE indicator. Percentage was overkill, even with the absence of a virtual scrollbar, and the reason why a “report-position” (Ctrl+P) command was implemented.

Speaking of commands — The command syntax was made closest to a command shell. Command names are clear and easy to remember (e.g., “left” is a short name used frequently to move the cursor to the left, and “report-position” is longer for its infrequent use) and allows clear separation of arguments (e.g., “goto +0x40”). “quit” (or Q shortcut) is easier than entering a “:q” command.

Since the hex editor acts as a text editor, it’s important to have an indicator when an edit is performed, but where? I figured that having it closest to a corner increased its visibility, and thus why it’s at the very start of the statusbar because it is an indicator, and thus the first thing written when rendering it.

Taking an analogy to text editors was an interesting design choice, since we tend to learn faster from existing ideas. “It’s just like that thing!“

0.6 – Selection

Version 0.6 was released 3 weeks later, October 12, 2025.

Like any other text editor, selection is a vital mechanic to perform operations over a portion of data.

It was clear to me that a special statusbar behaviour was needed to display selection information.

In this case, prepending “SEL: ” is a clear, immediate indication that a selection is being performed. The range displayed is inclusive, and the total selection size is in bytes to reduce headaches. Similarly, VSCode shows a total count of selected characters, useful to know the length of a string.

Shortcuts. Because the Q shortcut (to quit) seemed too easy to press, even if there was a check asking to save edits, I remapped “quit” to Ctrl+Q, to confirm the action of quitting. The usage of the control key to quit is seen in other programs like Firefox (Ctrl+Q and Ctrl+W), GNU nano (Ctrl+X), and VSCode (Ctrl+Q and Ctrl+W), Xed (Ctrl+Q), gedit (Ctrl+Q), and possibly many others.

Ideas for 0.7

The only plan for 0.7 in terms of visuals would be not rendering address rows past the end of document, since most text editors don’t do this by default, as observed in Xed, VSCode, gedit, Notepad++, and Visual Studio. This is only for appearance, but helps when seeing where the document ends.

A customizable statusbar would be nice, but isn’t a hard requirement at the moment.

Otherwise, I think that’s pretty much it! Both versions 0.5 and 0.6 focused on navigation, acting similarly akin to a text editor, and I believe I’ve mostly nailed it down.

Now, I just need to do a new backend to support insertion and deletion operations.

What a journey. A decade in the making, on the side, making up a cozy little hex editor.

(Wait, a decade? That’s worse than Valve Time…)