Although I would never call the software well written you seem to be having a worse time than most.
What follows is largely opinion from pulling things apart and little snippets I have managed to gather over the years (being
GBAtemp staff and being tied to a few things I have been tied to over the years opens a few doors) although I do not think you will find many that disagree.
The early ones- they were little more than crude wrappers for the drivers to get it all done. Now I hate to speak ill of some of the coders as their efforts have provided me with a lot of enjoyment over the last many years but well ask Normmatt, smiths and co about the early acekard source releases vis a vis code quality (function declarations anywhere and everywhere, same with includes and other such things) and/or look up rants by programmers and such against self taught and outsourced programming as they often ring true here (do a DLL function export (they have nice names) on some of the EZ patching DLL files in general or better across versions or have a look at some of the hacks done to the programs over the years) as well as notice that the flash cart teams also suffered loss of staff (ability to manage/understand legacy code applies here as well). Also embedded ARM programming, embedded device programming (flash carts are fairly low level devices with interesting chips- most have a FPGA or CPLD and various types of memory chip that are all tied back to GBA code), low level driver programming and (good) GUI programming are quite different skills even if they do fall into the general umbrella of programming.
The later ones- often they were built from the earlier software (EZ4client and EZManager (the EZ3 software) and EZClient (the EZ1/2 software) share so much in common it is not funny) and often had to manage some very crude hacks (see several of the earlier release threads- "works on M3 if you disable DMA, set y to ?, .......") and with GBA kind of an afterthought/no attention paid to any regressions that might have come about (and owing to the hackjob nature of things they did happen a bit).
Replacements- there kind of was for some. Littlewriter is probably the most prominent but there were a handful of others (to say nothing of the efforts that went on for the GBAMP/M3 stuff by Chishm and co) and today there is also FAS1. The EZTeam once released the DS patching API for their patching DLL for the EZ4 to a person in one of the homebrew contests but it was never made truly public.
Equally the basic GBA patching has been reverse engineered at least as far as making generic patches* (Trolleydave did a lot and integrated it into one of his programs-
http://gbatemp.net/t...g-gba-patching/ has some base discussion) and implemented in a few other programs as well- for the ones made back when they were more or less done and left when the GBA still had a few things happening (EEPROM v126) and did not get updated to match. The trouble is you either make a wrapper for the DLL files or reverse engineer the GBA USB drivers and/or protocols which is a bit of a pain (made even more of a pain by the programmers then doing something resembling obfuscation in addition to the stuff above to it all to lessen the chances of clone makers).
I have considered it on occasion and even fiddled with a few but I am not a great PC programmer as far as reverse engineering hardware interfaces go and frankly those that really care can usually set up a VM or something to run the software with far less effort than reverse engineering something (not to mention that once you learn the quirks you can usually do OK).
*the GBA is pretty much capable of having this done (you find the nice string saying what it is and patch in a known distance from it) but finding someone that can run through what each opcode change means might be trickier.
What I sometimes suspect is people are kind of waiting (even if they do not know it) for something like we see today in the n64 (and maybe some of the stuff in the 16 bit cards although there the mappers and extra chips situation changes things a bit) where the legacy stuff from "back in the day" is more or less forgotten in favour of modern chips doing all that modern chips can do (and frankly I would love to see a savelist style GBA cart a la the original EZ5 or maybe current supercards for DS stuff where they physically emulate the save types rather than patch them to use SRAM as nearly all GBA carts do). However with the GB/GBC a prime target we have not seen that much (most that is made being for little sound DJ and thus lacking proper save and rom handling which I admit is quite tricky to do properly) and aside from a few GBA cards made way back when we have not seen much there either. Floating around some of the Chinese cart maker sides of things there have been rumblings of just this (or at least a modern revisit) happening but nothing much has pushed forward (the EZTeam did a very small run of new EZ4s a year or so back and did ponder some source code but nothing truly new).
Edit- confused littlewriter and little sound DJ in the last paragraph.
