[python-win32] WinSxS, manifests and binary distribution ?
Robert
kxroberto at googlemail.com
Tue Nov 8 10:41:57 CET 2011
Mark Hammond wrote:
> I'm afraid some of the assembly stuff is truly black-magic to me,
> but I'll answer what I can.
>
>
> On 8/11/2011 1:28 AM, Robert wrote:
> ...
>>
>> Now when I move away the 5 MFC files (4 dlls + manifest) to _mv,
>> then
>> Pythonwin.exe still runs properly!
>> And it does so until I move the folder
>> C:\WINDOWS\WinSxS\x86_Microsoft.VC90.MFC_1fc8b3b9a1e18e3b_9.0.30729.6161_x-ww_028bc148
>>
>> away to C:\WINDOWS\WinSxS\_mv
>>
>> (There are 2 more 9.0 MFC folders in WinSxS, but they have no
>> effect
>> regarding Pythonwin.exe - on or off)
>>
>> Well, but Pythonwin.exe has a builtin manifest
>> (win32api.LoadResource(None, 24, 1)) which draws
>> version="9.0.21022.8" -
>> and not 9.0.30729.* !? how come? :
>
> How come what? The C compiler generates this dependency based on
> what I have installed, which is VS2008 with no service packs.
>
>>
>>
>> <assembly xmlns="urn:schemas-microsoft-com:asm.v1"
>> manifestVersion="1.0">
>> <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
>> <security>
>> <requestedPrivileges>
>> <requestedExecutionLevel level="asInvoker"
>> uiAccess="false"></requestedExecutionLevel>
>> </requestedPrivileges>
>> </security>
>> </trustInfo>
>> <dependency>
>> <dependentAssembly>
>> <assemblyIdentity type="win32" name="Microsoft.VC90.CRT"
>> version="9.0.21022.8" processorArchitecture="x86"
>> publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
>> </dependentAssembly>
>> </dependency>
>> <dependency>
>> <dependentAssembly>
>> <assemblyIdentity type="win32" name="Microsoft.VC90.MFC"
>> version="9.0.21022.8" processorArchitecture="x86"
>> publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
>> </dependentAssembly>
>> </dependency>
>> </assembly>
>>
>>
>> Moreover, the files in ..
>>
>> Verzeichnis von
>> C:\WINDOWS\WinSxS\x86_Microsoft.VC90.MFC_1fc8b3b9a1e18e3b_9.0.30729.6161_x-ww_028bc
>>
>>
>> 148
>>
>> 10.10.2011 11:04 <DIR> .
>> 10.10.2011 11:04 <DIR> ..
>> 18.04.2011 21:51 3.766.600 mfc90.dll
>> 18.04.2011 21:51 3.781.960 mfc90u.dll
>> 18.04.2011 21:51 59.904 mfcm90.dll
>> 18.04.2011 21:51 59.904 mfcm90u.dll
>> 4 Datei(en) 7.668.368 Bytes
>> 2 Verzeichnis(se), 43.545.792.512 Bytes frei
>>
>> .. are younger than Pythonwin.exe itself !??
>
> I guess the manifest for that version indicates it supports the
> older version?
>
yes it seems this file catches with "bindingRedirect" the version
request range 9.0.20718.0-9.0.21022.8 to the newest installed
MFC90 DLLs:
C:\WINDOWS\WinSxS\Policies\x86_policy.9.0.Microsoft.VC90.MFC_1fc8b3b9a1e18e3b_x-ww_4ee8bb30
<assembly xmlns="urn:schemas-microsoft-com:asm.v1"
manifestVersion="1.0">
<assemblyIdentity type="win32-policy"
name="policy.9.0.Microsoft.VC90.MFC" version="9.0.30729.6161"
processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"/>
<dependency>
<dependentAssembly>
<assemblyIdentity type="win32" name="Microsoft.VC90.MFC"
processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"/>
<bindingRedirect oldVersion="9.0.20718.0-9.0.21022.8"
newVersion="9.0.30729.6161"/>
<bindingRedirect oldVersion="9.0.30201.0-9.0.30729.6161"
newVersion="9.0.30729.6161"/>
</dependentAssembly>
</dependency>
</assembly>
>>
>> Well, now with MFC90 folders of WinSxS moved away, and
>> Pythonwin.exe
>> finally not booting as wanted, I move then back the 5 MFC files
>> from
>> C:\Python27\Lib\site-packages\pythonwin\_mv to
>> C:\Python27\Lib\site-packages\pythonwin . But Pythowin.exe now
>> doesn't
>> start with that files right next to it (where precisely the same
>> version
>> is in Pythonwin.exe manifest and in that
>> Microsoft.VC90.MFC.manifest
>> file), nor does import win32ui in python(w).exe work.
>> (ImportError: DLL load failed: The referenced assembly is not
>> installed
>> on the computer)
>> Pythonwin.exe or win32ui won't load until
>> C:\WINDOWS\WinSxS\x86_Microsoft.VC90.MFC_1fc8b3b9a1e18e3b_9.0.30729.6161_x-ww_028bc
>>
>>
>> 148 is in Place.
>
> Is it possible that Windows is keeping an index of what is
> installed, so it *thinks* it will find the assembly in the SxS
> directory but fails to locate it and doesn't try the directory
> next to the modules?
>
>> I absolutely don't understand this. How can Pythonwin.exe draw a
>> MFC90
>> DLL set with future date and future version, and reject the DLL set
>> coming with pywin32 installer right next to with right version
>> ... ?
>> What has to be done to distribute the right binary files for a
>> win32ui app?
>>
>> Where do the "active" rather new files in
>> C:\WINDOWS\WinSxS\x86_Microsoft.VC90.MFC_1fc8b3b9a1e18e3b_9.0.30729.6161_x-ww_028bc
>>
>>
>> 148 come from at all?
>
> Probably from something else you installed - pywin32 doesn't
> install it.
>
> Please continue to share whatever you learn :)
>
> Mark
>>
>>
>> Robert
>>
>>
>> PS: By experience the method with placing MSVCRT 90 files +
>> manifest
>> next to a Python2.6 wxPython app (no MFC/win32ui) worked on fresh
>> computers (which I don't have easily at hand).
>>
finally I inspected with "depends.exe" (which confirmed well the
actual happening as far as I see) and tested the simple "shared
assembly" distribution method with VCR DLL(s) and MFC DLL(s) too
next to the py2exe'd app files on a fresh XP Virtual Machine.
Theory can't fully replace try+error ;-) From the list
msvcr90.dll
Microsoft.VC90.CRT.manifest
(not required: msvcp90.dll (c++ libs), msvcm90.dll (managed code))
mfc90.dll
Microsoft.VC90.MFC.manifest
<myapp>.exe.manifest
<myapp>.exe.manifest with the same manifest as embedded in
Pythonwin.exe (including the MFC request) is needed as max
surprise. When missing, "import dde" fails with pywin 216 with
that error mention in the thread nearby.
Unlike in build 216, pywin 212's dde.pyd here seems to have the
same embedded manifest as win32ui.pyd. The problem is not with
win32uiole.pyd.
So I guess from 214 -> 215 a sort of bug entered into the pywin
build files regarding the dde.pyd lacking a embedded manifest.
(I added that on SF bug ID 3314345)
Robert
More information about the python-win32
mailing list