Tim discovered this by accident when trying to insert a manifest into one of my gdi+ exercises:
Have anyone idea, why GuiImage.exe is not a valid Win32 application with this manifest<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity version="1.0.0.0" processorArchitecture="*" name="Co.Prd.Prg" type="win32" />
<dependency><dependentAssembly><assemblyIdentity type="win32" name="Microsoft.Windows.Common-Controls"
version="6.0.0.0" publicKeyToken="6595b64144ccf1df" language="*" processorArchitecture="*" />
</dependentAssembly></dependency></assembly>
EDIT: manifest wasn't a problem.
The exe was trashed. After a lot of testing, I could identify the culprit in the MasmBasic source:
sgSeg segment public DWORD 'BSS' ; special segment for SetGlobals
align 16
gvStart dd ?
ORG gvStart+4096-1
db ?
sgSeg endsWhen opened with
PeView, this segment appeared at the end of executables - and this worked just fine,
except when trying to change the regular .rsrc section with
UpdateResource.
In the meantime, I've removed this segment (it was not needed anyway), so
MB 27NovV2 is OK for updating resources.
In the process of testing, I also discovered that a file named
UpdateResource.exe requires elevation (same for Setup.exe and a few other "reserved" exe names). Launching it with CreateProcess just fails silently, but GetLastError reveals the problem. I've added a check to RichMasm; testbed attached.
On a side note (
Windows SDK Support Team Blog):
If you are wondering how Windows launches a manifested application, it is internally calling ShellExecute(), ShellExecuteEx().
manifest insanity ::)