Stephen Kellett wrote:
Interestingly none of my customers (all of whom are software
engineers of many years experience) that also use VS 2005 know how to
fix this problem (it comes up every now and then when I get a bug
submitted to me in the form of an example application that will not
run due to "manifest" problems).
You get cryptic clues that you need a manifest for something, but no
idea how to create one, where to put it, what compiler/linker
switches to invoke (if any!). Likewise, no information for what to do
if you get an app given to you that has no manifest (although I think
the solution is "go back to the author and demand one with a
manifest" which puts the problem back at the source (which in this
case is back at the Lua build chain for MS Windows). The whole thing
is such a bodge.
I don't have a complete understanding of the whole system, but I may
have some answers to these questions.
Starting with Visual Studio 2005 the runtime libraries are not directly
linked with the executables. Instead, the executable contain the id of a
particular version of the runtime that it needs. That allows the dynamic
linker to maintain several version of the runtime libraries, and to give
each application the one it needs (this is valid for the C runtime, but
also other system libs like the common controls, hence the need for a
manifest to support windows xp themes in applications).
That information, among others, is in the manifest. The manifest can be
embedded in an executable as a ressource file with a special tool called
mt.exe. I think mt.exe can also generate a normal resource file that you
can compile and embed in the PE file yourself.
The manifest itself should be generated by the compiler when linking a
dll/exe. My copy of Visual C++ Express 2005 generate a manifest for all
created dll and exe files.
