Re: [Oorexx-devel] rexx.exe manifest file and cmake.
Hi Rick, I'm still traveling and only have good Internet once in awhile. So I've put off answering this. But thought I'd better do something about it. The existing manifest was only needed for ooDialog. The important part is the part to load the 6.0 common controls library: descriptionOpen Object Rexx Interpreter./description dependency dependentAssembly assemblyIdentity type=win32 name=Microsoft.Windows.Common-Controls version=6.0.0.0 processorArchitecture=amd64 publicKeyToken=6595b64144ccf1df language=* / /dependentAssembly /dependency Since that is needed by any Windows GUI application to use the 6.0, or later, version of the library, it seems odd to me that CMake wouldn't have a way to do it, if it is generating its own manifest. Without it, the pre-verison 6.0 is loaded automatically, which is essentially W2K controls. It took me quite a bit of work to get it working originally. It needs to be the manifest of the executable that loads the ooDialog extension, which I didn't understand when I first started with it. I thought it was sufficient to use it for ooDialog.dll. So, if we can't get CMake to add the common controls part to the manifest it generates, then I'll have to add the custom step. I won't be back at home until after Memorial day. I'll work on it then if you haven't already come up with something. -- Mark Miesfeld On Mon, May 5, 2014 at 4:17 AM, Rick McGuire object.r...@gmail.com wrote: This is mostly to get this question recorded for Mark for when he gets back from vacation. I'm currently running into some issues with the manifest file we're embedding in rexx.exe via an include within rexx.rc. Building this via this method causes a duplicate resource error because the cmake build tools generate a default manifest which gets embedded via the /MANIFEST and /MANIFESTFILE linker options. When the .rc file pulls in the second manifest, this creates the error. For now, I've commented out the link in rexx.rc that pulls in the manifest file, so the cmake build is using the one it generates. For the existing build, I've switched to rexx.mak file to use /MANIFEST and /MANIFESTFILE link options. We're going to run into this same issue with the oodialog executables when we get that portion working in cmake as well. I really don't understand the manifests and what information needs to be in there. The cmake-generated manifests and the ones we are using are quite different. Here is our version: ?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=amd64 name=RexxLA.ooRexx.rexx type=win32 / descriptionOpen Object Rexx Interpreter./description dependency dependentAssembly assemblyIdentity type=win32 name=Microsoft.Windows.Common-Controls version=6.0.0.0 processorArchitecture=amd64 publicKeyToken=6595b64144ccf1df language=* / /dependentAssembly /dependency /assembly and here is the cmake version: ?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 /assembly Note that cmake generates one of these for all of the dlls and exes. So, do we need to continue using our manifest version or can just allow the cmake defaults? Does the cmake version cause any problems with the other files? I've found information on how to use custom manifests, which involves disabling the automatic generation and then adding a post-processing step that uses a tool to add the custom manifest. A bit of a pain, but doable. I think I'd prefer to let cmake do the heavy lifting if we can. Rick -- Is your legacy SCM system holding you back? Join Perforce May 7 to find out: #149; 3 signs your SCM is hindering your productivity #149; Requirements for releasing software faster #149; Expert tips and advice for migrating your SCM now http://p.sf.net/sfu/perforce ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get
Re: [Oorexx-devel] rexx.exe manifest file and cmake.
Mark, Thanks for the answer. I did find a solution for this. It turns out to possible to replace or merge additional manifest information into the executables as a post-processing step. I wasn't really sure which .exe files needed this, so I end up merging it into them all. If only ooDialog needs this, then that can simplify things in the cmake file considerably since I had to add a lot of WIN32 conditional stuff to do this. Rick On Wed, May 21, 2014 at 5:17 PM, Mark Miesfeld miesf...@gmail.com wrote: Hi Rick, I'm still traveling and only have good Internet once in awhile. So I've put off answering this. But thought I'd better do something about it. The existing manifest was only needed for ooDialog. The important part is the part to load the 6.0 common controls library: descriptionOpen Object Rexx Interpreter./description dependency dependentAssembly assemblyIdentity type=win32 name=Microsoft.Windows.Common-Controls version=6.0.0.0 processorArchitecture=amd64 publicKeyToken=6595b64144ccf1df language=* / /dependentAssembly /dependency Since that is needed by any Windows GUI application to use the 6.0, or later, version of the library, it seems odd to me that CMake wouldn't have a way to do it, if it is generating its own manifest. Without it, the pre-verison 6.0 is loaded automatically, which is essentially W2K controls. It took me quite a bit of work to get it working originally. It needs to be the manifest of the executable that loads the ooDialog extension, which I didn't understand when I first started with it. I thought it was sufficient to use it for ooDialog.dll. So, if we can't get CMake to add the common controls part to the manifest it generates, then I'll have to add the custom step. I won't be back at home until after Memorial day. I'll work on it then if you haven't already come up with something. -- Mark Miesfeld On Mon, May 5, 2014 at 4:17 AM, Rick McGuire object.r...@gmail.comwrote: This is mostly to get this question recorded for Mark for when he gets back from vacation. I'm currently running into some issues with the manifest file we're embedding in rexx.exe via an include within rexx.rc. Building this via this method causes a duplicate resource error because the cmake build tools generate a default manifest which gets embedded via the /MANIFEST and /MANIFESTFILE linker options. When the .rc file pulls in the second manifest, this creates the error. For now, I've commented out the link in rexx.rc that pulls in the manifest file, so the cmake build is using the one it generates. For the existing build, I've switched to rexx.mak file to use /MANIFEST and /MANIFESTFILE link options. We're going to run into this same issue with the oodialog executables when we get that portion working in cmake as well. I really don't understand the manifests and what information needs to be in there. The cmake-generated manifests and the ones we are using are quite different. Here is our version: ?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=amd64 name=RexxLA.ooRexx.rexx type=win32 / descriptionOpen Object Rexx Interpreter./description dependency dependentAssembly assemblyIdentity type=win32 name=Microsoft.Windows.Common-Controls version=6.0.0.0 processorArchitecture=amd64 publicKeyToken=6595b64144ccf1df language=* / /dependentAssembly /dependency /assembly and here is the cmake version: ?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 /assembly Note that cmake generates one of these for all of the dlls and exes. So, do we need to continue using our manifest version or can just allow the cmake defaults? Does the cmake version cause any problems with the other files? I've found information on how to use custom manifests, which involves disabling the automatic generation and then adding a post-processing step that uses a tool to add the custom manifest. A bit of a pain, but doable. I think I'd prefer to let cmake do the heavy lifting if we can. Rick -- Is your legacy SCM system holding you back? Join Perforce May 7 to find out: #149; 3 signs your SCM is hindering your productivity #149; Requirements for releasing software faster #149; Expert tips and advice for
Re: [Oorexx-devel] rexx.exe manifest file and cmake.
On Wed, May 21, 2014 at 2:29 PM, Rick McGuire object.r...@gmail.com wrote: Mark, Thanks for the answer. I did find a solution for this. It turns out to possible to replace or merge additional manifest information into the executables as a post-processing step. I wasn't really sure which .exe files needed this, so I end up merging it into them all. If only ooDialog needs this, then that can simplify things in the cmake file considerably since I had to add a lot of WIN32 conditional stuff to do this. It is actually all the executables that would run an ooDialog program. So, rexx.exe, rexxhide.exe, rexxpaws.exe and oodialog.exe need the manifest. With the common controls dependency part I posted. -- Mark Miesfeld Rick On Wed, May 21, 2014 at 5:17 PM, Mark Miesfeld miesf...@gmail.com wrote: Hi Rick, I'm still traveling and only have good Internet once in awhile. So I've put off answering this. But thought I'd better do something about it. The existing manifest was only needed for ooDialog. The important part is the part to load the 6.0 common controls library: descriptionOpen Object Rexx Interpreter./description dependency dependentAssembly assemblyIdentity type=win32 name=Microsoft.Windows.Common-Controls version=6.0.0.0 processorArchitecture=amd64 publicKeyToken=6595b64144ccf1df language=* / /dependentAssembly /dependency Since that is needed by any Windows GUI application to use the 6.0, or later, version of the library, it seems odd to me that CMake wouldn't have a way to do it, if it is generating its own manifest. Without it, the pre-verison 6.0 is loaded automatically, which is essentially W2K controls. It took me quite a bit of work to get it working originally. It needs to be the manifest of the executable that loads the ooDialog extension, which I didn't understand when I first started with it. I thought it was sufficient to use it for ooDialog.dll. So, if we can't get CMake to add the common controls part to the manifest it generates, then I'll have to add the custom step. I won't be back at home until after Memorial day. I'll work on it then if you haven't already come up with something. -- Mark Miesfeld On Mon, May 5, 2014 at 4:17 AM, Rick McGuire object.r...@gmail.comwrote: This is mostly to get this question recorded for Mark for when he gets back from vacation. I'm currently running into some issues with the manifest file we're embedding in rexx.exe via an include within rexx.rc. Building this via this method causes a duplicate resource error because the cmake build tools generate a default manifest which gets embedded via the /MANIFEST and /MANIFESTFILE linker options. When the .rc file pulls in the second manifest, this creates the error. For now, I've commented out the link in rexx.rc that pulls in the manifest file, so the cmake build is using the one it generates. For the existing build, I've switched to rexx.mak file to use /MANIFEST and /MANIFESTFILE link options. We're going to run into this same issue with the oodialog executables when we get that portion working in cmake as well. I really don't understand the manifests and what information needs to be in there. The cmake-generated manifests and the ones we are using are quite different. Here is our version: ?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=amd64 name=RexxLA.ooRexx.rexx type=win32 / descriptionOpen Object Rexx Interpreter./description dependency dependentAssembly assemblyIdentity type=win32 name=Microsoft.Windows.Common-Controls version=6.0.0.0 processorArchitecture=amd64 publicKeyToken=6595b64144ccf1df language=* / /dependentAssembly /dependency /assembly and here is the cmake version: ?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 /assembly Note that cmake generates one of these for all of the dlls and exes. So, do we need to continue using our manifest version or can just allow the cmake defaults? Does the cmake version cause any problems with the other files? I've found information on how to use custom manifests, which involves disabling the automatic generation and then adding a post-processing step that uses a tool to add the custom manifest. A bit of a pain, but doable. I think I'd prefer to let cmake do the heavy lifting if we can. Rick
Re: [Oorexx-devel] rexx.exe manifest file and cmake.
Yep, I caught that. I had also added it to rexxc.exe because I didn't understand what it was for. That one can be removed. Btw, I see ooDialog has a .exe file and a .com file. I think I've got those building correctly, but I'm not sure I understand what the .com file is for. I'm also adding the manifest to that one. Rick On Wed, May 21, 2014 at 5:35 PM, Mark Miesfeld miesf...@gmail.com wrote: On Wed, May 21, 2014 at 2:29 PM, Rick McGuire object.r...@gmail.comwrote: Mark, Thanks for the answer. I did find a solution for this. It turns out to possible to replace or merge additional manifest information into the executables as a post-processing step. I wasn't really sure which .exe files needed this, so I end up merging it into them all. If only ooDialog needs this, then that can simplify things in the cmake file considerably since I had to add a lot of WIN32 conditional stuff to do this. It is actually all the executables that would run an ooDialog program. So, rexx.exe, rexxhide.exe, rexxpaws.exe and oodialog.exe need the manifest. With the common controls dependency part I posted. -- Mark Miesfeld Rick On Wed, May 21, 2014 at 5:17 PM, Mark Miesfeld miesf...@gmail.comwrote: Hi Rick, I'm still traveling and only have good Internet once in awhile. So I've put off answering this. But thought I'd better do something about it. The existing manifest was only needed for ooDialog. The important part is the part to load the 6.0 common controls library: descriptionOpen Object Rexx Interpreter./description dependency dependentAssembly assemblyIdentity type=win32 name=Microsoft.Windows.Common-Controls version=6.0.0.0 processorArchitecture=amd64 publicKeyToken=6595b64144ccf1df language=* / /dependentAssembly /dependency Since that is needed by any Windows GUI application to use the 6.0, or later, version of the library, it seems odd to me that CMake wouldn't have a way to do it, if it is generating its own manifest. Without it, the pre-verison 6.0 is loaded automatically, which is essentially W2K controls. It took me quite a bit of work to get it working originally. It needs to be the manifest of the executable that loads the ooDialog extension, which I didn't understand when I first started with it. I thought it was sufficient to use it for ooDialog.dll. So, if we can't get CMake to add the common controls part to the manifest it generates, then I'll have to add the custom step. I won't be back at home until after Memorial day. I'll work on it then if you haven't already come up with something. -- Mark Miesfeld On Mon, May 5, 2014 at 4:17 AM, Rick McGuire object.r...@gmail.comwrote: This is mostly to get this question recorded for Mark for when he gets back from vacation. I'm currently running into some issues with the manifest file we're embedding in rexx.exe via an include within rexx.rc. Building this via this method causes a duplicate resource error because the cmake build tools generate a default manifest which gets embedded via the /MANIFEST and /MANIFESTFILE linker options. When the .rc file pulls in the second manifest, this creates the error. For now, I've commented out the link in rexx.rc that pulls in the manifest file, so the cmake build is using the one it generates. For the existing build, I've switched to rexx.mak file to use /MANIFEST and /MANIFESTFILE link options. We're going to run into this same issue with the oodialog executables when we get that portion working in cmake as well. I really don't understand the manifests and what information needs to be in there. The cmake-generated manifests and the ones we are using are quite different. Here is our version: ?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=amd64 name=RexxLA.ooRexx.rexx type=win32 / descriptionOpen Object Rexx Interpreter./description dependency dependentAssembly assemblyIdentity type=win32 name=Microsoft.Windows.Common-Controls version=6.0.0.0 processorArchitecture=amd64 publicKeyToken=6595b64144ccf1df language=* / /dependentAssembly /dependency /assembly and here is the cmake version: ?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 /assembly Note that cmake generates one of these for all of the dlls and exes. So, do we need to continue using our manifest
Re: [Oorexx-devel] rexx.exe manifest file and cmake.
On Wed, May 21, 2014 at 2:39 PM, Rick McGuire object.r...@gmail.com wrote: Yep, I caught that. I had also added it to rexxc.exe because I didn't understand what it was for. That one can be removed. Btw, I see ooDialog has a .exe file and a .com file. I think I've got those building correctly, but I'm not sure I understand what the .com file is for. I'm also adding the manifest to that one. The .com file is essentially to allow: C:\work.ooRexxoodialog -v ooDialog 4.2.4.10010 C:\work.ooRexx The .com file runs first and parses the command line. If the command line indicates a GUI application is needed, it restarts itself as oodialog.exe. oodialog.exe is linked as subsystem:windows, while oodialog.com is linked as subsystem:Console So, I don't think oodialog.com needs the manifest, but I don't remember for sure. It would depend on if oodialog.exe is started as a separate process or created as a child process. Which I don't remember off the top of my head. -- Mark Miesfeld -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
