Most of the following discussion follows other postings within the chromium-users mailing list as I was hashing through this problem. I've included it below for clarity and completeness as I am now trying to modify the CR code to better handle this situation rather than the kludge I posted in the users mailing list.
I am looking into the problem that I have had on my Windows system with CR. The difficulty centers around manifest files (i.e. app.exe.manifest) associated with Microsoft Visual Studio 2005 (MSVS 2005) and up. It seems that the MSVS 2005 compiler creates ".manifest" files that are somehow important to runtime linking.
In CR with Windows, the app faker first copies the exe for an app of interest to a temp dir and then copies crfaker.dll into that same dir with the name opengl32.dll. My understanding here is that this approach allows crfaker.dll to mascarade as the OpenGL library since the linker will first look locally within the temp dir for important dll's to link since the app.exe resides in that temp dir.
The problem is that the app.exe.manifest file is not copied by CR (app faker) into temp dir, as well. Without the manifest file some apps generate runtime linking errors. The one I have run into is not finding MSVCR80D.dll.
There seems to be three ways to resolve this issue (can anyone think of any others?). Does anyone have a recommendation or additional comments as to what approach would be best?
(1) The kludge (in my opinion not the best approach) is to embed the manifest file into the exe file as noted in the MSDN note ( I have found this works, but it goes against the spirit of CR since one must modify the OpenGL app of interest.
(2) Modify app faker to copy the app.exe.manifest (if it exists) to the temp dir at the same time that it copies the app.exe file. I have made this mofication and it seems to work as well. However, another issue that might arise is .local (dot local) files. I don't know much about these files but an app can have an app.exe.local, which seems to force Windows to check a local directory first for a dll. This behavior would seem to be affected if app faker is not copying the app.exe.local file and any local dll's along with app.exe.
(3) Another approach is to copy crfaker.dll with the new name of opengl32.dll into the current directory of the app.exe file and then to spawn the app from it's current directory. For this approach to work, it would seem necessary to have an app.exe.local file to insure that Windows first looks locally for opengl32.dll. I haven't tried this approach yet as I'm not totally familiar with dot local files or Windows dynamic linking. With that said, this approach seems the most promising to me.
My question to the CR developers is what approach seems to be the best from your experience? What guidance would developers have?
I am currently looking to modify app_faker.c and to follow (3) above as it seems to be the best approach to handle all scenarios. A post to the chromium-users list noted a simliar solution, and the key to (3) seems to be the .local (dot local) file.
I look forward to any help and guidance. Best regards,

David L. Page, PhD