1

I have an (PowerBuilder) application (let's call it MyApp.exe) in a folder with a sub-directory that has all the required dlls. I am able to run this application, by adding the application path and associated path variable to Windows App Paths registry key.

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\App Paths\MyApp.EXE] "Path"="C:\\Prog32\\MyAPP;C:\\Prog32\\MyAPP\\DLL\\;" @="C:\\Prog32\\MyApp\\MyApp.EXE"

The above runs file. I didn't even have to register DLLs.

If possible, I would like to run it using a batch file though, as users may install multiple versions of the same application in separate folders. When I tried to do the same thing in a batch file, it cannot find the DLLs.

@SETLOCAL SET CURDIR=%~dp0 CD %CURDIR% PUSHD %CURDIR% SET PATH=%CURDIR%;%CURDIR%\dll;%PATH% start "" %CURDIR%\myApp.exe POPD ENDLOCAL

I created this batch in the same directory as the executable, MyApp.exe. I was expecting it would find the DLLs, same way App Paths PATH setting did. The Batch file errors out not being able to find the DLLs. Do we need to register DLLs in this case? Why is it treated differently?

Notes:

  1. If I copied all the required DLLs to the same directory as the executable (without a DLL sub-directory), it runs fine without needing to worry about PATH or registering dlls.

  2. We used to use installShield to install before, but admins have automated scripts to copy files, they shied away from InstallShield programs after the first install. I am trying to refine the process, so what they copy will be simplified.

Thanks in advance for all your valuable comments and suggestions.-Sam

Improve this question

2 Answers 2

Reset to default
1

Why is it treated differently?

Because Windows is a mess when searching for libraries. See http://msdn.microsoft.com/en-us/library/windows/desktop/ms682586.aspx#search_order_for_desktop_applications

There are many elements to how the search order is determined, but in general it is like this

Check for the library...

  1. already loaded in memory
  2. on the KnownDLL list
  3. in the application's directory
  4. in the System directory
  5. in the 16-bit System directory
  6. in the Windows directory
  7. in the current working directory
  8. in the directories listed in the PATH environment variable

Overall I would agree with what MSDN states on their DLL Redirection page

It is good practice to install application DLLs in the same directory that contains the application

However, if using sub-folders is how you want to organize your application, you might take a look into using Application Manifests. Something else to try would be to set the library directory as the working directory

@ECHO off SETLOCAL SET "CURDIR=%~dp0" PUSHD "%CURDIR%\dll" start "" /D "%CURDIR%\dll" "%CURDIR%\myApp.exe" POPD ENDLOCAL
Improve this answer
Sign up to request clarification or add additional context in comments.

3 Comments

Thank you, David. You gave me a lot to work with. This is an old PB application we are bringing into the new (Windows) world. With so many choices, I wanted to see the best practice. The only reason, I didn't want to copy the DLLs to the same directory was to avoid clutter. I will explore that option as well. In my batch file, I was adding the DLL directory to the local path, that didn't work. Your suggested batch file fix works!! So, the key, I guess is to copy the DLLs to the app directory or make it current directory. Thanks for the links too.
Can you also please explain, if adding a registry entry to "App Paths" fit into any of these? Or is it being obsoleted in new windows? Thanks again!
From the App Path Documentation it would seem that the intended purpose of the Path entry is to prepend the PATH environment variable with the application's path. "It is the fully qualified path to the .exe." And in regards to the library search, number 8, "Note that this does not include the per-application path specified by the App Paths registry key. The App Paths key is not used when computing the DLL search path." Yet, this is contrary to the results you experienced above. Might be something missing from MSDN docs.
0

Changing the local Environment Variable %PATH% has no effect on any other process, not even a process that you load and execute from that command shell.

The process "start" is a partial exception: by default it copies the current copy of %PATH% from it's current environment. The new console process has the same %PATH%. But even so, no process started in that environment inherits the %PATH% from the environment: each new process gets it's version of 'path' from the registry.

There is a solution: "setx". SETX is the windows command that changes the actual path value, rather than just changing the local environment variable.

Improve this answer

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.