I'm trying to get my head around the mess generated by SxS, isolated apps, embedded manifests, local deployment and all the other "solutions" to DLL hell. It's hard enough to make it work on Windows, but making it work well under wine is another challenge.
In a nutshell, I'd like to ship a custom wine64 RPM package that can co-exist with distribution provided wine32 RPMs. I also want to make a couple of companion RPMs, which provide x64 apps that depend on my wine64 RPM. I don't want to require an installation of the x64 packages under Wine. i.e. I want to avoid the requirement to run vcredist_x64.exe for each user. The most obvious solution to this seems to be to include the DLLs from "Microsoft Visual Studio 9.0\VC\redist\amd64\Microsoft.VC90.CRT" in the same dir as the x64 application executable, known as "application local deployment".
Now, this is where I get confused. The VC redist files provide DLLs with version 9.0.30729.1, whereas the manifest embedded in the application has version 9.0.21022.8. When the 9.0.30729.1 VC redist files are installed in the windows dir, the associated policies will redirect requests for 9.0.21022.8 to use 9.0.30729.1, but this does not seem to work when the DLLs are deployed in the app directory.
Wine itself provides msvcr90.dll.so, which as far as I can tell doesn't play the manifest games or provide any particular version number.
Should I be using msvcr90.dll from VC redist?
Should I be using msvcr90.dll.so provided by wine? If so, how do I tell wine to ignore manifests and just load the DLLs found in the app dir?
Thanks for any insights you could provide.
On Monday 12 July 2010 12:49:02 pm Peter Urbanec wrote:
I'm trying to get my head around the mess generated by SxS, isolated apps, embedded manifests, local deployment and all the other "solutions" to DLL hell. It's hard enough to make it work on Windows, but making it work well under wine is another challenge.
In a nutshell, I'd like to ship a custom wine64 RPM package that can co-exist with distribution provided wine32 RPMs. I also want to make a couple of companion RPMs, which provide x64 apps that depend on my wine64 RPM. I don't want to require an installation of the x64 packages under Wine. i.e. I want to avoid the requirement to run vcredist_x64.exe for each user. The most obvious solution to this seems to be to include the DLLs from "Microsoft Visual Studio 9.0\VC\redist\amd64\Microsoft.VC90.CRT" in the same dir as the x64 application executable, known as "application local deployment".
Now, this is where I get confused. The VC redist files provide DLLs with version 9.0.30729.1, whereas the manifest embedded in the application has version 9.0.21022.8. When the 9.0.30729.1 VC redist files are installed in the windows dir, the associated policies will redirect requests for 9.0.21022.8 to use 9.0.30729.1, but this does not seem to work when the DLLs are deployed in the app directory.
Wine itself provides msvcr90.dll.so, which as far as I can tell doesn't play the manifest games or provide any particular version number.
Should I be using msvcr90.dll from VC redist?
Should I be using msvcr90.dll.so provided by wine? If so, how do I tell wine to ignore manifests and just load the DLLs found in the app dir?
Thanks for any insights you could provide.
Hi!
You need a special manifest to redistribute the VC runtimes in the application's directory. This is provided with Visual C++ (but not with the Express edition that doesn't allow you to distribute the created applications).
I don't think I am allowed to publish that manifest. Please find one somewhere on the net or in some application that installs msvc*90 locally. Hint: no hashes are provided for files, just the DLL name.
Paul
On 12/07/10 20:44, Paul Chitescu wrote:
On Monday 12 July 2010 12:49:02 pm Peter Urbanec wrote:
Wine itself provides msvcr90.dll.so, which as far as I can tell doesn't play the manifest games or provide any particular version number.
Should I be using msvcr90.dll from VC redist?
Should I be using msvcr90.dll.so provided by wine? If so, how do I tell wine to ignore manifests and just load the DLLs found in the app dir?
Thanks for any insights you could provide.
You need a special manifest to redistribute the VC runtimes in the application's directory. This is provided with Visual C++ (but not with the Express edition that doesn't allow you to distribute the created applications).
I am already using "Microsoft Visual Studio 9.0\VC\redist\amd64\Microsoft.VC90.CRT" from a full blown install of Visual Studio 2008, which includes a manifest. Is that the manifest you mean?
This manifest does not include any redirections and so I run into the problem listed in the Caveats section of this blog entry: http://blog.helgeklein.com/2010/03/deploying-visual-c-runtime-files-as.html
I'm still not quite sure whether I need to persist with distributing the MSVC provided DLLs or whether I can use the wine implementation instead.
Can I get wine to ignore the manifests and just load DLLs from the app directory?
On Mon, Jul 12, 2010 at 12:44 PM, Peter Urbanec winehq.org@urbanec.netwrote:
Can I get wine to ignore the manifests and just load DLLs from the app directory?
I am not sure if our loader was every updated to mimic this behavior
(Alexandre and I discussed it before), but older versions of windows used to support local dlloverriding by making a dummy file called appname.exe.local and placing that in the same folder of the application and the dlls you want to load. For example, say you have iexplore.exe and you want to force using some local dlls for testing, you can create a dummy file called iexplore.exe.local which would be placed in the same folder.
Like I said, I don't know if support for this was added to Wine, iTunes and Internet Explorer 5 both made use of this behavior under Windows 2000 and it's possible the behavior has changed in newer windows versions.
Thanks
-
Paul Chitescu -
Peter Urbanec -
Steven Edwards