I started to look into adding support for Bruni's GB colorization mods for VBA-M. I did some initial checking of the core work involved:

gb.cpp - changes
gbgfx.cpp - changes
gbglobals.h - changes
VBA.cpp - changes

basically those are the files, from my initial checks, of what Bruni changed, since he didn't make a diff. Which would have been helpful.

Netherless, I am interested in this. However, I am concerned about cross platform support, since I don't want to break any compatibility with the Linux/Mac OSX ports. So, I am giving this a opportunity for discussion before I try to whip up a build with this new functionality.

well, it should be possible to integrate this into all the ports, an cmd switch can be created for the sdl port, and im sure the GTK port can have something done with it.

in the end it all comes down to, the different port devs wanting to keep as inline as possible, with the features.

I'm sure we can work a cross platform solution out.

VBA-M | NGOHQ | Post Impact Productions | TNHW | XBCD 0.2.7

The changes in the gb* files should not cause any problems, as long as you don't use Windows specific libraries.
VBA.cpp is a Windows specific file thus similar changes have to be made to SDL.cpp and the GTK files.
I suppose the sprite hash <-> palette definition file is loaded from there. It would be nice to factor out the code and make it portable so that it can be reused by all of the ports.

A lot of features are reimplemented in all the ports like the config file parsing, the filter management code, audio output, ...
It would be nice it there was a place in the directory structure where we could put shared code.
Speaking about the directory structure, there is a lot of room for improvements here.
Filters should be in a separate folder. gb_apu is shared between the GB and GBA cores so why is it in the GB folder ?
Some of the GBA specific files are in the agb (why agb, it's called GBA everywhere else) folder but not all ...
I'd like to make these changes but I have no win32 build environment so that would break the build for the win32 port.

Also having a clear separation between the emulation cores and the frontends would be great.
Basically an abstract class that the emulation code uses and the frontends implement would be perfect (Moving all the functions and variables definitions the frontends have to implement in System.h would be a good start). ScummVM has a very nice way of doing it, check their common/system.h file.