Difference between C:\Program Files\Common Files and C:\WINDOWS\System ?

[J. Henning Schwentner]

Hi

If I want to share a DLL between Windows programs, I can put them into
C:\WINDOWS\System (or C:\WINDOWS\System32 on NT). If I start an application
which is linked against a DLL in the system directory, it will find the
DLL automatically. This is similar to /lib and /usr/lib on UNIX.

What is the reason of having a Common Files directory (C:\Program
Files\Common Files)?

How can I tell my app to look in this Common Files directory to find the
DLL's it requires?

Cheers
Henning

--
J. Henning Schwentner
Lanthan Software KG

[Jarmo Muukka]

My personal opinion is that applications SHOULD NOT install
anything to operating system directories. If you have to share
files, please share them in your own folder. So, if you install
application X, you could create directory "Lanthan Software KG"
under "Program Files" (ask the location and the name from OS) and
create X under "Lanthan ...". Shared files to "Shared" under
"Lanthan...". How does OS find these DLLs? If DLLs are loaded
automatically, they should be in PATH (I don't know any other
way). If they are loaded dynamically, then then you can load them
easily. One way is to install them in the same directory with
other program of yours. Then you don't need any mods to OS dirs
and no mods to PATH.

Now to Common Files. I checked my Common Files directory and found
there many DLLs under app specific folders. Then I picked one
mysteriously named DLL and searched it in registry. It was in
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Share
dDLLs. There were a full path of the file a DWORD value of 1. This
means that only one application is using this file. You could add
yours DLLs to this list and increment value when it already exists
and decrement value when uninstalling. When count drops to zero,
you should delete the setting and the file. And does OS find DLLs
from Common Files, if DLL is not in path? Maybe it can. There are
docs on this in the net, I think.

--
JMu

"J. Henning Schwentner" <hschw...@yahoo.com> wrote in message
news:9tj94b$2vnhe$1...@news.hansenet.net...

[Ron Ruble]

J. Henning Schwentner wrote in message <9tj94b$2vnhe$1...@news.hansenet.net>...

>If I want to share a DLL between Windows programs, I can put them into
>C:\WINDOWS\System (or C:\WINDOWS\System32 on NT). If I start an application
>which is linked against a DLL in the system directory, it will find the
>DLL automatically. This is similar to /lib and /usr/lib on UNIX.

This is not magic on either OS; both folders are
in the system path.

>What is the reason of having a Common Files directory (C:\Program
>Files\Common Files)?

Placing application DLLs in the Windows System
folder opens the system up to errors. In order to keep
the system stable, expect future versions of Windows
to make the system folder read-only by default
(Windows 2000 offers this as an administrator option;
of course, it can be done manually in prior NT versions)

>How can I tell my app to look in this Common Files directory to find the
>DLL's it requires?

Step 1: don't place the files in the Common Files folder;
create a subfolder for your applications, and place
the files there.

Step 2: Tell your applications to look in the Common
Files\Your Company Name\ folder for the DLLs.

There are 2 good ways to do this. Read the folder
path, either using the Registry or GetSpecialFolder
or GetSpecialPath APIs, and load the file with the
full path using LoadLibrary. For languages where this
isn't a good option (VB for one), use the
SetEnvironmentVariable API to add this folder to the
application (not system) path, before invoking any
functions within it.

[Jonathan de Boyne Pollard]

JHS> If I want to share a DLL between Windows programs, I can put them
JHS> into C:\WINDOWS\System (or C:\WINDOWS\System32 on NT).

You *can*, but you should not.

<URL:http://homepages.tesco.net./~J.deBoynePollard/FGA/dont-put-your-dll-in-the-system32-directory.html>

[J. Henning Schwentner]

> There are 2 good ways to do this. Read the folder
> path, either using the Registry or GetSpecialFolder
> or GetSpecialPath APIs, and load the file with the
> full path using LoadLibrary. For languages where this
> isn't a good option (VB for one), use the
> SetEnvironmentVariable API to add this folder to the
> application (not system) path, before invoking any
> functions within it.

I think the application should not care where the DLL is (in fact it should
not even care if it _is_ a DLL or statically linked or whatever), but the
OS should. So there must be a way to start application X with a
speciallised path. What is this way on Win32?