[8.6.0] vs. [7.5.2] Library lookups

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

[8.6.0] vs. [7.5.2] Library lookups

Doug Stewart
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.

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at http://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: [8.6.0] vs. [7.5.2] Library lookups

Louis LaBrunda

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


On Friday, April 18, 2014 11:15:07 AM UTC-4, Doug Stewart wrote:
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.

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at http://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: [8.6.0] vs. [7.5.2] Library lookups

Doug Stewart
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?

On Friday, April 18, 2014 11:45:14 AM UTC-4, Louis LaBrunda wrote:

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


On Friday, April 18, 2014 11:15:07 AM UTC-4, Doug Stewart wrote:
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.

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at http://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: [8.6.0] vs. [7.5.2] Library lookups

Louis LaBrunda

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 the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at http://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: [8.6.0] vs. [7.5.2] Library lookups

Doug Stewart
Wonderful, thanks Lou, very much appreciated.


On Mon, Apr 21, 2014 at 11:06 AM, Louis LaBrunda <[hidden email]> 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 [hidden email].
To post to this group, send email to [hidden email].
Visit this group at http://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at http://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: [8.6.0] vs. [7.5.2] Library lookups

John O'Keefe-3
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 <[hidden email]> 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 <a href="https://groups.google.com/d/topic/va-smalltalk/tCLPtRGrEco/unsubscribe" target="_blank" onmousedown="this.href='https://groups.google.com/d/topic/va-smalltalk/tCLPtRGrEco/unsubscribe';return true;" onclick="this.href='https://groups.google.com/d/topic/va-smalltalk/tCLPtRGrEco/unsubscribe';return true;">https://groups.google.com/d/topic/va-smalltalk/tCLPtRGrEco/unsubscribe.
To unsubscribe from this group and all its topics, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at <a href="http://groups.google.com/group/va-smalltalk" target="_blank" onmousedown="this.href='http://groups.google.com/group/va-smalltalk';return true;" onclick="this.href='http://groups.google.com/group/va-smalltalk';return true;">http://groups.google.com/group/va-smalltalk.
For more options, visit <a href="https://groups.google.com/d/optout" target="_blank" onmousedown="this.href='https://groups.google.com/d/optout';return true;" onclick="this.href='https://groups.google.com/d/optout';return true;">https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at http://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: [8.6.0] vs. [7.5.2] Library lookups

Doug Stewart
Thanks John

On Monday, April 21, 2014 12:29:12 PM UTC-4, John O'Keefe wrote:
Doug -

There is a good discussion of the .DLL search order and the use of App Paths in <a href="http://msdn.microsoft.com/en-us/library/windows/desktop/ee872121(v=vs.85).aspx" target="_blank" onmousedown="this.href='http://www.google.com/url?q\75http%3A%2F%2Fmsdn.microsoft.com%2Fen-us%2Flibrary%2Fwindows%2Fdesktop%2Fee872121(v%3Dvs.85).aspx\46sa\75D\46sntz\0751\46usg\75AFQjCNF6wrnV00WVug8RGmRBDwiH1OYrqw';return true;" onclick="this.href='http://www.google.com/url?q\75http%3A%2F%2Fmsdn.microsoft.com%2Fen-us%2Flibrary%2Fwindows%2Fdesktop%2Fee872121(v%3Dvs.85).aspx\46sa\75D\46sntz\0751\46usg\75AFQjCNF6wrnV00WVug8RGmRBDwiH1OYrqw';return true;">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 <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="mD_kDOSMPK8J" onmousedown="this.href='javascript:';return true;" onclick="this.href='javascript:';return true;">L...@...> 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 <a href="https://groups.google.com/d/topic/va-smalltalk/tCLPtRGrEco/unsubscribe" target="_blank" onmousedown="this.href='https://groups.google.com/d/topic/va-smalltalk/tCLPtRGrEco/unsubscribe';return true;" onclick="this.href='https://groups.google.com/d/topic/va-smalltalk/tCLPtRGrEco/unsubscribe';return true;">https://groups.google.com/d/topic/va-smalltalk/tCLPtRGrEco/unsubscribe.
To unsubscribe from this group and all its topics, send an email to <a href="javascript:" target="_blank" gdf-obfuscated-mailto="mD_kDOSMPK8J" onmousedown="this.href='javascript:';return true;" onclick="this.href='javascript:';return true;">va-smalltalk...@googlegroups.com.
To post to this group, send email to <a href="javascript:" target="_blank" gdf-obfuscated-mailto="mD_kDOSMPK8J" onmousedown="this.href='javascript:';return true;" onclick="this.href='javascript:';return true;">va-sma...@....
Visit this group at <a href="http://groups.google.com/group/va-smalltalk" target="_blank" onmousedown="this.href='http://groups.google.com/group/va-smalltalk';return true;" onclick="this.href='http://groups.google.com/group/va-smalltalk';return true;">http://groups.google.com/group/va-smalltalk.
For more options, visit <a href="https://groups.google.com/d/optout" target="_blank" onmousedown="this.href='https://groups.google.com/d/optout';return true;" onclick="this.href='https://groups.google.com/d/optout';return true;">https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at http://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.