%_sb_errorcode% = -1

What does that mean (%_SB_ERRORCODE% = -1) when attempting to call a
function in a support dll.

Bad Jeff was calling a dll, but not checking %_SB_ERRORCODE%
afterwards.

I just assumed that someone would yell at me if there was a problem,
but it was a silent sort of yell. Funny how theories are defeated when
you read the documentation.

This is a fairly consistant problem, but only on certain machines, but
I don't know the common obstacle yet.

The support file does get extracted, and it definitely resides inside
%TMPDIR%.


Jeff Slarve

Okay, I suspect new dependencies in the support dll. Will report back,
if that's not it. But I'm guessing it is.

Jeff Slarve

Hi Jeff,

> Okay, I suspect new dependencies in the support dll. Will report back,
> if that's not it. But I'm guessing it is.

Yes, I think it's a missing dependency. It's also possible that 1.) it's
caused by "DLL file not found" or 2.) "DLL function not found". Error -1 is
returned if the LoadLibrary API failed.

Friedrich

Thanks Friedrich -

What would you suggest that I do in this case:

1. I have a support dll that has (linked in, not dynamic) dependencies
on LSPUZIP.DLL and LSPZIP.DLL
2. In my "support files" section on my SB7 project, I have my dll and
the 2 LSZip files.
3. On a "virgin" machine, when I run my setup, I can see via procmon
that it's looking for these LSZip files on various points of my system
path, but not in the %TMPDIR% folder where the support DLL was loaded
from (and the files exist).

How do I force my DLL to find it's dependencies in its own folder?

Thank you.

Jeff Slarve

Hi Jeff,

I have to check this and will get back to you.

Friedrich

Hi Jeff,

>
> How do I force my DLL to find it's dependencies in its own folder?
>

See my reply in the "SetPath" thread and the following demo source codes:

http://www.lindersoft.com/projects/d...pendencies.zip

The above SetupBuilder .exe will call into sbdll.dll which is statically
linked to the lspuzipx.dll. The current directory is set and reset.

Does this help?

Friedrich

BTW, the call to the GetCurrentDirectory Windows API is not really required
here because we have a built-in "Get System Info (Current Folder)"
available. But in this example, I demonstrate how to use "Call DLL".

I think I'll add a new built-in "Set Current Folder" script function to
streamline the process.

Friedrich

Thanks for all of your help.

If you want to REALLY streamline the process, how about a checkbox on
the "Call DLL" function to include the dll's folder on the path, but
check with Jane first<g>

Jeff Slarve

(e.g. push/pop the path to/from the folder where the dlls reside
before/after calling)

>dll's folder on the path,

Jeff Slarve

> (e.g. push/pop the path to/from the folder where the dlls reside
> before/after calling)

To be honest, I don't know if such an automated "change current folder
mechanism" would cause negative side effects. I have to investigate it.

Friedrich

Yeah, I can dig it.

But there are several places that I've done rapid-fire path()
changing, and have never noticed a problem.

Of course, that doesn't really mean anything.

And, if the called support.dll is expecting the path() to be that of
the .exe, as has been in SB versions to-date, you wouldn't want to be
changing things willy-nilly. Unless that's how you roll<g>

Jeff Slarve

> Yeah, I can dig it.
>
> But there are several places that I've done rapid-fire path()
> changing, and have never noticed a problem.
>
> Of course, that doesn't really mean anything.
>
> And, if the called support.dll is expecting the path() to be that of
> the .exe, as has been in SB versions to-date, you wouldn't want to be
> changing things willy-nilly. Unless that's how you roll<g>

The LSZip DLL itself is an example where you would experience a negative
side effect. Okay, SetupBuilder provides built-in support for ZIP, so you
don't need the external LSZip here and it's only a theoretical example <g>.

Let us assume, you would like to add items with a "relative path" to the
..zip archive. You have the following folder tree structure:

c:\ziptest
c:\ziptest\folderA
c:\ziptest\folderA\folderB

Okay, you would like to add the relative path "\folderA" and "\folderB"
(including all files) to the ZIP archive. You do this by changing the
current folder to c:\ziptest and then instruct LSZip to include all files
and folders recursively by using *.*

This will store "\folderA" and "\folderA\folderB" in the ZIP archive.

If the application would automatically change the current path to %TMPDIR%,
then the above function to add relative paths to the ZIP would not work any
longer. The key to success is the current path in this case.

