ShineInHex - hex view/edit control

[Howard]

Hi Ramguru

I've basically been comparing your control from a stand-alone pont of view with James Brown's HexEdit which I've used for several years - best I've ever found - stepped up from MadEdit in MSDOS. I think you mentioned his name earlier in this thread. His is the only hexeditor I've come across that can genuinely copy & paste (has 1 or 2 bugs in Search, but fixes coming I think). I use that facility quite often. I've tried dozens of hexeditors - none compare to James' - but yours seems to be shaping up well, especially with the control thing in mind. The copy-paste-overwrite would pretty well finish it off.
For me I don't currently see a use for pasting outside the control.
We load stuff into the control to view it, monitor changes instigated by the parent, and manually manipulate it if necessary.

I couldn't paste into the Find dialog either.

I agree with your comment about paste-insert - really a no-no in hex editing, because most of the time we are dealing with fixed length files - eproms etc. That would be scarey!

You mention 'double-view' - if that means two concurrent windows into a hex block, that sounds real good - and triple-view... :bg

I haven't seen mention of rc2dlg converter - I'll search for it -sounds like you're having lots of fun :clap:

Howard

[wskjuf]

Hi Ramguru,

It's very good. and i suppose if it could give a better support for  diplay  of 64 bits length files in future, then i can deal with 4g bytes over files easier. sorry for my poor english.

[ramguru]

Thanks for your all feedback...
wanted to reply and post update at the same time, but that's not easy thing to do, 'caz I'm working on multiple projects, one fails everything pend :) . ATM having some issues with tab control also it doesn't  very well fit with ShineInHex design so I'm experimenting with "FireWorks CS3" well I'm not very good at graphics  :wink

I've basically been comparing your control from a stand-alone pont of view with James Brown's HexEdit which I've used for several years - best I've ever found

Well I'm not very self-confident at this point James brown is MVP, he has worked in M$ - what am I compared with him  :red (And yet HexEdit 2 is coming soon, I will be planted in the right-invisible place)
But I agree his HexEdit had some impact on this project, wanted to make something similar, better, what I would love  :toothy

For me I don't currently see a use for pasting outside the control.
We load stuff into the control to view it, monitor changes instigated by the parent, and manually manipulate it if necessary.

I couldn't paste into the Find dialog either.

So from your comment I assume you find some copy commands useless, could you be more precise and name them  ::)

I don't understand why you couldn't paste copied data into Find Dialog. Let's say I select "14-06" then execute "Copy->Hex" then run "Dialogs->Find" check "HEX" radio button & paste data into edit field, I would be able to look for that data then "1406" or reversed data "0614" by pressing "Find" button as many times as this data occur.

You mention 'double-view' - if that means two concurrent windows into a hex block, that sounds real good - and triple-view... :bg

I imagine this feature as parent-dependent, meaning in one-side there will be one instance of ShineInHex on other side the second instance, it will help to see differences in both files. Or maybe you have something else in mind, please share...

Hi Ramguru,

It's very good. and i suppose if it could give a better support for  diplay  of 64 bits length files in future, then i can deal with 4g bytes over files easier. sorry for my poor english.

Hi, wskjuf
I doubt about 64-bit support, you see it would be  10 times wiser to create two versions of hex-editor one for 32-bits one for 64-bits (I mean different OSes). 64-bit programming supports 64 bit registers - so it would be no big problem converting. However I have no 64-bit CPU...and cannot start digging into 64-bit world  :'(

[ramguru]

This is a preview of upcoming feature - structure viewer (later editor too)
You can give some suggestions at this stage  :wink
Now it exists as separate project (not yet integrated in ShineInHex) you can download and test it.
It does something serious at this moment:
1) reads structs.txt file that contains all the user-defined structures, as an example:

Code Select Expand

>BITMAPFILEHEADER
bfType      dw ?
bfSize      dd ?
bfReserved1 dw ?
bfReserved2 dw ?
bfOffBits   dd ?
<
supported keywords "db dw dd df dq dt dup"
you can see ">" indicates beginning of a structure, "<" indicates its end (btw 1-st structure in structs.txt should begin after newline separator). The toughest thing here was to create dynamical memory allocation model...you know  - app allocates memory, then allocates more memory and places a pointer to that block in previous allocated block, then allocates even more memory and does the same thing, so you understand freeing was just same painfull.
2) determines if struct member is an array and of course all data sizes
3) it shows values in big-endian form

