Visual studio 2008 and vcredist_x86.exe requirements
category: code [glöplog]
GDIplus seems to be embedded even on a plain vanilla "nehe" project, which only includes
#include <windows.h> // Header File For Windows
#include "gl.h" // Header File For The OpenGL32 Library
#include "glu.h" // Header File For The GLu32 Library
#include "glaux.h" // Header File For The Glaux Library
#include <windows.h> // Header File For Windows
#include "gl.h" // Header File For The OpenGL32 Library
#include "glu.h" // Header File For The GLu32 Library
#include "glaux.h" // Header File For The Glaux Library
anyway, GDIplus doesn't seem to be the problem; it is the MSVxxx things (which are not in the nehe simple example).
i always thought you yourself ( navis :p ) have way too many dependancies in your projects...watching your prods and how many .dlls are shipped with em...
...maybe thats what you get for doing so now !
but yes: that msvcr-prob suxx bigtime...microsofts fault !
download sprite-o-mat source and use the msvcrt.lib inside ! thats a very old one and should be a fuckaround :)
...maybe thats what you get for doing so now !
but yes: that msvcr-prob suxx bigtime...microsofts fault !
download sprite-o-mat source and use the msvcrt.lib inside ! thats a very old one and should be a fuckaround :)
ok so here is what is happening:
I've opened all our demos since lifeforce and found that the vcredist thing breaks in rupture. It was there when I used opencv 1.1 (rather than 1.0) for the first time.
So I now recompiled/built with 1.0 and the dependencies are gone. So, a word of warning: be careful of opencv > 1.1 (current version is 2.0).
I've opened all our demos since lifeforce and found that the vcredist thing breaks in rupture. It was there when I used opencv 1.1 (rather than 1.0) for the first time.
So I now recompiled/built with 1.0 and the dependencies are gone. So, a word of warning: be careful of opencv > 1.1 (current version is 2.0).
oh and thanks everybody, especially for pointing out depends.exe
wow...i really would have bet my last shirt on m$ doing sth wrong again !
but good you found the "bug" :)
happy partying asm then :D
but good you found the "bug" :)
happy partying asm then :D
A little addition to my post above regarding patched msvcrxx.dll.
It is possible to erase manifest in existing program without compiling source code. Open the target .exe in Resource Tuner and edit manifest to get rid of WinSxS sections:
>>>
Save .exe file with updated manifest, then copy patched runtime libraries to the same dir. That's all.
It is possible to erase manifest in existing program without compiling source code. Open the target .exe in Resource Tuner and edit manifest to get rid of WinSxS sections:
Quote:
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0"><assemblyIdentity type="win32" processorArchitecture="*" version="11.0.0.0" name=""></assemblyIdentity><description></description><dependency><dependentAssembly><assemblyIdentity type="win32" name="Microsoft.Windows.Common-Controls" version="6.0.0.0" language="*" processorArchitecture="*" publicKeyToken="6595b64144ccf1df"></assemblyIdentity></dependentAssembly></dependency><dependency><dependentAssembly><assemblyIdentity type="win32" name="Microsoft.VC90.CRT" version="9.0.21022.8" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity></dependentAssembly></dependency><dependency><dependentAssembly><assemblyIdentity type="win32" name="Microsoft.VC80.CRT" version="8.0.50727.762" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity></dependentAssembly></dependency><trustInfo xmlns="urn:schemas-microsoft-com:asm.v2"><security><requestedPrivileges><requestedExecutionLevel level="asInvoker" xmlns:ms_asmv3="urn:schemas-microsoft-com:asm.v3" ms_asmv3:uiAccess="false"></requestedExecutionLevel></requestedPrivileges></security></trustInfo></assembly>
>>>
Quote:
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0"><assemblyIdentity type="win32" processorArchitecture="*" version="11.0.0.0" name=""></assemblyIdentity><description></description><dependency><dependentAssembly><assemblyIdentity type="win32" name="Microsoft.Windows.Common-Controls" version="6.0.0.0" language="*" processorArchitecture="*" publicKeyToken="6595b64144ccf1df"></assemblyIdentity></dependentAssembly></dependency><trustInfo xmlns="urn:schemas-microsoft-com:asm.v2"><security><requestedPrivileges><requestedExecutionLevel level="asInvoker" xmlns:ms_asmv3="urn:schemas-microsoft-com:asm.v3" ms_asmv3:uiAccess="false"></requestedExecutionLevel></requestedPrivileges></security></trustInfo></assembly>
Save .exe file with updated manifest, then copy patched runtime libraries to the same dir. That's all.
*THE HORROR*
xml should *never* be touched by humans!
xml should *never* be touched by humans!
You don't have to modify msvcmxx.dll or msvcpxx.dll - because there are no manifest checks in these libraries.
A solution where you WOULDN'T have to distribute the patched or unpatched DLLs would be much better imo. Applications then would be tied to a specific OS version or higher though.
I tried editing the manifest on disk and then relinking, but that didn't work.
I heared VS2010 should be able to compile/link an application with different VS versions. Anybody tried that? Can the Express version do that too?
Btw. If you ever need to detect if the VC redistributables are installed, you might want to read this (2005), this (2008) and this (2010).
I tried editing the manifest on disk and then relinking, but that didn't work.
I heared VS2010 should be able to compile/link an application with different VS versions. Anybody tried that? Can the Express version do that too?
Btw. If you ever need to detect if the VC redistributables are installed, you might want to read this (2005), this (2008) and this (2010).
Plus here is some information on that matter. I based my project that checks for redists on this.