I think that sorry if things is usually handled in an “Application Manifest” on Windows
https://docs.microsoft.com/en-us/windows/win32/sbscs/application-manifests Scott > On May 12, 2020, at 8:33 AM, Kevin Rushforth <kevin.rushfo...@oracle.com> > wrote: > > Is there a way you can link the launcher (e.g., something similar to RPATH > on Unix systems) to look in the right place relative to the launcher? > Otherwise, the solution with adding to the PATH seems OK to me. > > -- Kevin > > >> On 5/12/2020 5:22 AM, Andy Herrick wrote: >> Is the problem that by removing the copy of the microsoft dlls from the >> applications bin directory, then on machines that do not have all of these >> dll's already in the PATH (usually in C:\windows\system32) they can no >> longer be found ? >> >> I don't like manually manipulating the PATH env variable either, but if so I >> don't see what else can be done short of putting the app exe in the bin dir >> of the runtime. >> >> /Andy >> >> >>> On 5/11/2020 9:37 PM, Alexander Matveev wrote: >>> Hi Alexey, >>> >>> Updating PATH does not look like good solution to me. Did you try to load >>> jli.dll by specifying full path to jli.dll when calling LoadLibary? If it >>> does not work, then for AddDllDirectory() did you used LoadLibrary() or >>> LoadLibraryEx() with LOAD_LIBRARY_SEARCH_USER_DIRS? According to doc you >>> need to use LoadLibraryEx() with flag when using AddDllDirectory(). >>> >>> Thanks, >>> Alexander >>> >>> On 5/11/2020 4:36 PM, Alexey Semenyuk wrote: >>>> Please review fix [2] for jpackage bug [1]. >>>> >>>> Fix failure to load jli.dll from app launcher. The fix is to append path >>>> to directory with jli.dll to PATH env variable and load jli.dll with >>>> altered value of PATH if the first attempt to load jli.dll without >>>> altering PATH fails. >>>> >>>> - Alexey >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8244634 >>>> >>>> [2] http://cr.openjdk.java.net/~asemenyuk/8244634/webrev.00 >>>> >>> >