Structures won't be constrained by any offset (meaning IMAGE_DOS_HEADER can only begin at 0 offset). Structure-viewer data will be changing in real-time according to selection. Also at any time user will be able to switch to other structure.

My current unknowns are:
how to show (draw) big arrays, say "x db 512 dup (?)" not filling all the screen with numbers :)
is it worth to show numb. in decimal ?
is it worth to deal with floats ?????



[attachment deleted by admin]

[Jupiter]

Hi ramguru!
Great work, really!

Nice idea with Structs.txt

Well... let's talk about bugs found ;)

1. TAB instead of many spaces in Structs.txt is not supported - app crashes!
2. Extra symbols after structure's title (see screenshot)

Keep this good work!
If you need any help - contact me via e-mail.

[ramguru]

Big thanks, Jupiter
I'll try to fix everything you've mentioned ASAP.
Also decided to add decimal preview for struct_members <= sizeof(DWORD) (not for arrays)
Keep posting suggestions  :U

[Jupiter]

Keep posting suggestions

Some options for single click:
Struct Title - Roll / Unroll struct
Struct Field (member) - highlight line

Some options for double click:
Struct Title - copy entire structure (formated as MASM struct syntax)
Struct Field (member) - copy value and name (e_lfanew<TAB>80h)
Struct Value - copy value only (80h)

Display options:
"Zebroid" list style: light/dark row for better visual distinguish
Additional column(s) for decimal and string representation of field value (5A4Dh / 'MZ' / 23117)
Different colours for db/dw/dd etc (very nice feature I think)
Additional field description (for some fields): e_lfanew - PE header offset

Structs database (Structs.txt):
Allow TAB characters in file
Redesign displaying of fields: format string using TAB stops and string length instead of aligning using spaces (as it currently realized)


Implementation:
Define RECT for drawing place (if we need to draw structs somewhere else in the dialog)

[ramguru]

These are some serious suggestions  :U thanks
It will take some time to implement them  :wink

[Howard]

G'day Ramguru

Picking up on some of your points:

Thanks for your all feedback...
Quote from: Howard on August 08, 2007, 02:20:48 am
For me I don't currently see a use for pasting outside the control.
We load stuff into the control to view it, monitor changes instigated by the parent, and manually manipulate it if necessary.

I couldn't paste into the Find dialog either.

So from your comment I assume you find some copy commands useless, could you be more precise and name them 

I don't understand why you couldn't paste copied data into Find Dialog. Let's say I select "14-06" then execute "Copy->Hex" then run "Dialogs->Find" check "HEX" radio button & paste data into edit field, I would be able to look for that data then "1406" or reversed data "0614" by pressing "Find" button as many times as this data occur.

Thanks, you have enlightened me - I normally highlight the chtrs and press Control-C to copy. On reflection, you obviously haven't implemented that because you highlight both the hex and the Ascii simultaneously, which makes it impossible to decide, for a direct paste into the Find dialog.
A couple of comments here - could you make the Find box non-modal so that it's possible to edit on the fly; and secondly if you load a file, open the Find dialog and accidentally press the Find button with blank search string an error is generated.

For the Copy Commands, well so far I haven't required a facility to copy a section to outside the control (although use copy to clipboard many times a day in general file use - but that's already catered for by HexEdit), but I wouldn't presume to say that nobody else would use it. For me just being able to select maybe 40 bytes and use that to overcopy another section, sometimes once, sometimes many copies, is an essential use, and would save a lot of outside maniplutation.

Quote from: Howard on August 08, 2007, 02:20:48 am
You mention 'double-view' - if that means two concurrent windows into a hex block, that sounds real good - and triple-view...

I imagine this feature as parent-dependent, meaning in one-side there will be one instance of ShineInHex on other side the second instance, it will help to see differences in both files. Or maybe you have something else in mind, please share...

