Dlls in subfolder?

You can use the win32 API; FindFirstFile:

Sample

void PluginLoader::LoadDllsFromDir( LPTSTR lpszDllPath )
{
WIN32_FIND_DATA findData = {0};
HANDLE hFind = 0;
int iCount = 0;
TCHAR szCurrent[_MAX_PATH];
string strDirectory;

// Remember current directory for restoring later
::GetCurrentDirectory( sizeof( szCurrent ) / sizeof( TCHAR ), szCurrent );

// Change to DLL directory (absolute path!)
::SetCurrentDirectory( lpszDllPath );

// Start searching for DLL's
hFind = ::FindFirstFile( "*.dll", &findData );
if( hFind != INVALID_HANDLE_VALUE )
{
do
{
// TODO: Do something with found files as you encounter them:
findData.cFileName;
}
while( FindNextFile( hFind, &findData ) );

// Stop searching
::FindClose( hFind );
}

// Restore current directory and exit
::SetCurrentDirectory( szCurrent );
}

Hope this helps.

When you say "app searches for them in sub-folder" do you mean that the app should load the dlls from those location ?

What kind of loading do you use, do you use LoadLibrary to explicitly load them or are they implicitly linked to the app ( which means windows looks for those dlls when the app is launched )?

DLL search order is like this:

1. The directory from which the application loaded.
2. The current directory.
3. The system directory. Use the GetSystemDirectory function to get the path of this directory.
4. The 16-bit system directory. There is no function that obtains the path of this directory, but it is searched.

Windows Me/98/95: This directory does not exist.

5. The Windows directory. Use the GetWindowsDirectory function to get the path of this directory.
6. The directories that are listed in the PATH environment variable.

So, you are left essentially with changing the PATH var.

Why not just put them in a folder that Windows searches anyway (e.g. the System folder) ?

To add to my previous post...

Just write an app that calls CreateProcess (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/createprocess.asp) on your real app. One of the params is a pointer to an environment. You can read the PATH in the current env; modify it; pass it to CreateProcess to launch your real app.

Viggy

Hi Viggy & Kirants

Cram that system folder full of DLL's - that's my philosophy! :D

Admittedly tho' - my DLL's do get deleted whenever my apps get uninstalled...!

MSDN:

Registering Application Path Information

The system supports "per application" paths. If you register a path, Windows sets the PATH environment variable to be the registered path when it starts your application. You set your application's path in the AppPaths subkey under the HKEY_LOCAL_MACHINE key. Create a new key using your application's executable file name as its name. Set this key's default value to the path of your executable file. The system uses this entry to locate your application if it fails to find it in the current path for example, if the user chooses the Run command on the Start menu and includes only the file name of the application, or if a shortcut icon doesn't include a path setting. To identify the location of .dll files placed in a separate folder, you can also include another value entry called Path and set its value to the path of your .dll files, as follows:

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\App Paths

Application Executable Filename = path
Path = path

The system will automatically update the path and default entries if the user moves or renames the application's executable file using the system shell user interface.