06300341.txt 30-Jun-00


Subject: Catch 22....
From: "Will Chapman" <willchapman@dial.pipex.com>

I have some DLL prototypes in my app and I don't know in
  advance where they are located (I can guess but as they
  are installed by a third party app, the user could have
  put them in a non-default directory).
I have a function that locates the appropriate path but
  before I can call it the app complains that it can't find
  the DLL's.
I've tried setting a global via App:initialize() and
  App:preinit() but the DLL's complain first.
I've also tried
_dll Function Adll()  AS ;
  DWORD:PASCAL:GetPath()+nameof.dll.func
where Getpath is my function that locates the correct path
  but that doesn't work either.
Are the only options to copy the DLL's to windows\system or
  to use LoadLibrary?

Thanks..
Will Chapman


Subject: Re: Catch 22....
From: "Glen Townsley" <glent@costengineer.com.au>

Will,

Can you use the splash screen sample on KnowVO and check for
  the files' existence in there?

HTH
Glen


Subject: Re: Catch 22....
From: "Patrick Rogers" <progers@kc.rr.com>

Will,

It was my understanding that when the application starts, it
  will automatically load all associated dll's, unless you
  use the LoadLibrary command.   It appears that you already
  know your only two options.

HTH
Patrick Rogers


Subject: Re: Catch 22....
From: "Will Chapman" <willchapman@dial.pipex.com>

As I recall the old splash screen example was a separate exe
  so thats an interesting idea - have a small launch app
  that passes the main app the appropriate path - that
  sounds better than stuffing duplicate files in
  Windows\system - I'll give it a shot.

Thanks for the idea..
Will Chapman


Subject: Re: Catch 22....
From: Gary Stark <gstark@DONT_SPAM_RedbacksWeb.com>

Will,

Reading between the lines in your note, it strikes me that
  if you don't know in advance where these DLLs are being
  installed, then you might also be likely to run into the
  situation where they're in fact not installed at all.
Also, you have the potential here that a user, at some
  future point, might install a different (later, more up-
  to-date) version of the app in question, with different
  refernces within the DLL. This will cause you all sorts of
  other problems ... <g>
It seems to me that the easiest way around this problem
  would be to - subject of course to licensing issues -
  simply install a known copy of the required DLLs within
  your application's program directory. That way you're
  guaranteeing the performance of your application, with a
  supplied known set of dependant DLLs.
I'd stay away from the Windoze\System directory; there's too
  much in there already, and for W2K apps that's a no-no
  anyway.
The other alternative is to find your dependant
  application/s during your install, and refuse to install
  unless they can be located. Once located, you can place
  their locations into the system registry, and retrieve
  that data upon your application start-up.

hth.
Gary Stark


Subject: Re: Catch 22....
From: "Will Chapman" <willchapman@dial.pipex.com>

Gary

Thats true but once into the app I have that covered...what
  I'm talking about here is DLL's that belong to the Palm
  Desktop, and it is a simple of looking for a  known
  Registry key to tell whether it is installed or not.
>
Also, you have the potential here that a user, at some
  future point, might install a different (later, more up-
  to-date) version of the app in question, with different
  refernces within the DLL.
>
Exactly, thats why I don't want to put the DLL's in
  windows\system
>
the required DLLs within your application's program
  directory. That way you're guaranteeing the performance of
  your application, with a supplied known set of dependant
  DLLs.
>

Thats what I doing at the moment but it does seem
a) a waste to install a second copy of each DLL (although I
  could delete them afterwards)
b) add extra clutter to my install
Its neater to use the DLL's that are already installed....
>
The other alternative is to find your dependant
  application/s during your install, and refuse to install
  unless they can be located. Once located, you can place
  their locations into the system registry, and retrieve
  that data upon your application start-up.
>
Ah, but thats the Catch 22 - because I'm declaring _DLL
  Function I need to know in advance where they are located
  and if the location is wrong the app won't load.....

Thanks for your input....
Will Chapman


Subject: Re: Catch 22....
From: Gary Stark <gstark@DONT_SPAM_RedbacksWeb.com>

Will,

>
Exactly, thats why I don't want to put the DLL's in
  windows\system
>
And this is why you should install the multiple copies of
  the DLL. Yes, I'll grant that it's wasteful, but even
  Micro$haft have somewhat given up on the concept of common
  DLLs now. The standard DLLs shipped with W2K cannot be
  overwritten now. While the theory was good, in practice it
  was less so ...
>
Ah, but thats the Catch 22 - because I'm declaring _DLL
  Function I need to know in advance where they are located
  and if the location is wrong the app won't load.....
>
But your declaration doesn't need the path. It just needs to
  find the DLL at compile time to compile, and to find it at
  runtime, via a pathing methodology, will work too. So,
  after you locate the app during install, modify the
  client's path statement ...
Alternatively, because you're dependant upon the Palm
  installation, why not install based upon that dependancy,
  eg: C:\Palm\WillsApp? Then the Palm DLLs will always be
  one level up from where you are.

Gary Stark


Subject: Re: Catch 22....
From: "Will Chapman" <willchapman@dial.pipex.com>

>
Alternatively, because you're dependant upon the Palm
  installation, why not install based upon that dependancy,
  eg: C:\Palm\WillsApp? Then the Palm DLLs will always be

  one level up from where you are.
>
Thats not a bad idea - I'll think about the othe
  implications of that...

Thanks for your input,,
Will Chapman


Subject: Re: Catch 22....
From: Duane@altx.net (Duane)

Will,

There is a place in the registry where you can setup your
  application with a path to look for DLL's. It works on
  win9x and on NT, I have not tested it on Win2000.
You do need to know the path of your DLL's ahead of time.
REGEDIT4
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\
  CurrentVersion\AppPaths\yourapp.Exe]
@="c:\\YourAppPath\\yourapp.Exe"
"Path"="c:\\SomeDLLPath;c:\\SomeOtherDLLPath"


Catch 22....
Posted by: Williebey

I have several _DLL Function prototypes that belong to a
  third party application that holds its DLL's in its own
  install directory.
The third party app posts its install directory to the
  Registry so it is a simple matter to determine where the
  target DLL's reside.
However, my CAVO2.5a1 app won't run unless it knows where
  the DLL's reside at launch time.
I've tried App:initialize() and:
_DLL Function Foo() PASCAL:GetDir() Thirdparty.dll.Foo
Where GetDir() returns the appropriate directory but no
  luck.
Is there another option other than:
a) Use LoadLibrary
b) Install copies of the 3rd party DLL's in my apps install
  directory or Windows\System (thereby cluttering and
  risking version mismatch)

Thanks...


RE: Catch 22....
Posted by: mrg17

THe only other options I am aware of are
c) In your installer modify the system path
d) write a launcher app that modifies the path before
  launching your main app