We are generating Interop dll for wuapi.dll using tlbimp.exe. Is this interop dll genrated by tlbimp.exe dependent on OS version?
Are there any dependencies on wuapi.dll that has to be packaged if this has to packaged and installed on client machines?
For more context :
C# code to find all office updates installed
How do I get a list of installed updates and hotfixes?
wuapi.dll has an OS dependency so the interop library does as well. Judging from the interface names there may be 6 versions of it out there. I see IUpdate through IUpdate5 for example on Win7. Trying to use a newer interface is liable to fail if you're running on an old version of Windows. Which interface is available on what version of Windows isn't documented in the MSDN library articles, you'll have to test this yourself. You can get old versions of Windows through an MSDN subscription.
Nothing but the interop library should be deployed, this is an operating system component.
Related
Did not find any suitable solution with existing questions so asking new question here.
We use log4cxx which has WS2_32.LIB as dependency. WS2_32.LIB is present in Windows SDK version 10.0.16299.0.
When using this log4cxx.dll on windows7 WS2_32.dll and all its dependencies gets loaded properly and application start normally.
but in windows 10 environment WS2_32.dll expects dependent dll's like API-MS-WIN-CORE-CRT-L1-1-0.DLL which are not part of windows10 or any of the microsoft visual c++ Redistributable which results in application error.
difference in WS2_32.dll and its dependencies between Windows7 and windows10 are clearly visible via dependency walker.
WS2_32.dll on windows 10:
whereas
WS2_32.dll on windows7 is
as shown here API-MS-WIN-CORE-CRT-L1-1-0.DLL is not a dependent dll in windows7 where as its in windows 10 which is not present in the system resulting in application error.
So what should be the way to make the application run successfully? what alternate dependency should be provided instead of WS2_32.LIB while compiling log4cxx.dll to avoid this issue in windows 10? Also where to find documentation about such changes between windows OS versions?
Please suggest.
The old depends.exe doesn't support those API sets and shows wrong data.
use the open source replacement called Dependencies:
Dependencies is a rewrite of the legacy software Dependency Walker
which was shipped along Windows SDKs, but whose developement stopped
around 2006. Dependencies can help Windows developers troubleshooting
their dll load dependencies issues.
I'm kind of lost with all these SDK windows versions.
For instance, I installed vs2013 on windows8.1, and I (also) need to link my apps against vs2008 runtime (platform toolset).
Should I install the whole VS2008 too or just the API. In the last case, what SDK do I have to install ?
You are talking about two very distinct things. The Windows SDK only covers the declarations and libraries that you need to make winapi calls. SDK v8.1 is suitable to target any modern Windows version since Vista, you select the Windows version you want to target by setting the _WIN32_WINNT macro. Note that XP requires an older SDK version, v7.1 is the last one that's still suitable and selected by setting the Platform Toolset to v120_xp.
The runtime libraries are a pure implementation detail of Visual Studio C/C++ projects and completely unrelated to the SDK. When you build such a program on VS2013 with the /MD compile option then it will have a dependency on msvcr120.dll, possibly msvcp120.dll and others. These DLLs implement the C runtime library and the C++ standard classes. And possibly MFC, ATL, OpenMP and AMP if you use those libraries.
If you still have a dependency on the VS2008 version of those libraries then you are liable to have a Really Big problem. You can obtain the release versions of those DLLs from the redist installer you can download from Microsoft. Having a dependency on the debug version requires having VS2008 installed on your machine. But having trouble linking the program and misery at runtime is highly indicated, the runtime libraries changed a great deal between VS2008 and VS2013 thanks to the new C++11 language standard. Having more than one CRT in a program is in general liable to cause lots of trouble.
You need to strongly pursue getting the library that still has the VS2008 dependency rebuilt. Contact the owner of the library if necessary to get an update.
We are developing a DLL, which calls generic WinUsb functions from WinDDK. This DLL needs to work in 32-bit and 64-bit versions of Windows, including xp, vista, win7, and possibly win8.
My question is, how can we manage the Visual Studio 2010 solution by targeting all these platforms? WinDDK libraries are different for each OS, so if I reference a library from the code:
#### #pragma comment (lib , "C:\\WinDDK\\7600.16385.1\\lib\\wlh\\i386\\winmm.lib" )
Or by referencing the library from the project options->includes section, this project only becomes correct for a particular target architecture. (In this example, Vista 32-bits, since I am including 'wlh').
Are we supposed to create a different project for each different OS target?
The WDK/DDK version does not constrain the OS version for which you build. You can pass the target OS as a build environment/compile parameter.
I think you should build DLL through DDK and use that in your VS project.
You can write pre-build event for your VS project to run a batch file which will build the DLL and put it in some well-known place for the project.
Also, you may have to create different project configurations for each platform you want to build for (at least different for 32-bit and 64-bit) and run appropriate build command for DLL.
According to this article, the version of a referenced dll is embedded in the exe file.
Using ProcExp, I can see that the runtime loaded dll is indeed the latest dll available on my machine, but I'm interested to know the linked version.
As a side note, I built the project using the VS9 msbuild, and interested in the VC runtime (msvcr90.dll) version. In the VC9 redist folder it is 9.0.30729.1, runtime the .4926 is loaded.
My questions are:
Is there any tool with which I can extract the dll version linked to (from the dll/exe)?
Which version does VS link to by default? The one found in its redist folder?
Thank you.
Dependency Walker might do it.
Actually, Dependency Walker seems to not read (or at least display) the version linked in the file.
But I found that I can use mt.exe from the Windows SDK or ResEdit to read the embedded manifests.
Also, to summarize my findings (targeting amd64 using msbuild with the Windows SDK for Win7, which seems to use VS9 (SP1?) libs):
Without special effort, VS9 (non-SP1) version 9.0.21022.8 of the CRT is written in the embedded manifest. Maybe this is a VS9 platform baseline.
Runtime the newest dll gets loaded, according to the SxS policy (good read can be found here, along with the article referenced in the question).
People seem to had problems when the appropriate policies are not installed (via the redist package for example), see here and [here] and 4[here]5.
The latter SO tells that if _BIND_TO_CURRENT_VCLIBS_VERSION=1 is defined, then the linker would link against the VS9 SP1 CRT (version 9.0.30729.1), which as noticed before, is indeed in the redist folder.
For future account, it would be nice if:
There would be a table with CRT version X.Y. introduced in OS/SP/etc Z.W.
If one could know that what is a safe version to target, which is possibly available on most users machines by default.
That is, can I get away with DLLs in the install directory or does the installer need to ensure that MingW is fully installed?
If you install the Qt SDK, it will actually install its own MinGW tree.
This does not directly answer your question, but generally speaking, to ensure I have all the right dependencies when creating an installer, I do the following:
Use Depends, a Microsoft tool that shows what DLLs a Windows executable (.exe or another .dll) depends on. This will not show dynamically loaded DLLs though, such as QT plugins. I believe Depends is part of the Platform SDK (it used to be, anyway), which you should be able to download. See here for example.
Use a virtualization tool (like VirtualBox or VMWare) to install a fresh copy of Windows and your application. If it complains of missing DLLs on startup, you missed something in the install package.
You should be aware of any dependencies on the Visual C++ run-time. There are many different versions out there, and if your app depends on them, you need to install the correct version to the Windows\WinSxS directory. Microsoft provides a redistributable for each version of Visual C++ (including the express edition, which you can get for free). I only mention this because I noticed when installing Qt SDK that the VC++ redistributable was getting installed, so the Qt DLLs may have a dependency on the VC++ run-time.