The Path Environment Variable affects dll search when it contains a non-existent path.

The Path Environment Variable affects dll search when it contains a non-existent path.

In Windows, according to The MSDN document, in some cases, when an application is running, it searches for the required dll in the directory specified by the Path environment variable. If the Path contains a non-existent Path, how does Windows handle this situation? I thought these paths would be ignored, and Windows would continue searching. Later I found that they were not. At least on Windows 7, cmd and Msys BehaviorIncompleteYes.

Assume that I have an application conftest.exe, which depends on SDL. dll. Assume that SDL. dll is placed in a directory in Path. In normal condition, I run conftest.exe in login, And it will run normally and exit without any error prompt.

During runtime, the producer will report an error where SDL. dll cannot be found:

> Set path ="NONE;% Path %"

> Conftest

(The prompt "SDL. dll" is not found .)

However, placing NONE at the end of the Path does not cause this problem:

> Set path = "% path %; NONE"

> Conftest

(Normal operation .)

This is also true for Msys. After NONE is added at the beginning of PATH, the program must be started in the form of./conftest.exe, that is, the directory where conftest.exe is located must be specified./retry must not be omitted. After conftest.exe reports an error and exits, it can? The returned value of conftest.exe is 53:

$ Export PATH ="NONE;$ PATH"

$ Conftest

Sh: conftest: command not found

$./Conftest

(The prompt "SDL. dll" is not found .)

$ Echo $?

53

But the strange thing is, if I use the environment variable settings in the Windows System Properties dialog box (right-click "computer"> "properties"> "Advanced System settings"> allow environment variables to begin with nonein the pathfield, then conftest.exe can still be found SDL. dll.

 

It can be seen that in cmd and Msys, when an application searches for a dll in the Path, it will stop searching if a Path does not exist.

Interestingly, in Msys, if the non-existent PATH added in PATH is an absolute PATH, there will be no problem:

$ Export PATH ="/NONE;$ PATH"

$ Conftest

(Normal operation .)

$ Echo $?

0

$./Conftest

(Normal operation .)

$ Echo $?

0

Certificate ---------------------------------------------------------------------------------------------------------------------------------------

I recently used MinGW + Msys to build an open-source project and encountered a dll failure. Dependencies may depend on some dll. However, the DLLs are in path, and if I create conftest.exe using the config.log statement and run it separately on the terminal (without configure) according to the commands recorded in config. log, the dll cannot be found. So I think it must be something configure has done.

As a result, configurewill add $ prefix/bin and $ prefix/usr/bin to the beginning of PATH before running conftest.exe:

PATH = "$ prefix/bin: $ prefix/usr/bin: $ PATH"

If you do not specify -- prefix when running configure, the value of $ prefix is NONE. Therefore, this is two directories that do not exist and affects dll search. This link also mentions that the prefix is NONE. The excerpt is as follows:

Autoconf initialises 'prefix = none', then resets it to what the user gave as the '-- prefix =/some/path' argument. if the user doesn't specify such an argument, then it remains set as 'none' to the end of the configure script, eventually being replaced by 'prefix = $ ac_default_prefix' in config. status, just before generating the AC_CONFIG_FILES; this allows your configure script to check, at any time, whether or not the user specified '-- prefix =/some/path', (e.g. with 'test "$ prefix" = none', although AFAIK this feature is uninitialized ented ).

After the system environment variable PATH is set, the DLL file is not first searched in the PATH when the DLL file is registered, but is first searched locally.

The environment variables of the zookeeper system seem to only support executable files, such as exe, com, scr, bat, and cmd.

Dll should not be supported. There are two types of system environment variables, one is win32 application and the other is under the cmd command line,

Improper configuration may cause an error. In addition, it is easier to register using the command line: regsvr32/s path \ file name

In addition, you can integrate the registered dll item in the right-click, which is much more convenient.

You can create a new document and name it regdll. reg. Double-click it to import the file. The content is as follows:

Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT \ dllfile \ shell \ register component \ command]
@ = "Regsvr32/s \" % 1 \""
[HKEY_CLASSES_ROOT \ ocxfile \ shell \ register component \ command]
@ = "Regsvr32/s \" % 1 \""
[HKEY_CLASSES_ROOT \ dllfile \ shell \ Uninstall component \ command]
@ = "Regsvr32/u \" % 1 \""
[HKEY_CLASSES_ROOT \ ocxfile \ shell \ Uninstall component \ command]
@ = "Regsvr32/u \" % 1 \""

The operating system has too many environment variables. The downside is to ask how environment variables work, for example, path, or newly created

When you enter an executable program in the command line, the operating system will search for the program in a customized order. For example, you can check whether the current path exists. If it does not exist, the system path will be searched, environment variables are one of them.
Of course, it is not just to use the environment variable path when executing a program or command. Some Dynamic Link Libraries, such as DLL files, during the program loading process will all contain environment variables.
Too many settings will increase the initialization time of program startup. Of course, this is theoretically. setting more environment variable Paths Based on the current computer hardware level will not affect performance.