Has this project been discontinued?

[FSharpCSharp]

This project is a very good hex editor. The last released version was only a beta version of the new version 5.0, but not much has really happened since December. Has the project been discontinued or has it moved? It would be nice to know what the project's situation is.

[DpEpsilon]

No, it's just that Andrew has not had as much spare time since late 2016. A few weeks ago I told him there was still interest in the project. I'll remind him again tomorrow.

[FSharpCSharp]

Many thanks for the information! It's really a great project, and it would be a pity if it wasn't continued for time reasons. I hope that there will be news soon! The last beta version looked really promising.

[DpEpsilon]

Andrew has given me write permissions to this repository. I'll see what I can do to get HexEdit up to date if I can find time over the next week.

[Tcll]

awesome to hear! :D
yes I'm still following XD
hit me up if you need ideas ;)

note that I exclusively use linux these days, but this is still perhaps the best hex editor in the wild for it for reverse engineering data.
although I do have a WinXP x64 VM set up if Wine decides to be dumb and break when running HexEdit
last I tried though, HexEdit was borked and I couldn't run it on WinXP for something with a native's symbol table...

as for keeping XP support, that's arguable and entirely up to you, but I still hope you'll support me :)
I'm only using XP (for testing my programs) because it's more secure than anything newer (I try to patch exploits where I can)

anyways, can't wait to see progress, and I hope you'll migrate things to be more cross-platform :D
(linux literally has nothing to compare)

I hope to lend a hand too when/if I can (I need IDEA/CLion support to be able to) ;)

[DpEpsilon]

Thanks for your interest! :)

My first priority will be to getting HexEdit to compile with VS 2017, and updating MFC. After this, I'll see if I can make it easier to develop with IDEA/CLion, or even with just a text editor. Hopefully we can then take a look at making HexEdit cross-platform (I am also painfully aware of how poor the selection of open source Linux HexEditors is right now).

I too am predominantly using Linux these days, and coincidentally I also have a Windows XP x64 which I used to use for infosec CTFs. HexEdit was a handy tool back then, and I'd prefer to keep WinXP support in case I ever compete again. However, if it gets in the way of support for modern systems, of course I'd prefer to drop XP support.

At the very least, I want to make sure people who are willing to contribute are able to do so. I'll be sure to test out the outstanding pull requests and look at some of the outstanding issues once I have my environment set up.

[AndrewWPhillips]

Hi, I haven't done anything with it for a couple of years as I got a great new job which has been taking most of my time. And: * there didn't seem a lot of interest in it * there are better Windows hex editor available nowadays * Microsoft stopped distributing required ASCII libs after VS2012 (sep. download required) and I didn't want to convert it to Unicode * templates can be very slow due to use of MFC grid control (no virtual. mode) At one stage I was going to rewrite it in C#, but have become more interested in Go and Rust recently. Thanks for your interest. Regards, Andrew.

…

On Fri, 1 Feb 2019, 17:21 FSharpCSharp ***@***.*** wrote: Many thanks for the information! It's really a great project, and it would be a pity if it wasn't continued for time reasons. I hope that there will be news soon! The last beta version looked really promising. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#21 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AIU-hk1YKP570MCvtwUH9pmPUU-Gp54oks5vI9zfgaJpZM4PXVBp> .

[Tcll]

@DpEpsilon: hoo boy you just gave me butterflies :D
can't wait! ^_^

btw, regarding XP support from my end (just to give you ideas)
I'm supporting XP in hopes to revive it, since it is grossly underestimated in terms of it's power (it's lack of standard support can be relieved as well)
but yeah, this is just me, if you wanna follow and have a stronger fire for it, cool, but if you don't, that's fine ;)

@AndrewWPhillips: I'm glad you took time to make a post :)
hope your new job goes well for you in the long run ;D

but regarding a few of your bullets:

there didn't seem a lot of interest in it

