Why should I copy a compiled CVI DLL into the System32 folder?

[Scott Youngren]

Hi

I have been letting the CVI compiler copy a DLL (project) into the windows\System32 folder.

This was primarily to let more than 1 other CVI executables, installed into different folders under \Program Files\

find and share this DLL code.

Also, when building the distribution kit for the DLL, I directed the DLL to be installed in the System32 folder.

When presenting this concept in a review to another software engineers, one engineer felt that the System32 folder should be reserved for windows, computer hardware drivers, etc. My CVI DLL should reside in the working folder of the associated main executable, or some other location. His concerns were un-install and updating processes and if the DLL were in a location specified by the Installer, it would be easier to keep track of, etc.

I am assuming that NI recommends CVI option to  "COPY TO \Windows\System32 folder". Why?

Does my fellow software engineer need some friendly advice?

[BTW, he has used NI CVI on occasion, mostly using other languages]

thanks ALL

Scott Youngren using CVI 8.1.x

[ebalci · Accepted solution]

Hi Scott,

Even we are aware of them or not, most programs use System32 as their DLL destination.

I would not bother myself too much about that.

Have you seen this document?

You can settle on another location and use the PATH environment variable in case you cannot convince System32 is ok.

[markus kossmann]

System32 is one of the directories, which is guarenteed to be searched by Windows when it looks for that  DLL. Have a look at MSDN for more info. If there is another solution that guarantees that for you, you are free to use it 

[LuisG]

Hi Scott,

NI doesn't necessarily recommend that you copy your DLL to the system folder. NI also doesn't recommend that you don't. I'm not aware of a recommendation of either option.

If this DLL is intended to be shared by multiple applications, another option you might want to consider is to install the DLL (plus any support files) to some dedicated directory, and register its location in the system registry. Then, the clients can read this location and build an absolute path, which they pass to LoadLibrary.

Luis

[menchar]

NI actually recommends saving the DLL in the .exe folder as I recall, it's in the help somewhere ... but then it's not shared, is it, which is something of the point of DLL's in the first place ...

Micro$oft has messed with the LoadLibrary search path and mechanism time and again.  With side-by-side assemblies and manifests, the DLL search path is even more arcane.  Microsoft has dickered with the load path due to hacking vulnerabilities and DLL hell I think.  There's a "safe" DLL load search path and an "unsafe" search path even.   "dot local" redirection is possible too.  Manifests can specify a "private path".  What a mess -

Here's a problem with not putting a CVI created DLL in the system folder (WINDOWS\system32 on an XP machine).

I created a DLL for use with VB6, including a type library.

I deployed it to a dedicated folder, off the DLL load search path (off of any of them, for any OS / version / safe /unsafe, etc.) .

I added it to the VB6 project as a reference, and VB6 is quite happy with it, showing the path to the DLL in its dedicated folder.  When I type in a function name in VB I get syntax-directed prompt for parameters, etc.

BUT ....

When I go to run the application, Visual Studio says it cannot find the DLL !

The only way Visual Studio can find the DLL at execution time, despite knowing where it is as a reference, is if it's on the DLL load search path!

So, I put it in the only folder guaranteed to always be on the DLL load search path, the system folder.

Menchar

[Scott Youngren]

Kudos and thank you ALL respondants for excellent replies!

After reading the suggested links, this windows programming novice has learned quite a bit from this topic.

I am now armed with material for further review.

Our group needs to come to an agreeable framework/process for others to follow.

I won't be there forever! (retirement?)

Scott Youngren