Joel Holdsworth wrote:
It works for precreated manifest as a separate file (not compiled in),
isn't it? If so you could do a trick that
I spotted here
http://www.winehq.org/pipermail/wine-patches/2009-September/078869.html
for a first time -
here another process is created after main test binary loaded, it's
created for exactly the same binary but with
a manifest created first (command line parameter passed to jump to V6
tests).
Hope this helps.
Ok... I've been looking at the child process code, and I think it's not
necessary to do that (though you might be doing something more complex -
I haven't looked at the patch in detail). The activation context method
that's already present sets up a manifest-enabled state of affairs. The
big gotcha is that you have to reload any function pointers that you
might care to use...
http://wine.pastebin.com/m11141e7a
As you can see here my version of the test unloads comctl32, switches on
the activation context, and then reloads comctl32, and then loads
pointers for ALL THE FUNCTIONS THAT WILL BE NEEDED. If you then call
these, you have a state of affairs that is pretty much identical to what
you get with a manifest from the start.
That's interesting. If it works for window classes too we should use it
for ListView and Header tests too
cause these are failing now on XP SP3 for some reason (but work fine on
up to Win7).