Only a theoretical example...

I'll investigate and play (with) the following. Before the DLL in "Call
DLL" is loaded and the specified DLL is located in the %TMPDIR% folder,
change the folder to %TMPDIR%, load the DLL (this includes the dependencies)
and after that (before the DLL function is executed), change the current
path back to the original path. In theory, this should work. This can be
done with only 3 or 4 lines of new code in the installer runtime.

Friedrich

Well, whatever the ramifications are, it seems to be working perfectly
now.

I don't understand the API *STRING vs *CSTRING stuff from your
example, but I guess I'm okay with that<g>

Thanks again for your help. Will be a much better weekend now.

>
>
>I'll investigate and play (with) the following. Before the DLL in "Call
>DLL" is loaded and the specified DLL is located in the %TMPDIR% folder,
>change the folder to %TMPDIR%, load the DLL (this includes the dependencies)
>and after that (before the DLL function is executed), change the current
>path back to the original path. In theory, this should work. This can be
>done with only 3 or 4 lines of new code in the installer runtime.

Jeff Slarve

Thanks so much. Will check it out as soon as I get started.

I really appreciate it.

Jeff Slarve

Friedrich -

Why does SetCurrentDirectory() only work as *STRING vs *CSTRING?

I assumed that was a typo on your part, but it crashes with *CSTRING.

So why does *CSTRING work with GetCurrentDirectory? and why does work
at all, since you're just passing the one parameter?

http://msdn.microsoft.com/en-us/libr...34(VS.85).aspx

Jeff Slarve

Jeff,

> (e.g. push/pop the path to/from the folder where the dlls reside
> before/after calling)

I have modified the installer runtime. In the upcoming SB72, it is handled
automatically (before the DLL and its dependencies are loaded).

Friedrich

Hi Friedrich,

can I avoid this new feature? I set the path via script to a special
path which is NOT the DLL-Path and I really need this, because of
dependencies to third party DLLs.

Markus

Hi Markus,

> can I avoid this new feature? I set the path via script to a special path
> which is NOT the DLL-Path and I really need this, because of dependencies
> to third party DLLs.

This new feature only kicks in if it is a "Support File" located in the
%TMPDIR% folder. For example, you have a "main.dll" and a "dependency.dll",
both files are Support Files located in the %TMPDIR% and dependency.dll is
dependency DLL of main.dll.

The installer runtime changes the current directory to %TMPDIR% before it
uses LoadLibrary to load the DLL and its dependencies. After the
LoadLibrary call and BEFORE a function from the DLL is executed, the current
directory is set back to the "old" current folder.

Would this couse problems in your case?

Friedrich

Unfortunately, yes.

I have a custom support dll which uses pervasive.

Pervasive is installed by my setup as a "sub-setup". The sub-setup,
which is the original pervasive setup, changes the search path, but
windows does not change the path settings of already started processes
and this is also valid for my already started setup.exe. So I change the
current path to the bin-folder of the new pervasive-installation and
after that, I call the dll-function in my support dll.

If the installer runtime would change the current path back to tmpdir,
my custom dll would not find the pervasive-dlls...

The only chance is, that I call "SetEnvironmentVariable" in kernel32.dll
to chnage the search path of my setup process but I suggest to add a
checkbox "set current path to dll location" to the call dll function,
which is NOT set by default to not break already existant setups.

Markus

Hi Markus,

>
> Unfortunately, yes.
>

Yes, I understand. Good point! In your case, the DLL would definitely not
find its dependency files.

So we'll make this new feature optional (and not enabled by default).

Thank you for your feedback.

Friedrich

So I get my checkbox?<g>

>
>
>So we'll make this new feature optional (and not enabled by default).

Jeff Slarve

>
> So I get my checkbox?<g>
>

Yes <g>

Friedrich

Jeff,

> Why does SetCurrentDirectory() only work as *STRING vs *CSTRING?
>
> I assumed that was a typo on your part, but it crashes with *CSTRING.
>
> So why does *CSTRING work with GetCurrentDirectory? and why does work
> at all, since you're just passing the one parameter?
>
> http://msdn.microsoft.com/en-us/libr...34(VS.85).aspx

Why? Because I had too much coffee or not enough <g>. Of course, you are
absolutely right. The GetCurrentDirectory prototype was completely
incorrect. I have uploaded a corrected example. And see attached new
prototype.

Sorry for the confusion!

Thanks,
Friedrich