Wierd issue wiht NSIS 3.0 and System::Call

Hi,

I have an installer which launches a DLL method using System::Call.
System::Call "MyDll::MyFunc(m '$1') i.r2"

with NSIS 3.0 beta-0 and with NSIS 2, it ran flawlessly for years...
Recently we've upgraded to v.3.0 and boom - this call fails and puts the simple error value in $2: 'error'

Was there any change with System::Call? is it a known issue?
I don't know where to get additional info about this error.

Thanks in Advance

System::Call itself did not change much IIRC but there are new restrictions on which libraries can be loaded into the process. (This also applies to NSIS v2.5x)

Does your .dll depend on msvcrt or other non-system libraries that you extract to $pluginsdir? If so you can try this:

Function .onInit
Initpluginsdir
System::Call 'KERNEL32::AddDllDirectory(w "$pluginsdir")' 
FunctionEnd 

Hi Anders - Thanks for your reply.

The dll has all its dependencies in its directory. I don't extract anything to $pluginsdir.
I've tried adding its directory as you suggested:
System::Call 'KERNEL32::AddDllDirectory(w "c:\MyDir\")'

This time i get error -2817
which is a progress. At least I don't get "error"...

By the way, is there any documentation for this new requirement?
Maybe i'm doing something wrong?

thanks,
yaniv

Originally Posted by yanivsag View Post

The dll has all its dependencies in its directory.

And which directory is that? $InstDir?

I don't think -2817 is a Windows error code. What does your dll function actually return? GetLastError()? Custom codes?

The new requirement is, you can only load relative .dlls from %windir%\system32 by default. Other directories have to be added with AddDllDirectory.

OK thanks.
This DLL is something that is installed in the system in its own directory (my installer assumes it's there, or fails if it doesn't).
The error indeed seems like something coming from the DLL, but it doesn't occur with NSIS 3 beta 0. I've contacted the DLL writer for help in parallel.

the strange thing is that i also have a call to my own dll in instdir and it works with no issue, even without calling AddDllDirectory.

Hi,
it appears that it doesn't find files in the system32 dir, e.g. netapi32, msvcr100 and others.

is there anyway to force that this directory would be searched?
thanks,
yaniv

netapi32 should not be a problem but msvcr* probably is. NSIS uses LOAD_LIBRARY_SEARCH_SYSTEM32 so normal Windows libraries should always work.

You can add the directory your .dll is in with AddDllDirectory but unless you put msvcr* in there as well it is probably not going to work.

Another way around this is for the person that creates the .dll to statically link to the CRT so you don't depend on external msvcr* files. (/MT)

You can call LoadLibrary on anything if you provide a full path, the restrictions are on relative paths and on .dll dependencies.

The msvcr* files are also in the system32 dir.
for some reason - the DLL my script is calling can't find them when it's launched from v3 due to the recent change. (i've checked using procmon from sysinternals)

I'll contact the DLL writers but it still seems strange to modify something that was working for years into something that is not easily configurable.

msvcr* might be using WinSxS or something like that and they are not Windows system files, they belong to Visual Studio.

The behavior was changed to fix a security issue.

Ok, thank you. I will try to distribute msvc*

Originally Posted by yanivsag View Post

Ok, thank you. I will try to distribute msvc*

Depending on the VS version you might be able to put the msvc* files in the same directory as your .dll as long as you call AddDllDirectory but all of these problems go away if you just statically link. You could also create a little helper application if you are unable to change the .dll.

Excellent,
That was exactly what I thought of doing buy will also check putting msvc*just to know if it works...

Many thanks