Well, BFI_INT stuff needs to be added. That's pretty crappy to do though.
Most of the outstanding stuff I need to do requires a bit of rearch. I want to add support for running miner plugins out of process of the main program. Once that is in, the processes can be started and stopped dynamically in the Console session, so they have GPU access.
I need more events flowing from the miner processes up to the main program. They already expose Resources, which represent something like a CPU, or a GPU, but those Resources can be a bit more descriptive. Hash count tracking per-resource would be nice. Then, when the main program is getting events from all of the stuff it's running, the console UI can be updated a bit (maybe using curses stuff) to show exactly what's happening. What GPUs are running. What pools are running. What GPUs are working on work from what pool, etc.
I'd like a miner plugin factory to be able to, with a resource, also advertise possible run-modes of the miner. Such as work group size, vector modes, etc. This way, instead of the user having to specify what options he wants the program to use, it just tries them all during the test phase, and picks the fastest.
Pool configuration stored in some other structure than System.Configuration would be nice. Or maybe System.Configuration is fine, but it needs to be configurable at runtime. You need to be able to alter the pools at runtime... for a future WPF UI.
Finally have gotten around to taking a look at this, now that my other stuff is more or less complete -
BFI_INT stuff - I'm guessing you say this is crappy because it requires doing brand detection, yes? Being that it's supported on AMD/ATI cards you'd have to be sure to pass it only on those cards.
Miners running outside the main program - how do you feel about implementing a WCF service between them for communication? It's a simple enough thing to do, although some might consider it a somewhat heavy-handed method of communication.