From Jean-Sebastien Guay,"As discussed yesterday on the osg-users list, I have altered src/osgDB/FileUtils.cpp to implement the official Windows DLL search order as described on the page http://msdn2.microsoft.com/en-us/library/ms682586.aspx . As mentioned, the search order is now:     1. The directory from which the application loaded.     2. The system directory. (C:\Windows\System32 by default, gotten using the        GetSystemDirectory function)     3. The 16-bit system directory. (C:\Windows\System by default, gotten by        adding "\System" to the path gotten in the next step...)     4. The Windows directory. (C:\Windows by default, gotten using the        GetWindowsDirectory function)     5. The current directory. (".")     6. The directories that are listed in the PATH environment variable. (as        before)
From Jean-Sebastien Guay,"As discussed yesterday on the osg-users list, I have altered
src/osgDB/FileUtils.cpp to implement the official Windows DLL search
order as described on the page
http://msdn2.microsoft.com/en-us/library/ms682586.aspx . As mentioned,
the search order is now:
    1. The directory from which the application loaded.
    2. The system directory. (C:\Windows\System32 by default, gotten using the
       GetSystemDirectory function)
    3. The 16-bit system directory. (C:\Windows\System by default, gotten by
       adding "\System" to the path gotten in the next step...)
    4. The Windows directory. (C:\Windows by default, gotten using the
       GetWindowsDirectory function)
    5. The current directory. (".")
    6. The directories that are listed in the PATH environment variable. (as
       before)

The first four directories are obtained using Win32 API calls, so they
should work correctly even on non-standard Windows installs.

The changes are well commented and should be clear, even to someone
not familiar with the Win32 API.

I have tested in a few scenarios and it works as expected. Serge Lages
has also tested the changes and confirmed they worked as described. I
have not had any other reports though (positive or negative).

I also fixed the issue with a trailing semicolon on the PATH adding an
empty string to the end of the search paths, as this was an
inconsistent side effect rather than a desirable effect. This change
will take effect on other platforms as well, but since it tests for an
empty string in the last item added to the search paths, it should
have no adverse effect.
"


git-svn-id: 23b6355f2bb369032457de4eb5f713ee134f73a8@7276 16af8721-9629-0410-8352-f15c8da7e697

joevandyk/osg,joevandyk/osg,joevandyk/osg,joevandyk/osg,joevandyk/osg