Yes, I had that partially in mind, but there are other ways of using this:
-  sometimes I want two views of a section of memory, one static (a snap-shot), the other dynamically updated, to watch for changes, and be able to compare with the snapshot without having to try to remember what it was
-  some occasions I'd like to view several sections of memory simultaneously as say in debugging, so more than two windows can be useful at times. In Visual Studio I often use up to 4, but VS only suits 80x86.

Thanks
(dreamy) Howard

[ramguru]

A couple of comments here - could you make the Find box non-modal so that it's possible to edit on the fly; and secondly if you load a file, open the Find dialog and accidentally press the Find button with blank search string an error is generated.

G'day Howard :) nice to meet ya

Yeah no problem, will include it in todo list
And I have just recently noticed that error (will be fixed of course).

but that's already catered for by HexEdit), but I wouldn't presume to say that nobody else would use it.

I'll do my best redirecting users from HexEdit to my control  :toothy

Yes, I had that partially in mind, but there are other ways of using this:
-  sometimes I want two views of a section of memory, one static (a snap-shot), the other dynamically updated, to watch for changes, and be able to compare with the snapshot without having to try to remember what it was
-  some occasions I'd like to view several sections of memory simultaneously as say in debugging, so more than two windows can be useful at times. In Visual Studio I often use up to 4, but VS only suits 80x86.

I doubt about one-static-one-dynamic-view-thing, 'caz at the moment I'm using memory mapped files, I'm dealing with direct changes, I don't know how it would turn if few instances opened the same file, may end in crash or in no read access. Regarding number of view I can make more than 2 but prefer even number :)

[Howard]

Hi Ramguru

I doubt about one-static-one-dynamic-view-thing, 'caz at the moment I'm using memory mapped files, I'm dealing with direct changes, I don't know how it would turn if few instances opened the same file, may end in crash or in no read access. Regarding number of view I can make more than 2 but prefer even number :)

You're thinking from the point of view of memory-mapped files. I'm thinking from the point of view of one file loaded to a block of memory by the parent and that same memory block being simultaneously accessed by one or more instances - which I'd deduced (hoped) should be possible for the control? I follow your concerns about more than one instance opening the same file - although in a slightly different context both Notepad & Wordpad don't have any qualms. And while on the subject, that's one of my few gripes with HexEdit - once it has got hold of a file nothing else can get at it. From a developer's point of view, (mostly) we know what we are doing and don't need to be protected from ourselves :wink

Oh... and even numbers is a lot better than no numbers.

Regards
Howard

[ramguru]

New version in first post:
...implemented multi_tab interface (using GDTabs);
...now read-only files can be opened with disabled input;
...fixed crash bug in find_dialog
...find_dialog now is modeless dialog-box with alpha feature

Sorry, Howard, no multiple views support (it doesn't fit in current design)
This update was more regarding test application...update regarding the control is coming soon

[Sameer]

excellent stuff mate

keep going ;)

[Draakie]

Hi RamGuru,

A fellow South African came up with a very novel idea of allowing grouping - during the edit.

http://www.nitrogen.za.org/junk/Elucidator.zip

Might make for an interesting feature...... :dance:

Draakie

[ramguru]

Thanks for the link Draakie
Was hoping to see those gradients in action  :lol but ...
So I had a play with that app to get the idea. And yes it's a novel feature. But if we sum things up. This Elucidator works only with decimal numbers which is good for users, but bad when it comes to editing, because direct editing is only possible with hex numbers. Also I'm working on similar feature: structure editor, which will order current selection into structure members. Next to hex representation there will be decimal one. Of course I agree it's not that convenient, 'cause it's not in-place change. But anyway I could make another feature like number grouping into BYTE (which is default), WORD, DWORD, so it would loook like:
99 88 77 66 55 44 33 22 [BYTE]
88 99 66 77 44 55 22 33 [WORD]
66 77 88 99 22 33 44 55 [DWORD]
Yet still thinking if it would make any sense ('cause structure editor does similar thing, and this would be applied to whole file)
Also I'm curious about that app, there is a messy column next to the scrollbar, is that a bug, or some kind of density/distribution indicator  :lol.