I've got a bug from one of our customers and believe that the problem lies with MSVCR80.DLL v8.0.50727.3053 - a version which I cannot find for download anywhere, however a google search turns up plenty of other crash reports.
Latest version on my system (and others here) is 8.0.50727.1433 and the Microsoft Visual C++ 2005 SP1 Redistributable Package (x86) is only version 8.0.5027.762 (currently same as the merge module we use)
Is there an "official" link to get this update? Is it bundled with any other Microsoft products?
EDIT: please don't email it to me, I'm looking for the SxS install.
EDIT2: damn, that wasn't the problem after all :(
A thread on the MSDN forums pointed out the answer: msvcr80.dll version 8.0.50727.3053 is included in .NET Framework 3.5 SP1
You ought to be able to answer this question using Microsoft's DLL Help Database http://support.microsoft.com/dllhelp/
Unfortunately, when I try it, I only get two answers for msvcr80.dll whereas there ought to be dozens of different versions: and I don't know why.
Try to use merge modules from "C:\Program Files\Common Files\Merge Modules".
Related
I am trying to install libcurl for my C++ project on VSCode and I came across a method to install via vckpg from this link: How do you properly install libcurl for use in visual studio 2017?
Hence, I looked for the documentation by Microsoft but only found that you can install vckpg for VSCode for Linux and MacOS but I couldn't find anything on how to install vckpg for VSCode on Windows.
Any idea how do you install vckpg for VSCode on Windows? Or is there an alternative method of installing libcurl on VSCode?
Currently VS Code does not support vcpkg on Windows.
As mentioned here the following issue is directly connected with VS Code support of vcpkg on Windows: https://github.com/microsoft/vcpkg/issues/10217. The issue is currently open and no workaround is provided.
The support may be provided in the future. Here are the comments from the thread:
ghost: "If there are enough requests, a feature request could be initiated to see what would be needed to integrate with CODE RUNNER and/or a plugin for VSCODE."
strega-nil: "Code Runner is not currently a supported way of building with vcpkg; we may add support eventually, but more likely it should be added by the community (or, even better, vcpkg support should be added to Code Runner). However, we do have features hopefully coming down the pipeline which will make life a lot easier for community members adding that support."
Unfortunately i was struggling with the same issue and installing C++ Redistributable which #mutantkeyboard recommended didn't solve the problem.
I installed VS Community Edition with English language pack and now it's OK.
Does anyone know when support for the AUDCLNT_STREAMFLAGS_AUTOCONVERTPCM stream flag was added to WASAPI? MSDN mentions this flag briefly, but doesn't go into much detail regarding its use and which versions of Windows support this.
I'm using the Platform SDK that comes with Visual Studio 2015 and AUDCLNT_STREAMFLAGS_AUTOCONVERTPCM isn't even defined.
Download and install the separate Windows 10 SDK, even though most of the components are installed with VS2015:
https://developer.microsoft.com/en-us/windows/downloads/windows-10-sdk
I had the same problem as you, and installing the latest Windows 10 SDK solved it for me. (Version 10.0.14393.795 at the time of writing.)
I wrote a C program and works fine on Windows 7 and Linux, but when I execute it on Windows XP I get the error:
"_except_handler4_common could not be located in the dynamic link library msvcrt.dll"
I researched it and some people said to delete the DLL "dwmapi.dll" which I don't have, so that's not my problem.
Some one told me to use depends walker(depends.exe) to find who is using msvcrt.dll. I did and find that pcre library is using it and there actually is a problem with it, but I don't have any idea how to solve this. Can any one help me?
Here's image of what depends walker show me:
Reason possibilities (afaiu):
a) You linked to msvcrt.dll specifically when building - this should
not happen according to Microsoft support unless you specifically do
it.
b) Some other installed or copied program/driver on your XP that
links to "wrong" version of msvcrl.dll is being triggered.
Depending on what the reason is,
here are few ideas to resolve:
1) There might be some program/driver/etc. installation on your XP
machine that has introduced "Vista/Win7 related crap" onto it. It is
said (by the internets) that PCRE3.DLL belongs to "GnuWin32 Non-system
processes". That means you can try to find it and rename/delete it. Or
delete the program you that uses it.
2) Installing the redist for XP of the C++ redistributable that you
used to build on Win7 might help. This is link for VS2005: (darn..
use google - i can only give two links per post :P)
Rebuilding:
3) Just build the file from sources on your XP machine using some
VisualStudio version you can get on it. And check those VS project
properties!
4) Fix your build on Windows7. You might be linking to
_except_handler4_common in msvcrt.dll in your Windows 7 build. Make sure that you do not do that. You can specifically instruct the linker
not to link to it in VisualStudio project properties
"/NODEFAULTLIB:msvcrt80.lib". You also did not specify what are you
using for building. VS2005, VS2008, VS2010, gcc?
Answer based on educated guesses and Jeffrey Tan research here:
and research here:
(On behalf of OP)
The problem was with the pcre3.dll, as i've told before, and i simply change the version of it, I was using the version 7.x and change to 4.4 that calls pcre.dll instead of pcre3.dll, that solve my problem if any one have the same issue.
here is the link to the correct lib:
pcre-4.4-dll.zip
I am trying to install CppUnit on Windows.
I have downloaded it from here, decompressed it, and noticed that all files have ,v in their name, and no extension.
The instructions for installation (in included files, as well as on every site I found that suggests installation for Windows, are for Linux. (example installing CppUnit for Windows Instructions).
Others, just to build: (example: installing CppUnit for Visual Studio Instructions or Second answer on same topic).
The accepted answer on the above link has a comment saying that the person who accepted it "Sorted it, I downloaded another version" - after he had exactly the same problem as I did - but did not specify what version or from where...
The link I have above is the latest version.
I was able to find a very old version, 1.12.1, from 2008, that would almost build (with lots of errors), on Windows. I am using it now to learn how to implement CppUnit. Still, it is 4 years old... I would like to be able to use the latest build...
Please, can someone give me some suggestion that I can implement, and works, in Windows, to install the latest cppUnit ?
Thank you.
The first download you made is an archive of the CVS repository. This explains the strange ,v "extensions" you see on the files. It is not what you should download. And indeed, the correct download you made (version 1.12.1) is 4 years old. It was the latest stable version though, so it should normally build. I don't know what the exact problems were you encountered.
There are however two newer options. There is CppUnit2, which is available here. And there is an independent fork of the original project available here.
Perhaps you can check either of those out and see if they are less problematic for you.
The fork Bart mentions on freedesktop.org appears to be the (only?) continuation of CppUnit version 1, and at this moment has version 1.13.2.
Note that for this version, if you want to use the test runner on Win64, you'll have to make a small modification described here until that has made it to a newer release.
We include a 3rd Party lib+DLL that recently causes a lot of trouble on installations. Using dependencywalker, we found that the dll itself refers to two different Versions of
MSVCR80.DLL:
Version 8.0.50727.4053 and
Version 8.0.50727.42
alt text http://img101.imageshack.us/img101/1734/dependencywalk2.jpg
In MOST cases installation makes no problems, even if we distribute none of both versions. But in a number of cases our installation just does not start. We then find messages in the windows system event log from the SideBySide manger: "Version of DLL does not match". In most cases again this problem can be resolved, by installing the .NET framework (although we do not use this). But now we have a case where this does not help.
I know that a solution would be, to install both versions as a shared assembly, but that seems not to be easy, and besides that i would prefer a much simpler solution. Does anybody know a workaround?
Can i somehow use only one version of the Dll?
EDIT:
I now tried cristians advice:
D:\Develop\LEADTOOLS15\patch_maifest>mt.exe -inputresource:ltkrn15u.dll;#1 -out:old.manifest
Microsoft (R) Manifest Tool version 5.2.3790.2075
Copyright (c) Microsoft Corporation 2005.
All rights reserved.
mt.exe : general error c101008c: Failed to read the manifest from the resource of file "ltkrn15u.dll". Ressource not found.
If i view the dlls dependencies with full paths, i see the following:
alt text http://img340.imageshack.us/img340/4122/dependencywalk3.jpg
The lower MSVCR80.DLL is the one withe Version ...42. I dont understand this. Why does MSVCP80.DLL refer to a different Version of MSVCR80.DLL than the one besides it. Is that maybe a problem of the dependencywalker ?
Your best option is to ship the needed DLLs within your applications installer package. Use at least the version that your 3rd party DLL depends on.
Microsoft offers standalone installers for its runtime DLLs (vcredits_*). The latest version for VisualStudio 2005 can be downloaded here. That is also the version that your DLL is linked against. You can silently launch the redistributable package from your installer.
As a manual workaround for already installed systems, simply apply the redist installer on the target machine.
If you choose this method, you don't need to be afraid of version conflicts, as applications depending on an older versions will be redirected to always use the most recent one.
For a better understanding you have look at this MSDN articles.
You have to change / update the manifest resource from the dlls.
mt.exe -inputresource:dll_with_manifest.dll;#1 -out:old.manifest
mt.exe -manifest new.manifest -outputresource:dll_with_manfiest.dll;#1
Sometimes the RT_MANIFEST (type 24) resource type doesn't have the #1 index in resource table, you should use a Resource Viewer (ResourceHacker, or ResEdit) and find out the index number. I have seen cases when the manifest has the #2 index number.