Introducing Frhed

Oh my, my second blog post today. This is the long overdue introduction of the project called Frhed.

One weakness of WinMerge for some users has been poor binary file handling. WinMerge can compare them (tell if the files are identical or different) but not much else. Also binary file detecting has been quite strict and some perfectly good looking text files have been determined being binary files.

To overcome these restrictions Jochen implemented binary file viewing for 2.8.0 stable release. It encodes binary files to text files for textual compare. And shows results like normal text file compare. But bytes that cannot be presented as characters are shown as their byte value. I liked this approach and in my personal opinion it was all we needed. Real binary file compare would require rewriting lots of WinMerge code.

Few months ago Jochen submitted a patch that added new binary file compare + editor code to WinMerge. Jochen basically integrated existing Open Source binary file editor called Frhed to the WinMerge. Doing lots ot refactoring in the process. One big refactoring is to move most of frhed code to dll we can load to WinMerge and show the editor window. This dll editor component is called heksedit.

There was one real (and for me a big) problem with this. The Frhed upstream development weren’t been active in years. Who would fix the bugs in Frhed? It could not be only the WinMerge developers. We have real problems to fix bugs in WinMerge to take yet another codebase to our maintenance. Look what happened with CrystalEditor. WinMerge is perhaps the only project publicly developing it.

I still thought we had a real use for the Frhed and it looked like a nice stand alone editor too. So I contacted the original Frhed author and asked if he would allow me to take over the project maintenance and create project for Frhed into Sourceforge.net. As the original author agreed I can do this I then created the project.

Goals of the Frhed project are:

• to develop stand-alone Frhed binary file editor.
• to develop heksedit dll as an embeddable editor part of the program. Currently WinMerge is the only client but I don’t mind other clients.

So far my personal target for Frhed has been towards the first alpha release. Which means getting basic things in order, like building, manual, versioning etc. I think there are only couple of details left and I can create the first alpha release next week. The release has been delayed mostly by lack of time (WinMerge release and all kinds of other stuff).

One very important thing to note is that WinMerge project will not develop Frhed or heksedit other than perhaps some WinMerge-specific changes (should be very minimal). All Frhed-related patches, bugs etc must be submitted to the Frhed project. New translations and translation updates must be submitted to the Frhed project, not to the WinMerge project. WinMerge project only gets certain revision or release of Frhed as its binary file editor.

Somebody might wonder if all this trouble is really worth of it. I already gave one example why it is – the CrystalEditor. The CrystalEditor was developed years ago. I think it was somewhat active when Dean (?) decided to use it in WinMerge. But since then the project has been practically vanished from the net and WinMerge is only remarkable project (that I know of) using it. There was project called Textcenter that tried to develop CrystalEditor further. But even that project has been inactive for years. For us WinMerge developers it would be ideal we could just pick release of some editor component and trust it just works for us. And we could concentrate on developing features that are related to comparing and merging, not basic editor stuff. We do that with other libraries like PCRE and expat. We don’t fix/develop them.

In the lucky case the Frhed project itself gets some interest by people and we’ll get new people helping in developing it. Please remember Frhed is a separate project – developing Frhed does not mean you need to touch WinMerge code. And Frhed project has no limitations WinMerge has – it does not use MFC so it can be developed using free version of Visual Studio.