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 (
http://msdn2.microsoft.com/en-us/library/ms235591(VS.80).aspx). 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,
--Dave
--
David L. Page, PhD
dav...@ie...
865.607.8192
|
