Base framework taking shape

Some of you will have looked at the source for HackerEX and noticed that there is an additional project in the workspace named zxStuff (or xsStuff if I haven’t uploaded the changes yet), this is basically my attempt to provide a c89/c90 based framework for HackerEX to rely on.

The reason for this framework shift is the following:

•  wxWidgets doesn’t support all the widgets/functions I desire
•  Compiling wxWidgets turned out to be a HUMUNGOUS pain
•  It gives me a better understanding of how C/C++ works

I figured since I was writing my own framework I best get it right the first time round so any ideas/fixes I had pop up in my head have been implemented at the first possible opportunity, which in turn allowed me to experiment with the general format/layout of zxStuff (which slowed me down on the short term but will prove faster on the long term).

I’ve now settled on a format/layout I am happy with and am in the process of ensuring everything is following that format before continuing with the rest of the framework (and of course HackerEX itself). This new framework will be much easier to compile than wxWidgets which in turn means people who wish to upgrade/expand HackerEX will have only a few issues compared to the seemingly endless number I encountered with wxWidgets.

I’ve already designed my own handler for text-boxes in C which is much easier to understand than the Win32 API that it runs on (will port to UNIX later after finishing HackerEX’s Win32 port).

Again I remind everyone that I am lazy so this may take up to a year before I have the next Binary uploaded, for now however I do a bit of reading then upload the current source of zxStuff and continue with changing the format of the remaining stuff.

Re-write…

I recently tried to compile my custom framework zxStuff in c89 and found out I had been using much C++ based code. Since the goal of the framework was to support this old standard I had no choice but to begin a rewrite before continuing with the application, the C++ side of it will continue to work the same once I finish but the c89 end had to be done 1st to prevent conflicts in the future as this will eventually be the only 3rd party framework HackerEX relies on.

Now some of you may have been wandering if this future change will effect backward compatibility, well worry not because I am designing HackerEX to rely on 2 external libraries that handle the data & gui, the data will not care which framework it is in because it shall use c89 style data objects (which are forbidden from having internal functions), this in turn means even if the handling is different the result will be the same.

This rewrite however does mean I may have to push my deadline back a bit, at most I only expect a push of 3 moths more as I have already done between 1/3 to 1/2 of the rewrite. For now I will ignore Unix support until I have Windows support functioning correctly (I am primarily based on Win7 but am aiming as far as WinXP – Win95 if I can help it).

Flexibility…

When I first started this project I had no clear vision of how I wanted it to operate, only that I wanted a GUI that didn’t have missing / broken functionality, as I programmed I had ideas flow through my head every now and then and in order to incorporate those ideas I had to improve the flexibility of the code. Now however I have finally settled on a structure that is convenient for both me and whoever wants to expand on it’s code base (namely the formats it supports). Right now I am currently focusing on finishing the core of the GUI/s, after which I will then bring back the full hacking functionality that it should support for now. Because I’m lazy this may take up to 3 months but I don’t think it will take longer than that but for now I have church to go to.

Update

You’ve probably been wandering what is going on with HackerEX, right now I’m developing an object that will be vital for supporting emulators, normal apps won’t care but emulators sometimes need to support integers / floats not supported by the host hardware / os which means that to support the search of these values I have to use a more flexible (albiet slightly slower) object that interacts with an array of bytes and gets the result desired, all other objects that interact with other variables can then wrap around this while maintaining the desired functionality. I’m almost complete with this object (floating values are the next on the agenda) and it will be thoroughly helpful in making the search algorithm more flexible.

On another note I got baptised last sunday (21/04/13), I did this to show my loyalty to God & Jesus as it they to whom we all answer and it is through trust in Jesus having died for us that we will go to heaven. All of what I do now would be meaningless if I didn’t hold this trust as I would be heading to hell for my sins in life (this program could possibly be one, not yet sure on that though).

Slow Progress

Hi all! Been a while, was mainly playing games but also did a bit of the interface on the side. The functions are mostly complete on the Database side, what ever is missing I’ll most likely catch when I make adjustments to the old GUI so that I may plug the Library right into it thus making much of each GUI behave the same as each other (minor differences may occur if one supports something the other does not).

