><<< There is no reason that a DLL HAS to be in the system directory. As longs <<< as, if it is COM it is registered, or if it is C-API it is in the current <<< directory or DOS path. I think this even includes network drives. Give it a <<< try.
>
>So let me see if I got this right... (and please correct me if I'm wrong.)
>
>For reference, I'm making all my calls to the advapi32.dll file.
>
>In my creation of a setup/install program, the system included about 5 DLLs and the executable which I created. If I create a directory on the network and place all the files there, any user that has access to that directory can run the EXE from that directory without having to install the DLLS on their system?
>
>Man if that's right, that's cooooool....
>

Unfortunately, that's not correct for several reasons.

First, some of the .DLLs may require registration. While you can register an OLE-enabled .DLL on the network, the problems that can result are bad - if you use a mapped drive for registration, then that mapping must always exist when you need to access the .DLL. For example, if you register something using a mapped drive, and the next time you run, the mapping has changed to point to a different network resource, things are broken.

Second, some of the .DLLs may be shared system components already present on the user's system (for example, some of the MSVCRT family .DLLs). If the .DLL already present on the system is an earlier version, but it's already loaded into memory, you're going to end up accessing the wrong version, and its going to be very difficult to track down why the app intermittently breaks; it often appears that if you start application "A" before your app, your app doesn't behave as expected, or worse, if the version on the user's system is newer than the one you distribute, if your app is loaded before "A", the other app fails in new and interesting ways...

Third, there are differences in some of the shared components used in different operating system versions; for example, NETAPI32.DLL exists under both Win9x and WinNT, but in spite of having the same name, they behave very differently between the two versions. There's no mechanism with the common network directory approach to make allowance for OS-specific requirements.

Fourth, there are minor performance differences when the runtime support files for VFP are located on the network, especially when the network gets busy.

Then you get into the question of where are my temporary files placed. You can direct them using entries in the CONFIG.FPW (either embedded in the executable, or in the startup directory, or specified by the -C command line switch), but if nothing is specified, the default location used is the startup directory on the network, which has a definite performance impact. Unless you point to a location that's known to be a safe work place on each system (do yourself a favor and don't use the root of a local drive; with FAT, there are limits on the number of directory entries in the root of a drive), you may find yourself unable to start the app or complete operations that require temporary files.

The more you look, the worse it gets. Do yourself a favor and install the common system components and runtime libraries locally; if you want to have a single copy of the executable on the network, fine (my preference is to use a launcher app that copies down the most current executable at startup if the one on the net is newer than the one on my local drive). There are too many things that can go wrong just dumping the .DLLs into the network directory and hoping it works right.
>Thanks for your help...
>
>Michael