What redistributables needed?

[anthonyrichards]

I have a large .DLL project (32-bit) developed using CVF on WIndows XP Pro. When deploying it to a different computer, CVF recommended accompanying it with VFRUN.EXE and running it to install any files that the .DLL 'might' be dependent on. I do this, even though I am not sure what files they are.

Now, I am contemplating porting the CVF project over to IVF (with VS2005 pro) on the same development platform for further development (again, 32-bit). Please can you tell me, in advance of (highly unlikely!) successful conversion to IVF, what files my .DLL is likely to require to run on a different Windows machine? And what IVF's equivalent to VFRUN.EXE is in the case I need it?
TIA.

P.S. Because my DLL code is made to be used by third-party software, I am required to include a 'C' pre-compiled object file when linking my .DLL code. The object file contains various relocation symbols for third-party code and the following linker directives:

Linker Directives
-----------------
/manifestdependency:"type='win32'
name='Microsoft.VC80.CRT'
version='8.0.50727.762'
processorArchitecture='x86'
publicKeyToken='1fc8b3b9a1e18e3b'"
/DEFAULTLIB:"MSVCRT"
/DEFAULTLIB:"OLDNAMES"

I have had no problem successfully accessing all my .DLL code from within the third-party application, so far. I have been able to access the debug version of my code when running the third-party software to track down coding problems. The only difference from the release version I find when linking the debug version of my .DLL is the warning

Linking...
Creating library Debug/usersub.lib and object Debug/usersub.exp
LINK : warning LNK4098: defaultlib "MSVCRT" conflicts with use of other libs; use /NODEFAULTLIB:library

usersub.dll - 0 error(s), 1 warning(s)

The warning is absent when linking the release configuration. This does not appear to be a deal-breaker, as the debug code runs Ok, but I think it is connected to the precompiled object code.

[mecej4]

There is an article that covers most of your questions. The Dependency Walker tool can be used on your DLL to see which other DLLs need to be redistributed, if you do not wish to use one of the prebuilt redistributable packages provided by Intel. It is easier to satisfy the legal/licensing requirements if the prebuilt distributions are used.

[anthonyrichards]

Thanks. From the POV of making installing an application on a foreign machine easy, the article is not reassuring. What with the various possibilities of win32/win64-bit applications and 32-bit and 64-bit platforms and the need to match redistributable to compiling platform, it all looks pretty daunting.

First of all, since my .DLL is a Win32-bit DLL, I assume it will not work on a WIn64-bit platform. Am I restricted to 32-bit platforms?

Lets suppose I want to copy my .DLL to the third-party's applications directory where it is needed to be accessed. Let's also suppose that the computer does not have any version of Visual Studio or its C++ compiler installed.

If I create a 32-bit version using my present IVF composer XE 2011.5.221 installed into VS2005 Pro version 8.0.50727 with service pack 1 running on my win32 MS XP Pro platform, it appears from the article that I will need to install a distribution pack specifically tailored to that combination PLUS all the MS C++ libraries as installed with VS2005. Is that correct?

Do the redistributable packages differ for Win32 and Win64 applications?

What if the target machine has a different version of Visual Studio + MS C++ installed on it? Would copying over/installation of the redistributable stuff for another version of VS not cause compatibility problems on the target machine?

[Steven_L_Intel1]

32-bit DLLs will work with a 32-bit application on a 64-bit platform. If your code is all 32-bit and you tell your end-users to build for 32-bit, you don't need to worry about 64-bit. There is only one redistributable installer for both 32-bit and 64-bit. As for MSVC, you should also include the MSVC redistributable for the VC version you used. The way the MSVC redistributables work is that they don't interfere with different versions.

We provide a .msm you can include in your installer, as does Microsoft.

[mecej4]

> First of all, since my .DLL is a Win32-bit DLL, I assume it will not work on a
> WIn64-bit platform. Am I restricted to 32-bit platforms?

No. That's the beauty (or curse, depending on your POV) of the AMD64/EM64T architecture. With few exceptions, 32-bit DLLs and 32-bit EXEs will run fine (with almost no execution speed drop) on X86 and X64. With few exceptions, you cannot mix 32-bit and 64-bit objects.

Both Intel and Microsoft make redistributables available. Many commercial applications install the VC redistributables if the PC does not already have them. While this may appear daunting to manage, it works without glitches most of the time. Once in a while, one may run into a need for a specific version of the redistributables, and it can be difficult to hunt down the required obsolete version. However, as a developer all that you have to do is relink your applications with the redistributables library whenever that gets refreshed.

> Do the redistributable packages differ for Win32 and Win64 applications?

Definitely, as to which parts of the redistributables you need to be concerned with. However, if you develop only 32-bit applications, you would be concerned only with the 32-bit components of the redistributables, regardless of whether the development or target machines are running W7-32 or W7-64.

Much of what I wrote may be inapplicable if you are writing device drivers.

[anthonyrichards]

"As for MSVC, you should also include the MSVC redistributable for the VC version you used."

I program only in Fortran. I do not 'use' Visual C++ as such,; only insofar as MS Visual Studio provides links to all the libraries required to run a Win32 application on a Windows platform can I be said to 'use' Visual C++ as I think those libraries were compiled with Visual C++.

Dependency Walker shows that my USERSUB.DLL depends on the following DLL's:

ADVAPI32.DLL
COMCTL32.DLL
COMDLG32.DLL
DFORMD.DLL
GDI32.DLL
KERNEL32.DLL
MSVCRT.DLL
NTDLL.DLL
OLE32.DLL
OLEAUT32.DLL
RPCRT4.DLL
SECUR32.DLL
SHELL32.DLL
SHLWAPI.DLL
USER32.DLL
USERSUB.DLL

from which I detect DFORMD as a CVF DLL and MSVCRT a Visual C++ run-time library, both of which would have to be distributed with my .DLL I think.

I am unfamiliar with RPCRT4.DLL, the rest appear to be standard Windows DLLs.

[mecej4]

Once you complete the porting from CVF to IVF, you should see the dependency on DFORMD replaced by one on LIBIFCOREMD. If you still retain the dependency on DFORMD, that is a sign that you still have some object that was compiled by CVF. If you do not have source code to recompile that object with IVF, that can be troublesome.

[Steven_L_Intel1]

Other than DFORMD, all of those are standard Windows DLLs. On a relink, you will see MSVCRT.DLL go away too, to be replaced by one from the current MSVC version.