[8.6.0] vs. [7.5.2] Library lookups

60 views
Skip to first unread message

Doug Stewart

unread,
Apr 18, 2014, 11:15:07 AM4/18/14
to va-sma...@googlegroups.com
Does anyone know the library look up protocol for VAST?

Is it?
1. path of executable
2. PATH environment variable
3. Windows/system32
4. Windows/SysWOW64
5. ???

When the bin directory existed, did the executable used to do a recursive lookup in ../*  ?

Now, without the bin directory, has the ../* lookup been removed?

Our app is organized like so:

/path/apps/app1 <-- executable lives here
/path/apps/system <-- vast dll's live here

In 7.5.2, the dll's were found.
In 8.6.0 the dll's were not found.

That led me to believe that the assumed lookup of ../* recursively was removed in 8.6.0

Can anyone help me understand how dll's are truly looked-up?

Our need is for side-by-side installations with different versions of our applications pointing to different versions of vast.

Louis LaBrunda

unread,
Apr 18, 2014, 11:45:14 AM4/18/14
to va-sma...@googlegroups.com

Hi Doug,

I don't think the library look up protocol has changed, at least not exactly.  You now need to include the [PlatformLibrary Name Mappings] section in an Ini file (see VAST ini file) of the same name as you image and in the same folder as the image (you may be able to put it elsewhere but this is easiest).

I put all the VA Smalltalk DLLs (and some others) is a folder like:

c:\Program Files\Common Files\Keystone Software Corp\binV8.6\

For NT services I put a renamed copy (same as program) of abtntsrv.exe in the binVn.n folder.  That gives it access to the DLLs.  The image lives in its own folder.

For GUI programs I keep the exe, image and ini files in their own folder and point the the DLLs with a registry entry with the path to the bin folder.  Like so:

[HKEY_LOCAL_MACHINE][HKEY_LOCAL_MACHINE\SOFTWARE][HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft]
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows][HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion][HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths]
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\MyProg.Exe]
"Path"="***Path to Bin***\binV8.6"

I hope this helps.

Lou

Doug Stewart

unread,
Apr 18, 2014, 2:47:02 PM4/18/14
to va-sma...@googlegroups.com
Hi Lou, thanks for your reply. 

I do include the [PlatformLibrary Name Mappings] stanza, so that should be okay. 

Question: I'm guessing that, in the ini file, I can provide a path for these dll's, yes? Sounds like that would not be necessary if the registry entry does what I hope.

Question: I don't really understand the registry entry example you provided.

Here's my guess, please correct me: Anytime a program by the name specified runs, supply the given path parameter to the exe as if it were the first/last entry on the PATH environment variable.

So, the presence of HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\MyProg.Exe key would prepend/append the provided path= anytime MyProg.Exe runs?

Question: Could you not also use this registry trick for the *ntsrv.exe (your services)?

Am I close?

Louis LaBrunda

unread,
Apr 21, 2014, 11:06:41 AM4/21/14
to va-sma...@googlegroups.com

Hi Doug,

Question: I'm guessing that, in the ini file, I can provide a path for these dll's, yes? Sounds like that would not be necessary if the registry entry does what I hope.

I think that could be possible but DLL's are a little different from the things like NLS files.  Programs normally don't give the path to a DLL, windows searches for them. See more below.

Question: I don't really understand the registry entry example you provided.

Here's my guess, please correct me: Anytime a program by the name specified runs, supply the given path parameter to the exe as if it were the first/last entry on the PATH environment variable.

So, the presence of HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\MyProg.Exe key would prepend/append the provided path= anytime MyProg.Exe runs?

This is about right but the program really doesn't get the path and doesn't do the search for the DLL.  The program asks (the OS) to access a DLL (makes a call to a function in the DLL) windows searches the various paths it has available starting with the one in the registry to link to the DLL.  Install programs like InstallShield will setup the registry entry for you.

Question: Could you not also use this registry trick for the *ntsrv.exe (your services)?

I don't think so but now that you ask, I can't remember why.  It may have something to do with services running without anyone being logged on or something.

Am I close?

Very.

Lou

Doug Stewart

unread,
Apr 21, 2014, 11:59:12 AM4/21/14
to va-sma...@googlegroups.com
Wonderful, thanks Lou, very much appreciated.


--
You received this message because you are subscribed to a topic in the Google Groups "VA Smalltalk" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/va-smalltalk/tCLPtRGrEco/unsubscribe.
To unsubscribe from this group and all its topics, send an email to va-smalltalk...@googlegroups.com.
To post to this group, send email to va-sma...@googlegroups.com.
Visit this group at http://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.

John O'Keefe

unread,
Apr 21, 2014, 12:29:12 PM4/21/14
to va-sma...@googlegroups.com
Doug -

There is a good discussion of the .DLL search order and the use of App Paths in http://msdn.microsoft.com/en-us/library/windows/desktop/ee872121(v=vs.85).aspx

John


On Monday, April 21, 2014 11:59:12 AM UTC-4, Doug Stewart wrote:
Wonderful, thanks Lou, very much appreciated.
On Mon, Apr 21, 2014 at 11:06 AM, Louis LaBrunda <L...@keystone-software.com> wrote:

Hi Doug,

Question: I'm guessing that, in the ini file, I can provide a path for these dll's, yes? Sounds like that would not be necessary if the registry entry does what I hope.

I think that could be possible but DLL's are a little different from the things like NLS files.  Programs normally don't give the path to a DLL, windows searches for them. See more below.

Question: I don't really understand the registry entry example you provided.

Here's my guess, please correct me: Anytime a program by the name specified runs, supply the given path parameter to the exe as if it were the first/last entry on the PATH environment variable.

So, the presence of HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\MyProg.Exe key would prepend/append the provided path= anytime MyProg.Exe runs?

This is about right but the program really doesn't get the path and doesn't do the search for the DLL.  The program asks (the OS) to access a DLL (makes a call to a function in the DLL) windows searches the various paths it has available starting with the one in the registry to link to the DLL.  Install programs like InstallShield will setup the registry entry for you.

Question: Could you not also use this registry trick for the *ntsrv.exe (your services)?

I don't think so but now that you ask, I can't remember why.  It may have something to do with services running without anyone being logged on or something.

Am I close?

Very.

Lou

--
You received this message because you are subscribed to a topic in the Google Groups "VA Smalltalk" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/va-smalltalk/tCLPtRGrEco/unsubscribe.
To unsubscribe from this group and all its topics, send an email to va-smalltalk+unsubscribe@googlegroups.com.

Doug Stewart

unread,
Apr 22, 2014, 2:29:54 PM4/22/14
to va-sma...@googlegroups.com
Thanks John
To unsubscribe from this group and all its topics, send an email to va-smalltalk...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages