Whenever a program loads, it reads the theme setting from the registry, right?
No. The program reads the various metric via GetSystemMetrics and SystemParametersInfo, as well as using the Extended OLE system colours with the high-bit set.
However, this isn't so much the program as much as it is the default implementation of things like WM_PAINT and WM_CALCSIZE, and WM_NCHITTEST that provide the "default" behaviour that gives the more familiar arrangement of caption buttons.
This sounds more like the application
is not reading the theme colours for certain elements, and using a hard coded colour, and it uses a theme colour, say, as the background to that hard-coded colour and they are the same (making text invisible) or have poor contrast.
Just returning a new colour in a subverted function registry access function wouldn't be enough; both GetSystemMetrics and SystemParametersInfo no doubt cache the return value from these functions system-wide, much in the same way the system imagelist is cached. The only time it knows to check the values again is when a system settings change message is broadcasted. So you could consider instead "subclassing" SystemParametersInfo and GetSystemMetrics and returning the new values that you want the application to use.
Good luck with that, since no doubt the application is compiled and therefore links directly to the functions in user32.dll; so your first task would be to literally have your appinit_dll hack the running processes import table so that it uses the functions from your library. Almost all AV programs will do a double-take when you do that; also, it might not work, since the program might very well have been designed to call those functions dynamically, or it might have been written in a language that calls those functions dynamically (VB6, for example, always performs a GetProcAddress() to get the pointer to a declared function and calls it at run-time). In which case, you would also need to supplant the import table for GetProcAddress; except GetProcAddress requests the pointer to a function i na given module, so you would have to supplant GetModuleHandle() as well; and some programs will acquire it via LoadLibrary, so you'd need to supplant that as well so that it returns the module handle of your appinit_dll... problem is, now if the program tries to get a handle to some other user32 function, it's calling GetProcAddress() with your module handle and the return is NULL unless you happen to export that function, so now you have to add a whole bunch of exports that forward to the "real" functions in user32.
And even in the best case, you are probably left with a tangled ball of yarn that hardly rolls.
Currently, I am running the program in Virtual PC with the classic theme enabled so I can use it.
You are confusing. You say you have it running in VPC with the classic theme enabled so you can use it; then you say you want to be able to switch themes. Themes are merely the colour selections of elements; the gradient title bar, icon sizes, icon fonts, the size of the title bar fonts and caption buttons, the colour of 3d-elements, etc. All of those are a theme.
However, by implication it seems that you don't want the program to run with a theme. You want it to run with a Visual Style, like the Luna or Aero styles, and still have all text visible.(or something) If the application was designed to run with a Visual Style, it will have a Manifest file either as an Embedded resource (#24) or it will "come with" a manifest file in the form of program.exe.manifest which appears in the same folder; by deleting this resource or file, windows will by default link it to Common Controls version 5.0, which in effect prevents the Luna or Aero Themes from entirely skinning the window, meaning that elements will be drawn using the default theme values rather then using the uxtheme functions, the same as if you ran it with windows classic. In Windows Vista and 7 you can explicitly disable Visual Styles by checking off the incorrectly captioned "Disable Visual Themes" button on the compatibility tab of the properties dialog for the program.
EDIT: looking back, Geek-9pms suggestion of using fast user switching is probably the most ideal; you can keep that program running in another account and switch between that account and yours just fine. What you want to do is have multiple themes and visual styles enabled at once; you want most of your windows to show your "default" visual style, which I can only guess is probably a Luna theme since you haven't explicitly said so and you say you have to run the program in windows classic so I am left only with the inference that you are probably running in the default theme- and you want another program to run with a completely different style. Aside from having some windows run with the current Luna theme, and some not (depending on wether they link to Common controls 5 or 6) you can't just skin windows willy-nilly with all sorts of different elements; the visual styles are all drawn by uxtheme, either a program uses uxtheme (and imports common controls 6) or doesn't. If it uses uxtheme.dll, then uxtheme.dll will use the globally allocated bitmaps that it loaded either at system boot or when the theme was changed that correspond to the currently selected theme. Otherwise, it isn't called at all and the default drawing occurs using the selected theme colours.
