-
Re: %_sb_errorcode% = -1
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
-
Re: %_sb_errorcode% = -1
> 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
-
Re: %_sb_errorcode% = -1
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
-
Re: %_sb_errorcode% = -1
Thanks so much. Will check it out as soon as I get started.
I really appreciate it.
Jeff Slarve
-
Re: %_sb_errorcode% = -1
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
-
Re: %_sb_errorcode% = -1
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
-
Re: %_sb_errorcode% = -1
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
-
Re: %_sb_errorcode% = -1
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
-
Re: %_sb_errorcode% = -1
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
-
Re: %_sb_errorcode% = -1
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