distribution of a self-made DLL made in Visual Studio Professional 2017 with FORTRAN (Intel Parallel Studio XE 2018 Prof.)

[Schwandt__Olaf]

Hi all (and Steve, if he is still here and read this),

that question is independent from my last question.

My students and I are using a program to calculate energy balances and the like. The functionality of this program can be extended by own functions.

For this I write such functions, which are compiled as a DLL. The DLLs I distribute. And for most of the students, it works without any problem. But for some students (on some computers) the DLL is shown as not be found. In that cases I distribute all DLLs to, which are shown in the dependency walker as used in my DLL.

That are (maybe it can be useful to know):

bcryptprimitives.dll
cfgmgr32.dll
cryptbase.dll
dbghelp.dll
devobj.dll
devrtl.dll
dhcpcsvc.dll
dhcpcsvc6.dll
dnsapi.dll
imagehlp.dll
IPHLPAPI.DLL
kernel32.dll
KernelBase.dll
nsi.dll
ntdll.dll
rpcrt4.dll
sspicli.dll
winnsi.dll

(The use of some of these DLLs I do not understand in this context.)

But the real question is, what the students can do that they can use my DLL. Do anyone help?

Olaf

[N_Netto]

You probably just need to pack the visual studio redistributable ( https://support.microsoft.com/en-gb/help/2977003/the-latest-supported-visual-c-downloads ) with your own dll.

 

[Schwandt__Olaf]

Hi Nicolas,

yes, thats a good idea. I will try. Your link is to a c++ redistributable. Is there a redistributable for FORTRAN to?

Greetings, Olaf

[mecej4]

https://software.intel.com/en-us/articles/redistributable-libraries-for-intel-c-and-fortran-2020-compilers-for-windows

[jimdempseyatthecove]

The MS Windows DLLs (e.g. kernel32.dll, ntdll.dll, etc...) should not be distributed with your program. They should be present on every Windows system *** The students may have different versions of MS Windows than your development system.

Jim Dempsey

[Steve_Lionel]

I agree that all you should need are the MSVC and Intel compiler redistributables. Both are available in EXE installers and MSP packages that can be bundled into your own installer.

[Schwandt__Olaf]

Hi Jim,

yes, I replace only not already existing files. I don't touch existing files.

Olaf

[Schwandt__Olaf]

Hi Steve,

(nice to see you again by the way),

ok I 'll try it with the redistributables.

And your rule is helpful.

Olaf

[Steve_Lionel]

A good rule - never ever replace or add files that go under the Windows top-level folder.

[Schwandt__Olaf]

Hi mecej4,

thank you for the link.

Olaf

[jimdempseyatthecove]

>>yes, I replace only not already existing files. I don't touch existing files

A "standard" practice is to install the required DLLs into the same folder as the execuitable, or into a user folder in PATH. Attempting to copy the Windows DLLs into either folder will not yield a "Replace...". It is strongly recommended that you do not mix one version of a Windows DLL with another version.

You should never install your DLL into System32 or elsewhere in the Windows folders.

Jim Dempsey

[Schwandt__Olaf]

Hi Jim,

Thank you, yes I do. But it's annoying, the fuzzy situation is typical for Microsoft

Olaf