Positional comparison for hex compare?

[gwideman]

How do I perform a comparison between two binary files, with hex display, where I want the comparison strictly between same locations in each file. So, the data at locations that are different would be marked red, and BC would not attempt to find later locations at which to "sync up" the two "streams".

Thanks, Graham

[Aaron]

Hello,

In the Hex Compare's Session menu -> Session Settings (or Rules toolbar button): Comparison tab, you can set Alignment to "None". How does this work for you?

[gwideman]

Hello,

In the Hex Compare's Session menu -> Session Settings (or Rules toolbar button): Comparison tab, you can set Alignment to "None". How does this work for you?

That's much better, thanks for pointing out that this falls under the idea of alignment rules.

Now, in the resulting display, with the "Diffs" button selected, how do I get each block of changed bytes to display separately, possibly with space between, and with row-start addresses set to multiples of 16? At the moment I get the display in the attached screencap -- all the blocks are jammed together (with a line drawn between) -- and it's difficult to work with the addresses.

Thanks, Graham

[Aaron]

Hello,

In the View menu, you can control the Layout for bytes per group, groups per item, and if it should Fit to Window. I believe Context Count is the value you are looking for here.

[gwideman]

Hello,

In the View menu, you can control the Layout for bytes per group, groups per item, and if it should Fit to Window. I believe Context Count is the value you are looking for here.

Thanks for your comment, but I don't know what combination of settings you are thinking of. I tried a few different settings, and all resulted in the several "result regions" getting displayed contiguously, separated by those thin black lines. That's the format I'm trying to escape from.

I want the result regions separated, so that their address display is on a round-number boundary. If it's 2 groups per item (like in my screen cap), I want the addresses to be multiples of 0x10. I don't want the start of the region to display jammed onto the end of the previous region. Am I missing a setting that does that?

[Aaron]

Hello,

Ah, so you are looking for a view mode which is based on "lines" of addresses. BC4's Hex Compare does not have this type of view; hex information is contiguous with configurable view modes. The address then represents any breaks that are present. Are you familiar with other hex software we could look to that have a display mode similar to what you describe?

[gwideman]

Hi Aaron, thanks for responding.

> Are you familiar with other hex software we could look to that have a display mode similar to what you describe?

The short answer is no, I don't. But let's examine what I was trying to achieve in the first place.

Again, the context is editing binary files that have a strict layout relative to byte positions. I'll call these "structured" files, as distinct from "sequential" files like text files, where the order of the bytes is paramount.

BC's compare capability with Hex display is useful for visually ensuring that I only change particular bytes.

I would be quite happy using All display mode which maintains regularly-incrementing addresses. However, with long files (10's of MB) it's extremely difficult to navigate to the differences indicated by the red marks in the margin. A one-byte mismatch is very hard to spot.

Diffs mode overcomes that problem, so a well-functioning Diffs mode would be great. Either that, or some kind of visual magnifier capability on the navigation margin.

Having switched to Diffs mode, now being able to focus on the regions of interest, and being primarily interested in absolute byte locations, it's crucial that the addresses be easy to identify. That objective is undermined by having the "lines" of bytes starting on random address boundaries. I need them to start on consistent multiples of the current bytes/row (8, 16, 24, 32). It seems to me that would be easily accomplished in BC by just separating the display of each Diff block by enough to get it to start at a round number on the next available line of display.

In BC that address display regularity also gets disrupted by editing, either delete or insert. A separate issue, but again relates to the disorientation caused by irregular line-start addresses.

I think the theme here is that inspection and editing of sequential and structured files involve different priorities. No surprise, that's why we have these two classes of data in the first place! Trying to work with one type of file using a viewer/editor/compare tool that's tuned to the other type is a problem!

So it's not so much "I'd like this particular viewing feature", as much as "I'd like it to be really good at inspecting and editing files that happen to be structured" (as well as maintaining the other set of options for sequential files).

I have tried tools that allow you to supply a definition of the detailed structure, and then present a view of the file contents composed into records and fields. Those tend to require a lot of preparation, and also obscure the underlying raw file contents so that the increased sophistication is not necessarily all benefit. So I don't suggest that BC go that far.

That's why if BC had a hex viewing mode which could be set for more structured-friendly viewing, it would be lovely.

[Aaron]

Thanks for the details. I'll add it to our Customer Wishlist for this style of View mode and organization. If I understand correctly, you'd like to have more regular "line" address numbering for vertical presentation, but diff sections can be any length. Should the context of the diff always start at one of these intervals, and how would you see handling large gaps between diff sections?