Prevent loading of a local *.dll

[romk]

I believe my question is very specific, as I was not able to find anything related to it.

As far as I understood, DLLs are being imported on the very beginning of the compiled code, first checking in the local directory and then in the path variable directories. For my situation I need the executable to NOT check in the local directory, as there is a DLL with the same name but a different purpose (it is used by for another application which is located in the same directory).

The DLL of interest is wsock32.dll. Everything works fine as long as the "wrong" DLL is not in the same folder as my executable. When it is, the following critical error occurs instantly when I start the executable, even before doing anything:

Procedure entry point "select" could not be located in "WSOCK32.DLL".

It would be really nice if there was some compiler/linker parameter, custom import code or another workaround for this.

Thanks in advance!

[skywalk]

Code: Select all

#my_DLL_PATH$ = "c:\myDLLs\"
#my_DLL_NAME$ = "wSock32.dll"
mydll = OpenLibrary(#PB_Any, #my_DLL_PATH$ + #my_DLL_NAME$)

[romk]

I already tried this in form of

Code: Select all

OpenLibrary(#PB_Any, "C:\windows\system32\wsock32.dll")

but it still does not prevent the program too look it up in its local directory.

[PB]

> I need the executable to NOT check in the local directory, as there is a DLL with the same name
> but a different purpose (it is used by for another application which is located in the same directory)

So, the question really is: why are two different apps installed to the same directory?

And the easiest way to fix your problem: install your app into its own unique directory.

[Shield]

If you use the WinAPI functions (i.e. LoadLibraryEx_()) you can specify what system folders shall be searched.
It's probably the only way as OpenLibrary() goes with default behavior.

[romk]

So, the question really is: why are two different apps installed to the same directory?

And the easiest way to fix your problem: install your app into its own unique directory.

That is for a reason. The other application is being updated and launched by my program. For the sake of simplicity it's better to have your application and its updater in the same folder, as most of constantly patched software does the same. I'd rather separate the two executables only if there is absolutely no other way.

If you use the WinAPI functions (i.e. LoadLibraryEx_()) you can specify what system folders shall be searched.
It's probably the only way as OpenLibrary() goes with default behavior.

I don't have any experience with WinAPI functions at all. I could not find a tutorial that is comprehensive or generic and not being confusing. Would you mind showing me your solution? I'd appreciate it!

[smacker]

So, the question really is: why are two different apps installed to the same directory?

And the easiest way to fix your problem: install your app into its own unique directory.

That is for a reason. The other application is being updated and launched by my program. For the sake of simplicity it's better to have your application and its updater in the same folder, as most of constantly patched software does the same. I'd rather separate the two executables only if there is absolutely no other way.

If you use the WinAPI functions (i.e. LoadLibraryEx_()) you can specify what system folders shall be searched.
It's probably the only way as OpenLibrary() goes with default behavior.

I don't have any experience with WinAPI functions at all. I could not find a tutorial that is comprehensive or generic and not being confusing. Would you mind showing me your solution? I'd appreciate it!

I think this is what he was talking about

Code: Select all

LoadLibraryEx_()
  
  resourceDLLname.s = "C:\windows\system32\wsock32.dll"
  
  LoadLibraryEx_(@resourceDLLname, #Null, #LOAD_LIBRARY_SEARCH_DLL_LOAD_DIR) ; but don't use this example with the #LOAD_LIBRARY_SEARCH_DLL_LOAD_DIR flag as the the following two are better probably for your needs
  
  ... Or to just search in your C:\windows\system32\ directory :
  
  resourceDLLname.s = "wsock32.dll"
  LoadLibraryEx_(@resourceDLLname, #Null, #LOAD_LIBRARY_SEARCH_SYSTEM32)
  
  
  Or... you can also just use LoadLibrary(...) ... which does the same thing As LoadLibraryEx_(...) with the #LOAD_LIBRARY_SEARCH_SYSTEM32 flag :
  
  
  resourceDLLname.s = "C:\windows\system32\wsock32.dll"
  LoadLibrary_(@resourceDLLname)

either one of those, they will load from where directed either by your path with the .dll file name or with LoadLibraryEx(...) by use of the #LOAD_LIBRARY_SEARCH_SYSTEM32 flag. However, use the second or third examples as they are probably what you would use. The first one isn;t so good all around because Windows 7, Windows Server 2008 R2, Windows Vista, and Windows Server 2008 requires KB2533623 to be installed to use that first one (and its not support at all on Windows Server 2003 and Windows XP) and you'd really only want to use that first example when you have .dll's to load outside of the normal search path like C:\windows\system32.

see > http://msdn.microsoft.com/en-us/library ... 85%29.aspx

[romk]

I tested that one with both LoadLibrary_() and LoadLibraryEx_(), without success. The error still occurs.

But I found an interesting Function documented in MSDN: SetSearchPathMode. The pages about LoadLibrary_() and LoadLibraryEx_() both hyperlinked me there. Unfortunately PB does not recognize

Code: Select all

SetSearchPathMode_(#WHATEVS)

when trying to compile.

[skywalk]

If you use the WinAPI functions (i.e. LoadLibraryEx_()) you can specify what system folders shall be searched.
It's probably the only way as OpenLibrary() goes with default behavior.

Are you saying the PB doc's are wrong?

Result = OpenLibrary(#Library, Filename$)
Description
Opens a shared library in order that the functions within it may be accessed.
Parameters

#Library A number to identify this library. #PB_Any can be used to auto-generate this number.
Filename$ The filename of the library to load. If the filename does not include a path, then the operating system will search for the library in its system folders, the applications directory and the current directory.

[romk]

Are you saying the PB doc's are wrong?

Result = OpenLibrary(#Library, Filename$)
Description
Opens a shared library in order that the functions within it may be accessed.
Parameters

#Library A number to identify this library. #PB_Any can be used to auto-generate this number.
Filename$ The filename of the library to load. If the filename does not include a path, then the operating system will search for the library in its system folders, the applications directory and the current directory.

Well, I can clearly see the behaviour, that the error occurs as soon as I place the "wrong" wsock32.dll in the same folder and execute my program, no matter if this line is on top of my code or not:

Code: Select all

OpenLibrary(#PB_Any,"C:\windows\system32\wSock32.dll")

So either the PB's docs might be wrong, or I am missing something, or the explanation in the docs was somehow terribly misunderstood.

[Thunder93]

With PB 5.31 x64 & x86 I specified path to the system folder and using bogus / not existing file. However the file exists in the executable location. Testing, the DLL file with the executable is never used.


Information seen in PB doc about OpenLibrary filename$ parameter. Is completely observed behaviour. Specify the path or you'll see it test out the application and current directory after system folders if the file is hard to find.

[Shield]

Are you saying the PB doc's are wrong?

No. I'm saying the PB functions work according to the default behavior of LoadLibrary_(),
which is not what the OP wants apparently.

[romk]

With PB 5.31 x64 & x86 I specified path to the system folder and using bogus / not existing file. However the file exists in the executable location. Testing, the DLL file with the executable is never used.


Information seen in PB doc about OpenLibrary filename$ parameter. Is completely observed behaviour. Specify the path or you'll see it test out the application and current directory after system folders if the file is hard to find.

I don't understand entirely... does that mean that OpenLibrary() searches first in the specified path, if a path is specified? If so, then OpenLibrary() is not working as it should in the given circumstances, as I mentioned in my last post.
~~~~~~~~~~~~~~~~~~~~~

Are you saying the PB doc's are wrong?

No. I'm saying the PB functions work according to the default behavior of LoadLibrary_(),
which is not what the OP wants apparently.

Is there a possibility to alter the behaviour of LoadLibrary_() ?
I tried out the following, but the behaviour stayed the same:

Code: Select all

#BASE_SEARCH_PATH_ENABLE_SAFE_SEARCHMODE  = $00001
#BASE_SEARCH_PATH_DISABLE_SAFE_SEARCHMODE = $10000
#BASE_SEARCH_PATH_PERMANENT               = $08000

Prototype SetSearchPathMode(flag.l)

Define DLL = OpenLibrary(#PB_Any, "Kernel32.dll")
If DLL
  Define SetSearchPathMode.SetSearchPathMode = GetFunction(DLL, "SetSearchPathMode")
  If SetSearchPathMode <> 0
    SetSearchPathMode(#BASE_SEARCH_PATH_ENABLE_SAFE_SEARCHMODE)
  EndIf
EndIf

~~~~~~~~~~~~~~~~~~~~~
Also, I read that the paths for external libraries are being read from IAT, and I thought about altering it, if that's possible?

[Shield]

This might be a reason (not 100% sure what MSDN means exactly):

If a DLL with the same module name is already loaded in memory,
the system checks only for redirection and a manifest before resolving to the loaded DLL,
no matter which directory it is in. The system does not search for the DLL.

I don't have PB at hand right now, so I can't test it yet.

Edit: hm, nvm, it shouldn't have any effect as it's a separate process.

[Thunder93]

Specify the path or you'll see it test out....