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:
>>
>> <description>Open 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"
>>> />
>>> <description>Open 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:
>>> • 3 signs your SCM is hindering your productivity
>>> • Requirements for releasing software faster
>>> • 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 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
>>
>>
>
>
> ------------------------------------------------------------------------------
> "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
>
>
------------------------------------------------------------------------------
"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
