This manifest stuff is driving me mad :(
Here is a manifest that declares both the common controls and the GdiPlus version:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<description>Windows Application</description>
<dependency>
<dependentAssembly>
<assemblyIdentity
type="win32"
name="Microsoft.Windows.Common-Controls"
version="6.0.0.0"
processorArchitecture="*"
publicKeyToken="6595b64144ccf1df"
/>
</dependentAssembly>
</dependency>
<dependency>
<dependentAssembly>
<assemblyIdentity type="win32" name="Microsoft.Windows.GdiPlus"
version="1.0.0.0" processorArchitecture="*"
publicKeyToken="6595b64144ccf1df" language="*" />
</dependentAssembly>
</dependency>
</assembly>Note that on Win7, you can specify GdiPlus version="1.1.0.0" (I haven't tested if it works, but icc returns 1)
When using CreateActCtx instead,
- if a manifest is included, it complains that the context activation has been done already
- if no manifest is included, it complains that I passed an invalid parameter: to be investigated :(
P.S.: This is on Win7-64 and/or XP. See what Microsoft says (https://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/a5e1790e-571a-4a6f-9466-5e07aff48dd6/is-there-workaround-to-get-gdiplusdll-v62920016384-for-x64-windows-7-machine?forum=windowssdk) on GdiPlus:
QuoteWe have identified that the problems must be due to some bugs in intermediate implementations of GDI+ 1.1 that use the newer Windows Imaging Component (WIC) in Windows 7 and 2008R2 x64. GDI+ 1.0 did not use WIC and did not have these bugs, but may present slightly different appearance because of small implementation details being different.
New attempt at making manifests work (plain Masm32):
include \masm32\include\masm32rt.inc
xDLLVERSIONINFO STRUCT
cbSize DWORD ?
dwMajorVersion DWORD ?
dwMinorVersion DWORD ?
dwBuildNumber DWORD ?
dwPlatformID DWORD ?
xDLLVERSIONINFO ENDS
.data
vinfo DLLVERSIONINFO <DLLVERSIONINFO, 0, 0, 0, 0>
.code
start:
mov esi, rv(LoadLibrary, "ComCtl32") ; CreateActCtx
; print str$(esi), 9, "for LoadLibrary", 13, 10
mov ebx, rv(GetProcAddress, esi, "DllGetVersion")
; print str$(ebx), 9, "for DllGetVersion", 13, 10
push offset vinfo
call ebx
; print str$(eax), 9, "retval", 13, 10
print str$(vinfo.dwMajorVersion), "."
print str$(vinfo.dwMinorVersion), 9, "major.minor version", 13, 10
print str$(vinfo.dwBuildNumber), "."
print str$(vinfo.dwPlatformID), 9, "build.platform", 13, 10
exit
dd FlatSB_GetScrollInfo ; OK, 4.71 and higher
dd DrawShadowText ; can't find entry; 6.00 and higher
dd GetMUILanguage ; OK, 5.8
dd InitMUILanguage
; dd HandleScrollCmd ; symbol undefined
; dd ImageList_GetFlags ; symbol undefined
dd RegisterClassNameW ; OK; 5.82 and 6.0 from Windows XP SP2, and higher; except 5.82 and 6.0 from Windows XP SP3
end start
If GetComCtl32Version.exe.manifest is present, version is 6.16, otherwise 5.82 :(
The embedded manifest is identical, and PeView shows it is correctly included, but it simply doesn't work :(
Any ideas why the resource manifest fails to show effect??
P.S.:
- attachment #2 has two identical executables, plus SmallEditor.exe.manifest
- to the right of the toolbar, you can see which ComCtl32 version is effectively active; 5.82 for the editor2 (no matching *.exe.manifest), 6.16 for editor.exe
- try Alt Tab between the two versions; on Win7, I can see differences only if I activate one of the Aero themes
My question here is really how exactly one can activate ComCtl32 6.16 without the external *.exe.manifest file
P.P.S.: To complete the confusion, I've now tested it in my XP VM. The exe won't run, complaining that RegisterClassW can't be found. Note that it runs fine in W7-64, despite the fact that the old ComCtl32 5.82 is recognised by DllGetVersion. Which seems to indicate that LoadLibrary yields a different version than the statically linked one ::)
Intense debugging, however, indicates that the statically linked version is 5.82 (without "external" manifest); but it does have RegisterClassW, in contrast to the 5.82 under XP ::)