The Plugin Hex converter doesn't appear to be correct?

  • I copied/pasted a foreign line from an e-mail into a .txt
    file with w/NOTEPAD in Windows (saved as Unicode).

    I then used my own MASM hex dump program and compared the
    O/P to what NOTEPAD++ says; they are COMPLETELY MIS-MATCHED?

    my program:
    00000000 FFFEA8607D590CFFA86084762C67216B …}Y....v,g!k
    00000010 6B531F75448D3C681062E97E2A67BE8F kS.uD.<h.b.~*g…
    00000020 07680CFF2C670459EF53D0630652CD64 .h…,g.Y.S.c.R.d
    00000030 5C4FC78F0CFFE68BE28B510051001AFF \O…Q.Q…
    00000040 35003100390032003400380033003600
    00000050 31000CFF758D 1…u…

    NOTEPAD++ 8.1.3:

    an old SPF2/PC 16bit hex editor,
    which matches my program (1st x’10’ bytes):

    I also caused my program to crash/dump, and used WinDbg to
    see what was read into a buffer (via WINAPI Readfile), and it
    matches what I printed:
    0040e000 ff fe a8 60 7d 59 0c ff a8 60 84 76 2c 67 21 6b 6b 53 1f 75 44 …}Y....v,g!kkS.uD
    0040e015 8d 3c 68 10 62 e9 7e 2a 67 be 8f 07 68 0c ff 2c 67 04 59 ef 53 .<h.b.~*g…h…,g.Y.S
    0040e02a d0 63 06 52 cd 64 5c 4f c7 8f 0c ff e6 8b e2 8b 51 00 51 00 1a .c.R.d\O…Q.Q…
    0040e03f ff 35 00 31 00 39 00 32 00 34 00 38 00 33 00 36 00 31 00 0c ff .…
    0040e054 75 8d 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 u…

    Am I using the converter correctly? The doc doesn’t seem to
    have anything on the use of this plugin. The characters are wrong,
    the prefix (BOM) and the nulls (#519248361) are missing…

    Thankx for your time.

  • @IRI ,

    The Hex-Editor plugin (note it’s editor, not converter) has not been actively developed for some time.
    However, the Hex-Editor plugin isn’t exactly what you seem to be thinking it is: it gives a hex display of the contents of the editor (after Notepad++ has read in the files and applied the encoding for interpreting the bytes from the file) – hence, it doesn’t show a BOM (because the BOM isn’t text to edit), and it shows Notepad++'s internal representation for the bytes of the text, rather than the representation of the raw bytes that are on the disk; it’s not how I would have designed the plugin if i were a plugin designer… but I’m not. If you want a true hex editor, which will give you the raw, unadulterated bytes of the file on disk, then the Notepad++ & Hex-Editor plugin is probably not the tool combination you are looking for. (Personally, when I need a hex editor once every year or two at work, I pull out HxD. But Notepad++ isn’t affiliated with HxD, and you should take that as a personal recommendation, not as an official recommendation of this forum or of Notepad++ itself.)

    (And, as an addendum, Notepad++ is designed as a text editor; the file you seem to be editing does not appear to be “text” to me.)

  • Could this be what OP is talking about?:


  • @Alan-Kilborn ,

    Oh, yes, that does seem to be a valid alternate interpretation of what the OP asked – and probably fits the OP’s phrasing better than my interpretation, with the mention of “converter”.

    If that’s what @IRI meant, the bulk of my answer stll holds: that Converter > ASCII->HEX command is giving a hex display of the contents (or selected contents) of the editor window, not of the bytes underlying the file itself. Depending on the encoding used, and which characters are in the editor, those two series of bytes can be significantly different (and the BOM will still not be shown, because it’s not in the editor window). And it was still meant for text, not binary data.

  • I appreciate your explanation. Unfortunately, “interpretation”
    is NOT what I want; “raw” is. Let me explain…

    I was working on the problem w/the newer PROCEXP that causes
    ‘netsh trace’ to lose data. I wanted to know when the data was
    lost or not, so I looked for a particular character string in
    the created .etl. As I’ve done many times, I used ‘findstr.exe’
    to look for it, but, it kept saying it wasn’t found. NOTEPAD’s
    “interpretation” shows it, NETMON itself shows it, even my own
    FIND program shows it. This drove me nuts!

    Finally, I used my hex dump program to get a “raw” hex dump,
    and that instantly explained the problem! It was in UNICODE;
    each byte was a DBCS, with a null trailing each. I guess
    ‘findstr.exe’ (Win7) can’t handle that (maybe using a hex file
    for the string?), whereas my own FIND handles Unicode (it DOES
    use a file for the string, and handles both ASCII and Unicode).

    So, I’m looking for a GUI program to more easily examine files
    for situations like this, tho a hex editor would be nice too.
    Currently, to create hex files, I use another of my own programs,
    as well as the old SPF2/PC hex editor “GUI”. I’ve had similar
    situations before, where a hex dump explained what the problem was.
    The old SPF2/PC program works great, but I don’t know how long
    16bit will be supported, even with DOSBox, tho it works in Win10.

    Oh well. Anyway, thankx for your help.

  • FYI: A nice, clean, simple hex editor is here:

    It has a “normal” portable .zip, where no OS changes are done.

    I didn’t like the HxD editor .zip as it expected me to run a
    Setup.exe, which implies that OS changes would be done; I don’t
    allow that on my systems, except after a system backup, and only
    to run it under the Guest logonid which has no system authority.
    If it attempts to do so, then I won’t use it.

  • @IRI
    We are all free to decide what constitutes the important criteria for selecting our tools, but I believe you are conflating ‘would’ with ‘could’ in your statement: ...Setup.exe, which implies that OS changes would be done. I’ve happily used the ‘portable setup’ versions of HxD for years with no problems. I’ve also tried FrHed and XVI amongst others and not returned to them. I hope you are at least as happy with your choice of tools as I am with mine.

  • @IRI

    I agree with @artie-finkelstein – I’ve never “installed” HxD to use it.

Log in to reply