Is there a way to put the manifest lines directly into the rc file, say just above the version lines, or do they always have to be in a separate included file?
Not that I know of Jim, still, its simple enough to include an external manifest so I don't see the problem. Have a close look at the options for the linker you are using as there may be a way to do it.
Just trying to fight this excess file proliferation. Odd that it can include it but not just take it straight.
You can add this as a link response file
/manifest:embed
/manifestdependency:"type='Win32' name='Microsoft.Windows.Common-Controls' version='6.0.0.0' processorArchitecture='*' publicKeyToken='6595b64144ccf1df' language='*'"
/manifestuac:"level='asInvoker' uiAccess='false'"
Thanks Sinsi (I think).
When you say "link response file" I'm not sure what you meant. But since I asked to embed the commands in the .rc file, I assume that's what you gave me.
So I tried rc.exe from 1998 and got the following error-
rsrc.rc (45): error RC2135 : file not found: name
Writing /MANIFESTDEPENDENCY:"TYPE='WIN32':/MANIFEST:EMBED, lang:0x409, size 0.
So I thought, I probably need to use a newer resource compiler. So I tried Pelles porc.exe from 2011 and got
PORC: rsrc.rc(44): warning: Unrecognized or misplaced token: /
PORC: rsrc.rc(45): warning: Unrecognized or misplaced token: /
PORC: rsrc.rc(45): warning: Unrecognized or misplaced token: /
PORC: rsrc.rc(45): warning: Unrecognized or misplaced token: "STRING"
PORC: rsrc.rc(45): warning: Unrecognized or misplaced token: "STRING"
PORC: rsrc.rc(46): warning: Unrecognized or misplaced token: /
PORC: rsrc.rc(46): warning: Unrecognized or misplaced token: "STRING"
PORC: rsrc.rc(46): warning: Unrecognized or misplaced token: "STRING"
W
So clearly I have absolutely no idea what I'm doing, but thanks for you patience
Just so there is less confusion, here is the text of the .rc file. As you can see, I used Hutch's bigbutton demo for a test :shhh:
// ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤
#include "\masm32\INCLUDE\Resource.h"
// ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤
500 ICON MOVEABLE PURE LOADONCALL DISCARDABLE "bigbutn2.ico"
700 BITMAP MOVEABLE PURE LOADONCALL DISCARDABLE "toolbar.bmp"
800 BITMAP MOVEABLE PURE LOADONCALL DISCARDABLE "bluegrad.bmp"
// ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤
600 MENUEX MOVEABLE IMPURE LOADONCALL DISCARDABLE
BEGIN
POPUP "&File", , , 0
BEGIN
MENUITEM "&Open", 1010
MENUITEM "", , 0x0800 /*MFT_SEPARATOR*/
MENUITEM "&Save", 1020
MENUITEM "", , 0x0800 /*MFT_SEPARATOR*/
MENUITEM "&Exit", 1090
END
POPUP "&Help", , , 0
BEGIN
MENUITEM "&About", 10000
END
END
// ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤
5000 DIALOGEX MOVEABLE IMPURE LOADONCALL DISCARDABLE 10, 10, 257, 133, 0
STYLE DS_MODALFRAME | 0x0004 | DS_CENTER | WS_CAPTION | WS_VISIBLE | WS_POPUP
CAPTION " About"
FONT 8, "MS Sans Serif", 700, 0 /*FALSE*/
BEGIN
LTEXT "img", 999, 0,0,12,10, SS_LEFT, , 0
ICON 500, 998 15,35,18,20, , 0
LTEXT "Text", 997, 51,37,190,60, SS_LEFT, , 0
PUSHBUTTON "OK", 1, 189,104,50,14, 0, , 0
END
/manifest:embed
/manifestdependency:"type='Win32' name='Microsoft.Windows.Common-Controls' version='6.0.0.0' processorArchitecture='*' publicKeyToken='6595b64144ccf1df' language='*'"
/manifestuac:"level='requireAdministrator' uiAccess='false'"
// ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤
VS_VERSION_INFO VERSIONINFO
FILEVERSION 1, 0, 0, 0
PRODUCTVERSION 1, 0, 0, 0
FILEOS VOS__WINDOWS32
FILETYPE VFT_APP
// FILETYPE VFT_DLL
BEGIN
BLOCK "StringFileInfo"
BEGIN
BLOCK "040904B0"
BEGIN
VALUE "CompanyName", "Your Company Name\000"
VALUE "FileDescription", "Description Of Application\000"
VALUE "FileVersion", "1.0\000"
VALUE "InternalName", "Item Name\000"
VALUE "OriginalFilename", "Original File\000"
VALUE "LegalCopyright", "\251 2010-2020 Application Copyright Holder\000"
VALUE "ProductName", "Item Name\000"
VALUE "ProductVersion", "1.0\000"
END
END
BLOCK "VarFileInfo"
BEGIN
VALUE "Translation", 0x409, 0x4B0
END
END
// ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤
Link command
link myfile.obj @myfile.rsp
myfile.rsp
/manifest:embed
/manifestdependency:"type='Win32' name='Microsoft.Windows.Common-Controls' version='6.0.0.0' processorArchitecture='*' publicKeyToken='6595b64144ccf1df' language='*'"
/manifestuac:"level='asInvoker' uiAccess='false'"
A response file is simply the linker's command line switches, one per line, in a text file.
You could put the three manifest lines on the link command instead.
So, I didn't make my self clear. I wanted to do this to avoid having an .xml file hanging around, but I need to make an extra .rsp file instead. Or add to the link command.
k, thanks.
Jim,
I perfectly understand your wish to avoid little files all over the place, but what's the difference to expecting, for example, \Masm32\include\masm32.inc to be in that precise location? Once you've built the exe, the client does not need the xml file. So put that stuff in a folder of your choice, even \Masm32\include\ will do, and adjust your rc files accordingly. Attached some samples.
Thanks jj
Jim,
This is the basic manifest file I use in 32 bit. The section with bold text is the individual app specific data.
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<description>YourAppNameHere</description>
<dependency>
<dependentAssembly>
<assemblyIdentity
type="win32"
name="Microsoft.Windows.Common-Controls"
version="6.0.0.0"
processorArchitecture="X86"
publicKeyToken="6595b64144ccf1df"
language="*"
/>
</dependentAssembly>
</dependency>
</assembly>
Yup. That looks exactly like the one that came with your bitbutton demo :)
A manifest is a XML file and can be placed directly in a .RC file like this:
1 24
MOVEABLE PURE LOADONCALL DISCARDABLE
BEGIN
0x3F3C, 0x6D78, 0x206C, 0x6576, 0x7372, 0x6F69, 0x3D6E, 0x3122,
0x302E, 0x2022, 0x6E65, 0x6F63, 0x6964, 0x676E, 0x223D, 0x5455,
.....
0x0D3E, 0x3C0A, 0x612F, 0x7373, 0x6D65, 0x6C62, 0x3E79, 0x0A0D,
END
Some resource tools do it. It is easy to make a little program to convert the Manifest text to the format above accepted by the Microsoft compiler.
I have produced the converter and is attached.
(https://www.dropbox.com/s/fjq7ngmvniohok6/xmltoresource4.png?dl=1)
the program doesn't open a window, it just shows up on the task bar and the only option is to close it.
It was fixed, thank you.
I produced a Unicode enabled version of the program.
Manifests are supposed to support unicode and, of course, RC.EXE can deal with that (very old versions may not). However, most resource tools are dated and do not support Unicode. I found that Resource Hacker is still being maintained and does support. I don't particularly like Resource Hacker, I am just mentioning it because I have used it to confirm the program works as expected.
Finally, I removed the line MOVEABLE PURE LOADONCALL DISCARDABLE, it is ignored unless you are doing resources for 16-bit applications.
(https://www.dropbox.com/s/cdz405uzl82j92k/xmltoresource3.png?dl=1)
Hi AW:
The program Manifest to Resource works in Windows 7, which is my current dev computer.
Will it work in Windows XP? I am asking because I use XP for 32-bit development??
Thks
Jonas
In the mean time, I've gone back to a previous method of adding a manifest, putting it right in the asm file and using polink.
This entered at the end of the program just before the end statement-
OPTION DOTNAME
.drectve SEGMENT INFO DISCARD
db "'"
db '-manifestdependency:type="Win32"'
db ' name="Microsoft.Windows.Common-Controls"'
db ' version="6.0.0.0"'
db ' processorArchitecture="X86"'
db ' publicKeyToken="6595b64144ccf1df"'
db ' language="*"'
db "'"
db '-manifest:embed'
.drectve ENDS
produces this in the exe file-
<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
- <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" />
</requestedPrivileges>
</security>
</trustInfo>
- <dependency>
- <dependentAssembly>
<assemblyIdentity type="Win32" name="Microsoft.Windows.Common-Controls" version="6.0.0.0" processorArchitecture="X86" publicKeyToken="6595b64144ccf1df" language="*" />
</dependentAssembly>
</dependency>
</assembly>
which looks like this using dump-
00000820h: 0€È¥ï]HX0€<?xml version='1.0' enco
00000870h: ding='UTF-8' standalone='yes'?><assembly xmlns='urn:schemas-microsoft-com:asm.
000008C0h: v1' manifestVersion='1.0'> <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3
00000910h: "> <security> <requestedPrivileges> <requestedExecutionLeve
00000960h: l level='asInvoker' uiAccess='false' /> </requestedPrivileges> </sec
000009B0h: urity> </trustInfo> <dependency> <dependentAssembly> <assembly
00000A00h: Identity type="Win32" name="Microsoft.Windows.Common-Controls" version="6.0.0.0"
00000A50h: processorArchitecture="X86" publicKeyToken="6595b64144ccf1df" language="*" />
00000AA0h: </dependentAssembly> </dependency></assembly>
Quote from: jimg on December 11, 2019, 01:07:34 AM
.drectve SEGMENT INFO DISCARD
Works fine for UAsm, AsmC and ML 8.0 and higher :thumbsup:
Quote from: JonasS on December 11, 2019, 12:51:21 AM
The program Manifest to Resource works in Windows 7, which is my current dev computer.
Will it work in Windows XP? I am asking because I use XP for 32-bit development??
Hi Jonas,
It will work properly in all Unicode enabled versions of Windows, i.e Windows NT 4 and above.
Since I am using the Tahoma font, viewing all characters will depend on its availability in the system, but even if characters not properly viewed the conversion will be done properly.
The previous version I posted was not Unicode aware, would work properly with Windows 95 and above.
It was produced in old Delphi 5, does not use anything from the Windows C runtime (now officially part of the OS). Has modern look in Windows 10 and had modern look 25 years ago in the Windows 95 times. Good compiler, not the sort of funky things we see these days.
Now if there was a way to embed the version code in the asm file I could dump rc files all together :icon_idea:
Hi jimg,
If you have very small resource scripts, your method to embed the resource code into the assembly module is practical and easy. For bigger resource files, I am afraid things are getting more difficult. Here is my experiment :
- Compile the resource script as usually :
\masm32\bin\rc.exe Rsrc.rc
Convert the .res file to an object module with the MS tool cvtres :
\masm32\bin\cvtres.exe /MACHINE:x86 Rsrc.RES
Disassemble the file Rsrc.obj with Agner Fog's objconv tool :
objconv.exe -fmasm Rsrc.obj Rsrc.asm
Open Rsrc.asm and copy all the resource segments identified with .rsrc$0X ( X=1,2,... ) to your assembly module :
.386
option dotname
; @comp.id equ 000606C7H ; 394951
.rsrc$01 SEGMENT BYTE PUBLIC 'DATA' ; section number 2
db 00H, 00H, 00H, 00H, 00H, 00H, 00H, 00H ; 0000 _ ........
.
.
.
db 09H, 04H, 00H, 00H, 0D8H, 00H, 00H, 00H ; 00B0 _ ........
dd imagerel($R0001B0) ; 00B8 _ 00000000 (imgrel)
dd 00000048H, 00000000H ; 00BC _ 72 0
dd 00000000H ; 00C4 _ 0
dd imagerel($R0001F8) ; 00C8 _ 00000000 (imgrel)
dd 000002B8H, 00000000H ; 00CC _ 696 0
dd 00000000H ; 00D4 _ 0
dd imagerel($R000000) ; 00D8 _ 00000000 (imgrel)
dd 000001B0H, 00000000H ; 00DC _ 432 0
dd 00000000H ; 00E4 _ 0
.rsrc$01 ENDS
.rsrc$02 SEGMENT BYTE PUBLIC 'DATA' ; section number 3
$R000000 label byte
db 3CH, 3FH, 78H, 6DH, 6CH, 20H, 76H, 65H ; 0000 _ <?xml ve
db 72H, 73H, 69H, 6FH, 6EH, 3DH, 22H, 31H ; 0008 _ rsion="1
.
.
.
db 74H, 00H, 69H, 00H, 6FH, 00H, 6EH, 00H ; 04A0 _ t.i.o.n.
db 00H, 00H, 00H, 00H, 09H, 04H, 0B0H, 04H ; 04A8 _ ........
.rsrc$02 ENDS
END
Maintaining a separate asm file including the db sequences above is a better method.
Since ml.exe V6.1X does not support the statement imagerel, you can assemble your code with ml V8 ( or higher ) , Asmc or Uasm :
C:\asmc-master\bin\asmc.exe /coff DlgBox.asm
\masm32\bin\polink /SUBSYSTEM:WINDOWS DlgBox.obj
You can examine the executable with Resource Hacker to check if the resources are copied correctly to the application. You would also like to check Nidud's Asmc specific resource macros, a very nice work.
Thanks Vortex, I'm going to have to study this for a bit to figure it out. And I always use UASM :thumbsup:
I've been using this for several years now - the rc file gets generated on the fly:
include \masm32\MasmBasic\MasmBasic.inc ; download (http://masm32.com/board/index.php?topic=94.0)
Init
Inkey "Using common controls version ", ComCtl32$()
EndOfCode
Resources must be put below the end start or EndOfCode label; when pressing F6, content between the two Rsrc lines will be written to [filename].rc
Rsrc
#include "resource.h"
IDI_APPLICATION ICON "\\Masm32\\MasmBasic\\icons\\Smiley.ico"
01 RT_MANIFEST "\\Masm32\\MasmBasic\\Res\\XpManifest.xml"
Rsrc
Hi AW
Thank you, good to know. The program is useful for purposes other than make the manifest.
I need Unicode, Ansi is not enough for me.
Following a complaint by HSE in the dynamic layout thread (http://masm32.com/board/index.php?topic=8285.msg90794#msg90794) I made some tests with this macro, forcing the .drectve:
@AddManifest MACRO
if 1 ;idni @Environ(oLinker), <polink>
OPTION DOTNAME
.drectve SEGMENT INFO
db 34,"-manifestdependency:type='Win32'"
db " name='Microsoft.Windows.Common-Controls' version='6.0.0.0'"
db " processorArchitecture='*' publicKeyToken='6595b64144ccf1df'"
db " language='*'", 34, " -manifest:embed "
.drectve ENDS
echo *** manifest added in EndOfCode ***
else
.err <## GuiEnd/EndOfCode option XP works only with polink, sorry ##>
endif
ENDM
It turns out that this method works fine with PoLink of 21.3.2015 but not with any other versions, including the later version from 2.7.2018 :sad:
This might help:
db 34,"-manifestdependency:",34,"type='Win32'"
...
Did you test it?
Only within C:...
#pragma comment(linker, "/MANIFESTDEPENDENCY:\"type='Win32' "\
"name='Microsoft.Windows.Common-Controls' "\
"version='6.0.0.0' "\
"processorArchitecture='*' "\
"publicKeyToken='6595b64144ccf1df' "\
"language='*'\"")
#pragma comment(linker, "/MANIFEST:EMBED")
...so polink 9.0 works.
Quote from: TimoVJL on January 17, 2020, 03:21:45 AMpolink 9.0 works.
I re-checked and yes, you are right, versions 8.00.2 and 9.00.2 work. Unfortunately the old 6.50.0 that ships with the SDK chokes.
Binary to resource file converter handling XML files :
Usage : bin2res binaryfile.ext ResID ResType
ResID can be a number with a leading symbol # or a string identifying
the binary data.
ResType = RCD for RC_DATA binary file
XML for Manifest file
bin2res Autumn.txt POEM RCD
bin2res Manifest.xml #1 XML
\masm32\bin\rc Rsrc.rc
\masm32\bin\ml /c /coff Dlgbox.asm
\masm32\bin\polink /SUBSYSTEM:WINDOWS Dlgbox.obj Rsrc.res Autumn.res Manifest.res
I wonder if it would be useful to add resources to a library. Apparently it is possible, at least the linker doesn't complain, but how would one access such a resource? In my tests, the lib does contain the resource but the exe doesn't. Any idea?
QuoteNote that you can't lib in object files created with cvtres. If multiple object files are provided, lib complains as though as multiple .res files were given; if a single object file is provided, lib does not complain, but the linker simply ignores the embedded resource data in the lib file.
https://stackoverflow.com/questions/531502/vc-resources-in-a-static-library/1631078
Thanks. Indeed, I can see the resource in the lib file, but if the linker ignores it... what can we do ;-)
Long ago I experimented with adding resources in the form of DB sequences into library modules so that they did not depend on external resources to display simple things like icons and from memory I got it to work OK. Been so long ago I forget how it was done.
Dialog box templates in memory should do the job but the classical resource files are easier to use and maintain.
Even easier than a resource file, you can use macros like DlgDefine (http://www.jj2007.eu/MasmBasicQuickReference.htm#Mb1012) to do in-memory dialogs.
Hi Jochen,
Thanks. The macros are better, I agree with you.