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.
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).
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).
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.
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.
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.
I’ve had some ideas for improving not only the GUI but also how much memory HackerEX uses, there might be a slight slowdown with the Hooking process but I will include an option to disable the memory enhancement ( It’s only needed if you use overwhelmingly large Hack Lists / Trees ).
I’ve also thought of a way to begin supporting UNIX without sacrificing speed, I will do this by adding ONE variable when compiling the Library that the new GUI will rely on – this will then be set at start up to enable quick analysis of which actions are supported by the system.
I’ve also had ideas on how to include certain bits of information that would typically be used by save editors but can be used for processes as well, this idea however did require a bump up on the codelist version and in order to support auto-upgrade of old lists I had to spend some time thinking through what the new loading function should look like.
All in all once I get my lazy butt in gear this will be a much more useful tool for creating trainers, patches and save editors because the hacker will have a clearer overview of what their hacks are doing ( I’m also turning the visual codelist into a codetree that display simple stuff like “write to 0x0A 3 times while decreasing address by 2” )
There will also be the option of turning off lines of code where instead the program will assume 0 for these allowing codelist files to be even smaller where possible.
However I make no promises about how fast I will be for this so for now stick to the assumption that I won’t finish until the new year at least – I will make another post then to give you another time frame.