HWACHA

For the curious, here is the current state of AXE 4, as I see it right now. By right now, I mean September 30th, 2006.

It would be nice if I could answer the question 'how near is it to being done?' However, that's impossible because I don't know everything that will go in it, and I don't know everything that will have to be redone -- it seems to me that a few things could benefit from being done in native code rather than C#.

So, all I'm trying to do here is give an idea of what has been accomplished. The long half of the journey, I'm afraid, is yet to come. Currently, most of the work is going on the GUI. Enough basic functionality has been done that documents can be loaded and edited, and now a great deal of GUI infrastructure is required before advanced features are added.

I/O

Files

Support for simple files and large, in-place files (i.e. paged files) is 100% done and has been for ages.

Devices

Support for logical and physical storage devices is 100% done, but performance is a bit on an issue. .NET does not allow the kind of efficient IO that would make it practical to (for example) grep an entire disk for a string in a reasonable amount of time. Whether this can be speeded up, or whether it will have to be rewritten, is hard to say at the moment.

The GOOD news is, that opening a device is an awful lot nicer in AXE 4. Take a look at that screen shot. Now remember that unbelievable 'thing' that AXE 3 makes you use. Please notice how you are no longer expected to type in the physical device number!

Memory

Physical memory is not done yet -- I'm not sure if anyone actually used it so it may never be done.

Virtual memory is done, and works MUCH MUCH better than it did in AXE3. No longer do you get a funny dialog box up from which you pick just one slice of memory -- your document now is the process' own memory space, complete with annotations and regions that show what areas are mapped how. It's really nice.

Structures

Structure Model

Structures are 90% implemented, and they are much more powerful than AXE3 ones. Good. At some point I should write a complete description of the new system.

Structure Files

Currently, to specify a structure you need to basically write a bit of C# code that defines the structure, using a mini-API for that purpose, and the code is then compiled on the fly...

Obviously this isn't good enough and there should be C and/or C#-like structure definitions that AXE can parse, but this is not done and it's a very time intensive thing. It's one of the areas where if anyone has suitable code or expertise, perhaps we can do a deal...

Scripts

AXE4 scripts consist of C# code that's compiled on the fly, and are thus infinitely more powerful than the AXE3 script language. There's some work to do on the internal script API, though -- I'd call it 50% done.

Editing

Clipboard

10% done. You can cut and paste, but only raw bytes and only within AXE. There's no windows clipboard access. It's not hugely difficult, though; it should take only days to implement.

Cursor movement, inserting, etc

60% done. The mechanics of moving the cursor around, selecting, and typing are surprisingly complicated and hard to get right. I'd say it's a bit over half done, but it's the kind of thing that I know tends to drag on. It's boring to do, too.

Search/replace

40% done. I can't express how much I hate implementing this, especially as I have already worked on two major projects in my life that involved a full set of Visual Studio like search and replace functionality. It's surprising how much state has to be maintained between searches, and how much can go wrong.

Masks

The new mask system is 50% done -- actually, it's 100% done, but I'm 0% sure how to express it in the GUI. I might wind up exposing only a subset of the mask functionality, simply because I'm not sure if users will be able to take full advantage of it.

GUI

Oh, my, the difficult part of AXE. You'd think C# would be far nicer to work with than MFC, but in the end you wind up battling a fairly similar set of 'hey, that bit moved and I don't know why' kind of issues. A major problem is that the Visual Studio designer is SO broken -- when faced with anything remotely complex in the way of nesting or inheritance it just dissolves into error messages and malformed wizard code. It's been quite a disappointment.

Docking window system

This is done, using DotNetMagic, and it works very well.

Menu system

This is not done. Menu management in AXE is non-trivial; a given operation can often be done from the main menu, via a toolbar button, via a popup menu, and via a keystroke and all those things have to be kept in sync, channeled through one handler for maintainability, and greyed out / highlighted / disabled together. I am still considering what the strategy will be.

Hex Views

80% done. This is a big part of AXE and I'm glad that it mostly works. The column width system is a bit different now, but in general it's much like AXE3 to use.

'Map' Views

0% done. This is the 'graphical' view type in AXE3. It's not all that difficult to implement, although AXE4 is going to have a rather more complex system than AXE3 did; hopefully I will have time for a complete description later.

Structure Views

Not done. Hard. Need to wait until more infrastructure is in place.

Resources

I really need icons! There are no icons for AXE4 yet, I don't want to re-use the AXE3 ones and in any case I need different icons. I basically need about 40 nice custom icons to be dropped in my lap -- unfortunately this seems unlikely to happen.

Analysis

None of the 'analysis' features is done. Generally, they aren't hard; the hard part is in the GUI elements that bind them to the regular editing view. Analysis features that I plan to add include:

• Periodicity -- like the 'Auto Line Length' feature in AXE3. This is incredibly useful for some people but in AXE3 it's not integrated very well.
• Entropy map -- divide the file into regions by 'entropy' level, ie by degree of randomness. Very useful for large files that contain a lot of corrupted 'noise' regions.
• Checksums / digests -- much like AXE3.
• Histograms / statistics -- not hard.
• Grammar -- AXE3's grammar generator is interesting but it could do a lot more, especially in terms of mapping the grammar to the actual file. In AXE4 I hope to get a lot more value out of the grammar generator.