I've been spreading interest behind the scenes, but besides that it's disliked because it's slow and it's template language could be a bit more revised, aside from it's general feel...
otherwise I'm sure it would soar. :)

there are better Windows hex editor available nowadays.

arguably the only 2 I know about have been 010 and Hex Editor Neo, which neither are free and I could argue 010 is less intuitive, despite being seemingly more preferred
otherwise, I haven't heard talk of anything newer/better (probably because the community I follow is focused more on other stuff)
... the only thing arguably "better" that I know of is my own project (SIDE) which is a plugin for my primary project (UGE) with focus strictly for it rather than general use... but that's still in pieces since it requires UGE's API which is still incomplete.

but anyways...

At one stage I was going to rewrite it in C#, but have become more
interested in Go and Rust recently.

if I could make a suggestion to move to python3, it's much simpler to use, and more stable across platforms.
(note that you'll have to use Py34 if you want to keep XP support)

my previous shots of SIDE's hex viewer (actually all displays) were done with Py27+PyQt4 QPainter widgets
and you already know how those were much faster. :)
but while they seemed great, they were a real strain to have to deal with because Qt's support leaves room for more to be desired, not to mention it's still rather slow overall.
I'm tapping into winapi (user32/gdi32) + opengl32 window creation through ctypes (or rather my rewrite named cbin which includes wrappers for these dlls (WIP)) and hope to have some super fast performance out of that with a very minimalistic and portable interpreter (only 12MB in size)

@DpEpsilon: I'd be happy to share my works and knowledge if you're interested in my direction :)
otherwise, feel free to use what you like (might I recommend Java over C# (if you do look at that route again) because Mono sucks)

[FSharpCSharp]

Thank you for the interesting discussion. It's great that something is happening here again. Personally I don't care more or less if it was programmed in C# or C++, mainly it works and is good to use. Unfortunately I haven't found any really good Open Source Hexeditors that have been able to get close to this product. Too bad actually.

[mdsitton]

If C# is chosen one option for cross platform ui is https://github.com/AvaloniaUI/Avalonia as something similar to WPF.

If starting a C# project I would highly recommend looking into getting something started ontop of .NET Core.

With C++ of course there is Qt for cross platform UI.

I too am sorely missing a decent cross platform hex editor... Every platform I end up needing to use a different editor, and now with this one being mostly unmaintained for a while i'm lacking one for windows :)

[Tcll]

if you want, you could go my current route and manipulate windows at the base level with user32/gdi32
those libraries seem to be much more powerful than known (about as powerful as SDL)
and yes you should be able to keep it easily compatible with Wine so things don't break.

I'm working on this in python, but you can use any language of your choice that allows working with them. ;)
I recommend against C# and Java for that (though Java has it's own wm, so why even bother)
java's good and all for cross platform, but I have enough java programs killing my RAM, and would prefer there not be another.

if you want a recommendation from me, use C
but C++ is okay aside from it's tediosity with Micro$**t's deprecation of everything

about the only thing I can see if you want REAL cross platform support with high performance and relatively low memory use is non-standard Py34 (__slots__ and such)
you're not missing out on anything Py35+ provides aside from minor performance and security improvements/fixes

I highly recommend Py34 for that, but it's up to you.
if you do, I recommend sticking to habits on your own standards for readability rather than following PEP8 which doesn't care about performance (and arguably memory) in most cases.

[DpEpsilon]

I'm not keen on rewriting in a new language due to the time involved, unless it could be done gradually (i.e. in Rust).

That said, if it becomes obviously too hard to port HexEdit to other systems, it may be worth the effort.

I have been running a bit short on time over the last week or so, having only really had time to set up a Windows development environment. I'm hoping to get something done this weekend, but I have some career reflection to do before a meeting on Monday.

[FSharpCSharp]

Just wanted to ask if there was anything new about the continuation of this project or about an adequate successor. Many people suggested to reimplement the project. Unfortunately I haven't found a repository where the development takes place yet. Thanks in advance!