I have now made untested support for the results GUI, instead of the limited support the previous had this new functionality will now allow viewing of all results regardless of how many there are (just not all at once), it will do this by loading the required information from the search files in chunks (number of rows * number of columns = max results displayed at once), the rows will be adjustable but the columns will be fixed to reduce the time it takes to set up the grid (if at all) for filling.

Before I can test the results interface I need to do the search interface (these need to be implemented simultaneously), this is proving to be difficult since I am trying to implement something that ArtMoney does, searching values at various byte lengths. This will take some time as I’m am trying to keep it efficient so that there is little noticeable difference in the time it takes to perform the search. It was simple on the previous GUI as it was a fixed length however as I’m now trying to take into account a variable length I am also having to adjust the way in which I test the values themselves so it will be a while before I get this right (also I’m lazy).

Once I have completed this I will upload the new GUI as a release candidate and begin working on plugging in the old GUI into the library instead of built in support. Whilst I’m doing that I would appreciate feedback on the RC to help identify missing functionality.

Hacklist interpreter complete

The new hack loading functions are now complete and use a much smaller amount of RAM while a hack is loaded, this in turn means that Hacklists that are ridiculously large can be loaded effortlessly.

While I still do not recommended using an old computer for this tool it is now capable of functioning without causing it to crash as long as the PC in question can offer up to 256MB of RAM (Educated Guess) to HackerEX.

I still need to add the manipulation functions, however I am now satisfied that the load/save functions can replace the old ones when I get round to it.

Getting there…

HackerEX 2 is starting to take shape in terms of the loading lists, to store temporary data more easily without modifying the original the program now relies on temporary files, this helps to reduce the memory being used by the program, also an issue that the previous GUI had will be resolved in the same way this one is being resolved because the functions are being designed to be used from a DLL at a later point so all loading/listing will become unified in behaviour while at the same time reducing the reliance on RAM to store temporary data, this in turn frees RAM for smarter Searches.

One thing to note however is that large hack lists will possibly be slower to use on timer based loops, I’ll do what I can to make this as unnoticeable as possible but there are limits, old hardware and/or operating systems will make this apparent (not that I believe anyone will actually try but it can run if there is enough RAM).

Since this is still in-complete I would recommend backing up your database before trying it out (if you plan to compile SVN code), I plan to have this ready by February but things don’t always go to plan so don’t hold you’re breath just yet. Once I finish with the loading/saving side of things I will move straight onto the hacking side of things so that the interface can at least be used for existing hack lists (I’ll work on more formats later but for now it at least supports adding in formats other than HackerEX v1 Format).

I’ll do another screen shot once I got the Hack list loading correctly. Good night 🙂

SVN Update

I figure people are starting to wonder about whether I’m ever going to post the code for the new version of HackerEX so I gone and uploaded it as a new branch however be warned it will crash on trying to list data held in temporary files, and I have not tried to implement anything else yet because they will rely on this new functionality to avoid potential issues in available RAM. Also DO NOT use your original database, use a copy of it instead because this will do some renaming of file extensions. Themes are supported somewhat but you will need to provide your own images for now otherwise comment out the UpdateTheme() from the G constructor before compiling.

I’m tired now so I will continue with this on Sunday most likely.

HackerEX GUI

This is the initial design of the new look, it’s not finished but it gives you an idea of where HackerEX is moving in the GUI direction.

Re-Motivated

After having to re-install a number of things including my OS I lost my motivation for awhile (but not my notes and files). Recently I regained it but had problems with wxWidgets but now that has been resolved and I can get to work on the new version. There are some things I will have to ignore for now in order to get it ready for the new year (main thing being UNIX support) but I have begun work on library attachment so another method of hacking will become user friendly through HackerEX.

The library attachment will be experimental so for now I will restrict that to a Debug version until I happy the overall code is safe for general use. While there is only so much I can do about the memory usage I have targeted that with the new GUI I mentioned, at the same time it will also deal with instances where I forgot to code the function like last time. For now I won’t focus on the code tree thing but the object is there at the ready for me to program it when I get round to it, until then it will be treated as a list object.

When all this is done I will release the first truly Stable release as version 2.0 as 1.0 was to be a finished version of the previous set of Betas (which I might still do later). I probably won’t finish the Hacking side of things until the new year because I will need to implement the database interface fully first, and this I need to start from scratch almost as the code from the previous one will not directly port to this one as this one is sharing objects.