|
code
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
DLL fightI am struggeling with a hardware company. They provide their own drivers and .dll files, but their .dll files are buggy. People need to downgrade to make them work reliably. I am distributing the downgraded .dlls with my application, and luckily I am allowed to do so. But I am afraid that people might first install my app, then the dlls from the hardware driver CD. Of course they register their dll files in the setup process. The dlls consists of 2 dlls files, both have to be registered. The first has to be referenced in VB6. The other one is internally called by the one which I am referencing in VB6. My question would be: How would I know that the used dlls are still the one that I installed and registered and not the buggy ones from the driver CD? Would I have to look at the registry to see which file is actually registered and then get the file information by an API function? Unfortunately the dll doesn't have a version property, so I cannot request it directly from the dll. Has anybody ever been in the same situation? If the DLLs are C++ then simpley put them in the same folder as your exe.
and if they are activex dll then use reg-free com manifest file. http://vb6zone.blogspot.com/2010/07/make-my-manifest.html Show quoteHide quote "Igor Bolschewski" <angryco***@hotmail.com> wrote in message news:e1NquUATLHA.2104@TK2MSFTNGP04.phx.gbl... | Hi all! | | I am struggeling with a hardware company. | | They provide their own drivers and .dll files, but their .dll files are | buggy. | People need to downgrade to make them work reliably. | | I am distributing the downgraded .dlls with my application, and luckily | I am allowed to do so. | | But I am afraid that people might first install my app, then the dlls | from the hardware driver CD. Of course they register their dll files in | the setup process. | | The dlls consists of 2 dlls files, both have to be registered. | | The first has to be referenced in VB6. | The other one is internally called by the one which I am referencing in VB6. | | My question would be: | How would I know that the used dlls are still the one that I installed | and registered and not the buggy ones from the driver CD? | | Would I have to look at the registry to see which file is actually | registered and then get the file information by an API function? | | Unfortunately the dll doesn't have a version property, so I cannot | request it directly from the dll. | | Has anybody ever been in the same situation? | Hi Abishek!
Looks good, but unfortunately your app crashes with an "Invalid property" when I load my vbp project. Is there a log file that I could send to you? Show quoteHide quote > If the DLLs are C++ then simpley put them in the same folder as your exe. > and if they are activex dll then use reg-free com manifest file. > > http://vb6zone.blogspot.com/2010/07/make-my-manifest.html > > > > "Igor Bolschewski"<angryco***@hotmail.com> wrote in message > news:e1NquUATLHA.2104@TK2MSFTNGP04.phx.gbl... > | Hi all! > | > | I am struggeling with a hardware company. > | > | They provide their own drivers and .dll files, but their .dll files are > | buggy. > | People need to downgrade to make them work reliably. > | > | I am distributing the downgraded .dlls with my application, and luckily > | I am allowed to do so. > | > | But I am afraid that people might first install my app, then the dlls > | from the hardware driver CD. Of course they register their dll files in > | the setup process. > | > | The dlls consists of 2 dlls files, both have to be registered. > | > | The first has to be referenced in VB6. > | The other one is internally called by the one which I am referencing in > VB6. > | > | My question would be: > | How would I know that the used dlls are still the one that I installed > | and registered and not the buggy ones from the driver CD? > | > | Would I have to look at the registry to see which file is actually > | registered and then get the file information by an API function? > | > | Unfortunately the dll doesn't have a version property, so I cannot > | request it directly from the dll. > | > | Has anybody ever been in the same situation? > | > > MMM is not my app :)
here is solution to your invalid property value problem, scroll down and read comments http://mmm4vb6.atom5.com/hello-europe-mmm-0-7-3344.html here is article on reg-free COM http://www.devx.com/vb/Article/32888 Show quoteHide quote "Igor Bolschewski" <angryco***@hotmail.com> wrote in message news:e5lsk6ATLHA.5956@TK2MSFTNGP05.phx.gbl... | Hi Abishek! | | Looks good, but unfortunately your app crashes with an "Invalid | property" when I load my vbp project. | Is there a log file that I could send to you? On 9/4/2010 1:08 AM, Abhishek wrote:
> If the DLLs are C++ then simpley put them in the same folder as your exe. <snip>> and if they are activex dll then use reg-free com manifest file. And what about registering the local copies each time the program is run? "mscir" <ms***@yahoo.com> schrieb im Newsbeitrag Temporary registrations in the "oldfashioned way" willnews:i5t1vs$5hk$1@news.eternal-september.org... > On 9/4/2010 1:08 AM, Abhishek wrote: > > If the DLLs are C++ then simpley put them in the > > same folder as your exe. > > and if they are activex dll then use reg-free com manifest file. > > And what about registering the local copies each time the > program is run? not work that good. One reason is, that in case your own program is using the temporary registered (older or "other") version, any other Application which would be started at the same time, would be forced to use your temporary registered version too. So, that's not very "cooperative", so to say. The second reason is, that on Vista/Win7 you would take chances, regarding a *successfully* temporary registration ("UAC-problems"). So, the recommendation to use SxS-based (manifest-based) regfree-COM is a good one - this method is available from XP onwards (doing in principle the same thing you recommended, but automatically - and without the side- effects of affecting other applications). And of course there's always the other "real regfree COM" way, which works either per VB-Code or per small Helper-Dll (GetInstance-Call instead of CreateObject) - and then (not using the SxS-Services/Manifests) also on systems < XP. Olaf Let's say I install the dlls into my application folder.
They are 32bit dlls. Should I install them to the Sys32 folder or what it's called so that it works under 64bit as well, or does it not matter where I put them? Show quoteHide quote > "mscir"<ms***@yahoo.com> schrieb im Newsbeitrag > news:i5t1vs$5hk$1@news.eternal-september.org... >> On 9/4/2010 1:08 AM, Abhishek wrote: >>> If the DLLs are C++ then simpley put them in the >>> same folder as your exe. >>> and if they are activex dll then use reg-free com manifest file. >> >> And what about registering the local copies each time the >> program is run? > Temporary registrations in the "oldfashioned way" will > not work that good. One reason is, that in case your > own program is using the temporary registered (older > or "other") version, any other Application which would > be started at the same time, would be forced to use > your temporary registered version too. So, that's not > very "cooperative", so to say. The second reason is, > that on Vista/Win7 you would take chances, regarding > a *successfully* temporary registration ("UAC-problems"). > > So, the recommendation to use SxS-based (manifest-based) > regfree-COM is a good one - this method is available from > XP onwards (doing in principle the same thing you > recommended, but automatically - and without the side- > effects of affecting other applications). > > And of course there's always the other "real regfree COM" > way, which works either per VB-Code or per small > Helper-Dll (GetInstance-Call instead of CreateObject) - > and then (not using the SxS-Services/Manifests) also > on systems< XP. > > Olaf > > 32-Bit Windows
C:\Windows\System = Old 16-Bit System Folder C:\windows\system32 = 32-Bit System Folder 64-bit C:\Windows\system32 = 64-Bit System Folder C:\Windows\SysWOW64 = 32-Bit System Folder really confusing. Show quoteHide quote "Igor Bolschewski" <angryco***@hotmail.com> wrote in message news:%23VxU4mBTLHA.2036@TK2MSFTNGP05.phx.gbl... | Let's say I install the dlls into my application folder. | They are 32bit dlls. | Should I install them to the Sys32 folder or what it's called so that it | works under 64bit as well, or does it not matter where I put them? | I use Olaf's DirectCOM library, which he
referred to indirectly but didn't mention in his post. It works dependably and is only 20 KB. Instead of registering the COM DLL you just load it directly, storing your COM DLL and Olaf's DLL in the app.path folder. A DirectCOM call instantiates the desired class in the COM DLL. "Igor Bolschewski" <angryco***@hotmail.com> schrieb im Newsbeitrag Yes, the App.Path (parallel to your Exe-File) isnews:%23VxU4mBTLHA.2036@TK2MSFTNGP05.phx.gbl... > Let's say I install the dlls into my application folder. > They are 32bit dlls. the right place for regfree COM-Dlls (and their non-ActiveX-satellite-Dlls), yes. > Should I install them to the Sys32 folder ... No, if there's a chance that another version of some"Dll-Set" (with the same names) is already there (installed by other vendors), then just leave or use your own Dlls beside your (32Bit)App.Exe-File. LoadLibrary will search the App.Path first, before switching over to other "wellknown places" (read about LoadLibrary in the MSDN). As Mayayana has said, there's a relative simple solution for regfree COM (at least for ActiveX-Dlls - regfree OCXes are a little bit more difficult) - and you can extract the small Helper-Dll (DirectCOM.dll) from the toolset-zip on my site: http://www.thecommon.net/3.html Then try the regfree approach in your App, by changing your instantiation-calls from Dim MyClass As cNameOfClass Set MyClass = New cNameOfClass to: Set MyClass = GetInstance(App.Path & "\AxDllName.dll", _ "cNameOfClass") to create the instance in a regfree fashion. So, instead of "manifest-trouble" you will need to do a search for all instantiation-lines in your code, which refer to cSomeClassInYourAXDll ... and replace all of them with matching GetInstance-Lines - but that's it already. (There's also a helper-*.bas-module in the toolset- download, which contains the needed declarations for the exportet Functions of the DirectCOM.dll - including the just mentioned GetInstance-Call) Deployment then into some Destination-Path of your choice: MyApp.exe AxDllName.dll AxDll_Satellite_AsStandard.dll DirectCOM.dll If your MyApp.exe-Project has no other (COM-) dependencies other than those from AxDllName.dll, then everything should work without registration (directly from an USB-Stick or wherever your App.Path is finally located). Olaf The reg-free COM DLL or OCX should be placed in its own folder, because if
the user is running with admin rights then (OCX) will get registered automatically when used by the app. Show quoteHide quote "Schmidt" <s**@online.de> wrote in message news:i5trnn$3b9$1@speranza.aioe.org... | | "Igor Bolschewski" <angryco***@hotmail.com> schrieb im Newsbeitrag | news:%23VxU4mBTLHA.2036@TK2MSFTNGP05.phx.gbl... | | > Let's say I install the dlls into my application folder. | > They are 32bit dlls. | Yes, the App.Path (parallel to your Exe-File) is | the right place for regfree COM-Dlls (and their | non-ActiveX-satellite-Dlls), yes. "Abhishek" <u***@server.com> schrieb im Newsbeitrag Yep, good catch - but as you say, only necessary,news:i5ts1r$413$1@speranza.aioe.org... > The reg-free COM DLL or OCX should be > placed in its own folder, because if the user is > running with admin rights then (OCX) will get > registered automatically when used by the app. if any OCXes are "in the regfree package too". DirectCOM.dll as it is today, only supports regfree instantiation of AX-Dlls - and on these VB6 does not do an attempt of re-registration on startup of the Process. Olaf "Schmidt" <s**@online.de> wrote in message It would be really helpful if you didn't refer to this technique as reg-free news:i5trnn$3b9$1@speranza.aioe.org... > As Mayayana has said, there's a relative simple > solution for regfree COM (at least for ActiveX-Dlls - > regfree OCXes are a little bit more difficult) - and > you can extract the small Helper-Dll (DirectCOM.dll) > from the toolset-zip on my site: > http://www.thecommon.net/3.html COM, since it isn't. The term has a specific meaning in Windows and what you are doing is not that AT ALL. It is perfectly good, and is especially helpful for pre-XP Windows, but it causes confusion when you overload the term in this manner. Actual Windows reg-free COM has no problems with OCXs whatsoever. I'm not trying to flame you or anything, just hoping to avoid confusion like that we see when people refer to VFred as VB. Well, the dll itself is my last problem, I hope.
My foremost problem is: I am wondering where it searches for it's helper dll. Because as I mentioned, there are 2 dlls, and the main dll needs the helper dll. I am not sure if it searches in the same path (let's say app.path) or Sys32 or elsewhere. It wouldn't help me if I could perfectly load the main dll, but it uses the helper dll from a path which I don't want it to. Show quoteHide quote > "Schmidt" <s**@online.de> wrote in message > news:i5trnn$3b9$1@speranza.aioe.org... >> As Mayayana has said, there's a relative simple >> solution for regfree COM (at least for ActiveX-Dlls - >> regfree OCXes are a little bit more difficult) - and >> you can extract the small Helper-Dll (DirectCOM.dll) >> from the toolset-zip on my site: >> http://www.thecommon.net/3.html > > It would be really helpful if you didn't refer to this technique as > reg-free COM, since it isn't. > > The term has a specific meaning in Windows and what you are doing is not > that AT ALL. It is perfectly good, and is especially helpful for pre-XP > Windows, but it causes confusion when you overload the term in this manner. > > Actual Windows reg-free COM has no problems with OCXs whatsoever. > > I'm not trying to flame you or anything, just hoping to avoid confusion > like that we see when people refer to VFred as VB. "Igor Bolschewski" <angryco***@hotmail.com> schrieb im Newsbeitrag A Dll finally gets loaded by and is running in thenews:OqzTbwGTLHA.456@TK2MSFTNGP06.phx.gbl... > Well, the dll itself is my last problem, I hope. > > My foremost problem is: > I am wondering where it searches for it's helper dll. process-space of your App.exe. And the App-Path is searched first, no matter what Dll is involved, even when loaded indirectly by an "intermediate" AX-Dll - that's something you can rely on - the App-Path comes first. As an regfree deployment-example, if your App-Exe is referencing the AX-Dll (and does not know about any other Dll) - and the AX-Dll has a Helper.dll only known to this AX-Dll internally, then all will work as it should, if you place all Dlls beside your App.exe. \SomePath\ App.exe DirectCOM.dll AX.dll HelperStd.dll regfree instantiation-line for the simple scenario above: GetInstance(App.Path & "\AX.dll", "cSomeClass") But careful, if you work with Sub-Paths below your App.exe and DirectCOM.dll based regfree instantiation. This will not work: \SomePath\ App.exe \Dlls\ DirectCOM.dll AX.dll HelperStd.dll But with this small change it would work again: \SomePath\ App.exe DirectCOM.dll HelperStd.dll \Dlls\ AX.dll regfree instantiation-line for the sub-path-scenario above: GetInstance(App.Path & "\Dlls\AX.dll", "cSomeClass") Explanation for the somewhat funny looking SubPath- placement above: The GetInstance-Call allows direct loading at an explicitely given path, but only for the AX-Dll(s). If this AX-Dll has internal Standard-Dll-dependencies, then these need to be placed or already located in one of the "known" search-paths again - and this is (as before) the App.Path or the known system-paths (as usually \system32 on a 32Bit system). And this holds true also for the DirectCOM.dll, which is also not an ActiveX-Dll, but a Std-Dll. And the just described scenario has implications for the behaviour of a regfree solution, running in the *IDE* and not from your compiled App.exe. Here the hosting Process is the VB6.exe, and the same necessities with regards to placement of Standard-Dlls apply. So, for your deployment (and with relativ low count of AX-Dlls) the variant #1 should be sufficient: \SomePath\ App.exe DirectCOM.dll AX.dll HelperStd.dll For running the same stuff in the IDE, the two Std-Dlls in this example (DirectCOM.dll and HelperStd.dll) need to be placed either beside the VB6.exe-File - or alternatively in the SysPath of your developer-machine (as copies). The AX-Dlls can remain inside the App.path, because these are addressed directly by the GetInstance-Call with a full-path. Olaf Schmidt wrote:
> I think that may be changing. There was news recently that MS will> A Dll finally gets loaded by and is running in the > process-space of your App.exe. > > And the App-Path is searched first, no matter what > Dll is involved, even when loaded indirectly by an > "intermediate" AX-Dll - that's something you can > rely on - the App-Path comes first. patch the NT-line of OSs so that the app path is no longer in the default search path for DLLs. This is an attempt to cut off an exploit whereby malware would place a DLL in its own directory, with the same name as a system DLL or other well-known DLL, and then cause its mischief in DLLMain -- in other words, as it's loaded.
Show quote
Hide quote
"Jim Mack" <no-uce-***@mdxi.com> schrieb im Newsbeitrag Such a change would have - umh... "some foot-shooting-news:keGdnXJ63M-ADh7RnZ2dnUVZ_sKdnZ2d@giganews.com... > Schmidt wrote: > > > > A Dll finally gets loaded by and is running in the > > process-space of your App.exe. > > > > And the App-Path is searched first, no matter what > > Dll is involved, even when loaded indirectly by an > > "intermediate" AX-Dll - that's something you can > > rely on - the App-Path comes first. > > I think that may be changing. There was news recently that > MS will patch the NT-line of OSs so that the app path is > no longer in the default search path for DLLs. potential" I'd suppose. ;-) Do you have some links, where these "news" are mentioned or discussed? Olaf After serious thinking Schmidt wrote :
Show quoteHide quote > "Jim Mack" <no-uce-***@mdxi.com> schrieb im Newsbeitrag http://visualstudiomagazine.com/articles/2010/08/23/microsoft-warns-of-dll-flaw-involving-remote-servers.aspx> news:keGdnXJ63M-ADh7RnZ2dnUVZ_sKdnZ2d@giganews.com... >> Schmidt wrote: >>> >>> A Dll finally gets loaded by and is running in the >>> process-space of your App.exe. >>> >>> And the App-Path is searched first, no matter what >>> Dll is involved, even when loaded indirectly by an >>> "intermediate" AX-Dll - that's something you can >>> rely on - the App-Path comes first. >> >> I think that may be changing. There was news recently that >> MS will patch the NT-line of OSs so that the app path is >> no longer in the default search path for DLLs. > > Such a change would have - umh... "some foot-shooting- > potential" I'd suppose. ;-) > > Do you have some links, where these "news" are mentioned > or discussed? > > Olaf http://visualstudiomagazine.com/articles/2010/08/25/powerpoint-firefox-other-apps-at-risk-from-dll-flaw.aspx -- ClassicVB Users Regroup! comp.lang.basic.visual.misc Free usenet access at http://www.eternal-september.org What you're linking to discusses mainly remote
loading on networks. It's an issue with the current directory that's a big issue currently in the news, but it's really a network security issue, for the most part. (It could also come into play with something like a USB stick locally, but in either case it's an exploit involving the current directory. And a quote from the article is this: "Microsoft says each affected application, many of them not under Microsoft's control, will have to be patched individually." Likewise with Dee Earley's link. It offers advice for preventing attacks when on a network where a DLL might be loaded remotely. Again it's talking about the current directory. I don't see anything in any of those links about not using app.path. According to the MS info. page... http://support.microsoft.com/kb/2264107 ....they're just providing new Registry entries to control loading from the current directory. Preventing loading of a DLL from app.path would break virtually all software, and outside of the system folder it should be the safest place. The current directory, on the other hand, is changeable. In this attack, as I understand it, the attacker convinces someone to open a file from a remote share, USB stick, etc., which changes the current directory, which then allows a malicious DLL to be loaded, assuming it has a name that's not found in app.path, system folder, or Windows folder -- because the current directory is the last location in the standard search path for DLLs. The patch MS offers allows one to skip the current directory search for DLLs -- per-app or system-wide. I don't know how anyone could read those links and conclude that app.path is going to be deleted from the list of searched paths for loading a DLL. They may do that someday, once they finish locking down the system and start blocking all 3rd-party software from using any functions at all outside of managed code....but until that time comes I don't think they're going to block you from loading your own DLL. :) | http://visualstudiomagazine.com/articles/2010/08/23/microsoft-warns-of-dll-flaw-involving-remote-servers.aspx| http://visualstudiomagazine.com/articles/2010/08/25/powerpoint-firefox-other-apps-at-risk-from-dll-flaw.aspx| Show quoteHide quote | | -- | ClassicVB Users Regroup! comp.lang.basic.visual.misc | Free usenet access at http://www.eternal-september.org | |
Show quote
Hide quote
"Leo" <ttdh***@gmail.com> schrieb im Newsbeitrag
http://visualstudiomagazine.com/articles/2010/08/23/microsoft-warns-of-dll-flaw-involving-remote-servers.aspx
news:i62j47$la0$1@news.eternal-september.org... > After serious thinking Schmidt wrote : > > "Jim Mack" <no-uce-***@mdxi.com> schrieb im Newsbeitrag > > news:keGdnXJ63M-ADh7RnZ2dnUVZ_sKdnZ2d@giganews.com... > >> Schmidt wrote: > >>> > >>> A Dll finally gets loaded by and is running in the > >>> process-space of your App.exe. > >>> > >>> And the App-Path is searched first, no matter what > >>> Dll is involved, even when loaded indirectly by an > >>> "intermediate" AX-Dll - that's something you can > >>> rely on - the App-Path comes first. > >> > >> I think that may be changing. There was news recently that > >> MS will patch the NT-line of OSs so that the app path is > >> no longer in the default search path for DLLs. > > > > Such a change would have - umh... "some foot-shooting- > > potential" I'd suppose. ;-) > > > > Do you have some links, where these "news" are mentioned > > or discussed? > > >
http://visualstudiomagazine.com/articles/2010/08/25/powerpoint-firefox-other-apps-at-risk-from-dll-flaw.aspx
> Thanks. This finally boils down to the KB-article which Dee has mentioned in his post, and which is also contained in the discussion-links above, so I've placed additional questions in my reply to Dee. Olaf On 06/09/2010 12:21, Schmidt wrote:
Show quoteHide quote > "Jim Mack"<no-uce-***@mdxi.com> schrieb im Newsbeitrag http://msdn.microsoft.com/en-us/library/ff919712.aspx> news:keGdnXJ63M-ADh7RnZ2dnUVZ_sKdnZ2d@giganews.com... >> Schmidt wrote: >>> And the App-Path is searched first, no matter what >>> Dll is involved, even when loaded indirectly by an >>> "intermediate" AX-Dll - that's something you can >>> rely on - the App-Path comes first. >> >> I think that may be changing. There was news recently that >> MS will patch the NT-line of OSs so that the app path is >> no longer in the default search path for DLLs. > > Such a change would have - umh... "some foot-shooting- > potential" I'd suppose. ;-) > > Do you have some links, where these "news" are mentioned > or discussed? -- Dee Earley (dee.ear***@icode.co.uk) i-Catcher Development Team iCode Systems (Replies direct to my email address will be ignored. Please reply to the group.) "Dee Earley" <dee.ear***@icode.co.uk> schrieb im Newsbeitrag [new LoadLibrary behaviour]news:e4m22BcTLHA.5068@TK2MSFTNGP05.phx.gbl... "Assuming safe DLL search mode is enabled and the application is not using an alternate search order, the system searches directories in the following order: - The directory from which the application loaded. - The system directory. - The 16-bit system directory. - The Windows directory. - The current directory. - The directories that are listed in the PATH environment variable." So, the above states, that even *with* "safe Dll search mode enabled", an Application will continue, to search on (and load from): "The directory from which the application loaded" first. And this is (in my understanding) furthermore VBs App.Path (the Path from where the MainApp.exe was started from). All the security-related considerations and examples assume a vulnerability from "The current directory" which in my understanding is a "different animal" compared with the App.Path. Comments anyone? Olaf On 06/09/2010 15:05, Schmidt wrote:
Show quoteHide quote > "Dee Earley"<dee.ear***@icode.co.uk> schrieb im Newsbeitrag Erm, yes, I read it in passing a few days ago, then I saw the post here > news:e4m22BcTLHA.5068@TK2MSFTNGP05.phx.gbl... > > [new LoadLibrary behaviour] >> http://msdn.microsoft.com/en-us/library/ff919712.aspx > > "Assuming safe DLL search mode is enabled and the application > is not using an alternate search order, the system searches > directories in the following order: > - The directory from which the application loaded. > - The system directory. > - The 16-bit system directory. > - The Windows directory. > - The current directory. > - The directories that are listed in the PATH environment variable." > > So, the above states, that even *with* > "safe Dll search mode enabled", an Application will > continue, to search on (and load from): > "The directory from which the application loaded" > first. > > And this is (in my understanding) furthermore VBs > App.Path (the Path from where the MainApp.exe > was started from). > > All the security-related considerations and examples > assume a vulnerability from "The current directory" > which in my understanding is a "different animal" > compared with the App.Path. and gave a link, forgetting they were separate. My apologies :) (Oh, and it is she, not he :p) -- Dee Earley (dee.ear***@icode.co.uk) i-Catcher Development Team iCode Systems (Replies direct to my email address will be ignored. Please reply to the group.) "Dee Earley" <dee.ear***@icode.co.uk> schrieb im Newsbeitrag Ok, umm sorry - and if I'm allowed a drift-off intonews:OQfGy0cTLHA.5716@TK2MSFTNGP02.phx.gbl... > (Oh, and it is she, not he :p) the muddy waters of "politically incorrect, sexists thinking": Just take it as a compliment! ;-o Olaf "Schmidt" <s**@online.de> wrote in message I made the same mistake once. :-)news:i62uq1$div$1@speranza.aioe.org... : : Ok, umm sorry - and if I'm allowed a drift-off into : the muddy waters of "politically incorrect, sexists thinking": : : Just take it as a compliment! ;-o : Anyone who shuns political correctness is A-OK in my book. Cheers! Schmidt has brought this to us :
Show quoteHide quote > "Dee Earley" <dee.ear***@icode.co.uk> schrieb im Newsbeitrag That's always been my understanding, yeah.> news:e4m22BcTLHA.5068@TK2MSFTNGP05.phx.gbl... > > [new LoadLibrary behaviour] >> http://msdn.microsoft.com/en-us/library/ff919712.aspx > > "Assuming safe DLL search mode is enabled and the application > is not using an alternate search order, the system searches > directories in the following order: > - The directory from which the application loaded. > - The system directory. > - The 16-bit system directory. > - The Windows directory. > - The current directory. > - The directories that are listed in the PATH environment variable." > > So, the above states, that even *with* > "safe Dll search mode enabled", an Application will > continue, to search on (and load from): > "The directory from which the application loaded" > first. > > And this is (in my understanding) furthermore VBs > App.Path (the Path from where the MainApp.exe > was started from). > > All the security-related considerations and examples > assume a vulnerability from "The current directory" > which in my understanding is a "different animal" > compared with the App.Path. > > Comments anyone? Schmidt wrote:
Show quoteHide quote > "Jim Mack" schrieb... The reporting was somewhat confused. Because most programs either>> Schmidt wrote: >>> >>> A Dll finally gets loaded by and is running in the >>> process-space of your App.exe. >>> >>> And the App-Path is searched first, no matter what >>> Dll is involved, even when loaded indirectly by an >>> "intermediate" AX-Dll - that's something you can >>> rely on - the App-Path comes first. >> >> I think that may be changing. There was news recently that >> MS will patch the NT-line of OSs so that the app path is >> no longer in the default search path for DLLs. > > Such a change would have - umh... "some foot-shooting- > potential" I'd suppose. ;-) > > Do you have some links, where these "news" are mentioned > or discussed? start with the current directory = app.path, or force a change to that state, it's easy to think of them as equivalent. The question is whether MS specifically excludes the currently active directory, which would indeed break programs that A) rely on loading from app.path and B) deliberately or by default have the current directory = app.path; or whether MS continues to search the specific "app.path" but never descends to "current directory", no matter what that is. If the former, then yes, a lot of programs will break, and that was the focus of the articles I read. Since the exploit works because Win/Sys is searched after app.path, I don't see how their patch would help if it doesn't exclude app.path, or at least move it later in the search list. There has been so much pushback on this that it might never come to pass in any case. | If you read the MS page, and the other security| If the former, then yes, a lot of programs will break, and that was | the focus of the articles I read. | | Since the exploit works because Win/Sys is searched after app.path, I | don't see how their patch would help if it doesn't exclude app.path, | or at least move it later in the search list. | | There has been so much pushback on this that it might never come to | pass in any case. | reports, you'll see that the issue is with current directory ONLY when the attacker has managed to change that to a remote drive, USB stick, etc. by getting the person to open a file there. The implication is that the malicious DLL would have a unique name, therefore having no chance of being found in app.path, system or windows. So the MS patch allows removing current directory from the DLL search. If you think about it, removing app.path from the search wouldn't make much sense. It would not only break just about everything. It would also imply that the location where software is installed may have been breached, with malicious files installed. In that case the security of DLL loading would be irrelevant. Your installed software would itself have to be assumed to be malware. In other words, if app.path can't be trusted then the PC is already unusable. The helper dll has to be registered, does that tell me if the helper dll
is a standard dll or an activex-dll? Am 05.09.2010 11:50, schrieb Schmidt: Show quoteHide quote > "Igor Bolschewski"<angryco***@hotmail.com> schrieb im Newsbeitrag > news:OqzTbwGTLHA.456@TK2MSFTNGP06.phx.gbl... >> Well, the dll itself is my last problem, I hope. >> >> My foremost problem is: >> I am wondering where it searches for it's helper dll. > > A Dll finally gets loaded by and is running in the > process-space of your App.exe. > > And the App-Path is searched first, no matter what > Dll is involved, even when loaded indirectly by an > "intermediate" AX-Dll - that's something you can > rely on - the App-Path comes first. > > As an regfree deployment-example, if your App-Exe is > referencing the AX-Dll (and does not know about > any other Dll) - and the AX-Dll has a Helper.dll only > known to this AX-Dll internally, then all will work as > it should, if you place all Dlls beside your App.exe. > > \SomePath\ > App.exe > DirectCOM.dll > AX.dll > HelperStd.dll > > regfree instantiation-line for the simple scenario above: > GetInstance(App.Path& "\AX.dll", "cSomeClass") > > But careful, if you work with Sub-Paths below > your App.exe and DirectCOM.dll based regfree > instantiation. > > This will not work: > \SomePath\ > App.exe > \Dlls\ > DirectCOM.dll > AX.dll > HelperStd.dll > > But with this small change it would work again: > \SomePath\ > App.exe > DirectCOM.dll > HelperStd.dll > \Dlls\ > AX.dll > > regfree instantiation-line for the sub-path-scenario above: > GetInstance(App.Path& "\Dlls\AX.dll", "cSomeClass") > > Explanation for the somewhat funny looking SubPath- > placement above: > The GetInstance-Call allows direct loading at an > explicitely given path, but only for the AX-Dll(s). > If this AX-Dll has internal Standard-Dll-dependencies, > then these need to be placed or already located in one > of the "known" search-paths again - and this is (as > before) the App.Path or the known system-paths > (as usually \system32 on a 32Bit system). > And this holds true also for the DirectCOM.dll, > which is also not an ActiveX-Dll, but a Std-Dll. > > And the just described scenario has implications for the > behaviour of a regfree solution, running in the *IDE* > and not from your compiled App.exe. > Here the hosting Process is the VB6.exe, and the same > necessities with regards to placement of Standard-Dlls > apply. > > So, for your deployment (and with relativ low count > of AX-Dlls) the variant #1 should be sufficient: > \SomePath\ > App.exe > DirectCOM.dll > AX.dll > HelperStd.dll > > For running the same stuff in the IDE, the two > Std-Dlls in this example (DirectCOM.dll and > HelperStd.dll) need to be placed either beside > the VB6.exe-File - or alternatively in the SysPath > of your developer-machine (as copies). > The AX-Dlls can remain inside the App.path, > because these are addressed directly by the > GetInstance-Call with a full-path. > > Olaf > > > On Sun, 05 Sep 2010 19:08:48 +0200, Igor Bolschewski
<angryco***@hotmail.com> wrote: >The helper dll has to be registered, does that tell me if the helper dll Most likely yes - it is a standard dll, if it has to be registered for>is a standard dll or an activex-dll? > the application to run. -ralph "ralph" <nt_consultin***@yahoo.net> wrote in message Eh? Since when do standard DLL's need to be registered? That's an ActiveX news:afp7861ec3t53a0agegqhgog9lg1g6an4h@4ax.com... : On Sun, 05 Sep 2010 19:08:48 +0200, Igor Bolschewski : <angryco***@hotmail.com> wrote: : : >The helper dll has to be registered, does that tell me if the helper dll : >is a standard dll or an activex-dll? : > : : Most likely yes - it is a standard dll, if it has to be registered for : the application to run. thing.
Show quote
Hide quote
On Sun, 5 Sep 2010 20:04:12 -0400, "Kevin Provance" <k@p.c> wrote: LOL, caught me. Not sure why it came out that way. I either forgot to> >"ralph" <nt_consultin***@yahoo.net> wrote in message >news:afp7861ec3t53a0agegqhgog9lg1g6an4h@4ax.com... >: On Sun, 05 Sep 2010 19:08:48 +0200, Igor Bolschewski >: <angryco***@hotmail.com> wrote: >: >: >The helper dll has to be registered, does that tell me if the helper dll >: >is a standard dll or an activex-dll? >: > >: >: Most likely yes - it is a standard dll, if it has to be registered for >: the application to run. > >Eh? Since when do standard DLL's need to be registered? That's an ActiveX >thing. type "not", or was thinking the one and typing the other. Thanks for correcting that. -ralph "ralph" <nt_consultin***@yahoo.net> wrote in message Not a problem old top. Occasionally I have a useful purpose or two.news:h5e886l5p72kkgqheudfn6476qhd71fqqe@4ax.com... : : LOL, caught me. Not sure why it came out that way. I either forgot to : type "not", or was thinking the one and typing the other. : : Thanks for correcting that. "Igor Bolschewski" <angryco***@hotmail.com> schrieb im Newsbeitrag I see now, that you already stated that in yournews:e1Asz0RTLHA.4980@TK2MSFTNGP04.phx.gbl... > The helper dll has to be registered, does that tell me > if the helper dll is a standard dll or an activex-dll? first posting - so, if indeed both Dlls are COM-ones: main.dll (ActiveX-Dll) helper.dll (ActiveX-Dll) and need to be registered, then you can forget about "normal Dll-search-paths". In this case it's the *registry* which determines which Dll is loaded from what location (the registry-entry which was written last, determines the location path of either Dll - and this can be entirely different from the system-path and for both Dlls these "registry-links" can be independent ones, depending on the Setup- program or instance which made these entries). So, if you want to work regfree against these Dlls from within your App, the "manifest-approach" would be the recommended one. My DirectCOM.dll stuff can only help you with a regfree instantiation of the "outer dll", the main.dll. If inside this main.dll, the second "helper.dll" is an ActiveX-one, and (internally) not instantiated regfree too (meaning you don't have the sourcecode or influence on the code for "main.dll"), then the regfree approach over DirectCOM is not suited for this scenario of yours. Don't know, which one of the two Dlls is the "more buggy one" - if it is the main.dll which is more buggy, then you could try DirectCOM perhaps anyways, in this case only main.dll would be loaded from your own location (in a regfree manner) - and the dependency ("helper.dll") would then be loaded normally over the *registry* (whatever the latest registry-entry for "helper.dll" points to). But I suspect, that the "newer buggy version" encloses its "different behaviour" compared with your older version in "helper.dll" (according to Murphy). ;-) Olaf Yep, thanks for your post.
I am currently using the registry approach and want to switch over to manifest. Some strange feeling told me that your directcom only works for standard dlls. Show quoteHide quote > "Igor Bolschewski"<angryco***@hotmail.com> schrieb im Newsbeitrag > news:e1Asz0RTLHA.4980@TK2MSFTNGP04.phx.gbl... > >> The helper dll has to be registered, does that tell me >> if the helper dll is a standard dll or an activex-dll? > I see now, that you already stated that in your > first posting - so, if indeed both Dlls are COM-ones: > main.dll (ActiveX-Dll) > helper.dll (ActiveX-Dll) > > and need to be registered, then you can forget about > "normal Dll-search-paths". > In this case it's the *registry* which determines > which Dll is loaded from what location (the registry-entry > which was written last, determines the location path > of either Dll - and this can be entirely different from > the system-path and for both Dlls these "registry-links" > can be independent ones, depending on the Setup- > program or instance which made these entries). > > So, if you want to work regfree against these Dlls > from within your App, the "manifest-approach" would > be the recommended one. > > My DirectCOM.dll stuff can only help you with a > regfree instantiation of the "outer dll", the main.dll. > > If inside this main.dll, the second "helper.dll" is an > ActiveX-one, and (internally) not instantiated regfree > too (meaning you don't have the sourcecode or influence > on the code for "main.dll"), then the regfree approach > over DirectCOM is not suited for this scenario of yours. > > Don't know, which one of the two Dlls is the "more > buggy one" - if it is the main.dll which is more buggy, > then you could try DirectCOM perhaps anyways, > in this case only main.dll would be loaded from your > own location (in a regfree manner) - and the dependency > ("helper.dll") would then be loaded normally over the *registry* > (whatever the latest registry-entry for "helper.dll" points > to). But I suspect, that the "newer buggy version" encloses > its "different behaviour" compared with your older version > in "helper.dll" (according to Murphy). ;-) > > Olaf > > > That's an interesting issue. I'm not sure that
everyone would agree with your definition. Scripters using WSC script "components" are able to register their scripts as COM objects. They can also load that object by using the "script:" moniker with GetObject, which is then sometimes referred to as Reg-Free COM. Olaf's technique is true Reg-Free COM in that he's providing a DLL that does the loading directly, so that registration becomes irrelevant. What Microsoft seems to call Reg-Free COM is actually more like "Local-Reg COM". A registration is still required, but it can be looked up in a manifest provided with the software rather than having to be in the Registry. So you may be technically correct from Microsoft's official point of view, but if you want to split hairs, they probably should have called their method "manifest registration" and ignored the input from the marketing dept. I think that for most people "reg-free" just means what it says: any method that loads a COM class without depending on registration. Show quoteHide quote | It would be really helpful if you didn't refer to this technique as reg-free | COM, since it isn't. | | The term has a specific meaning in Windows "Bob Riemersma" <nospam@nil.net> schrieb im Newsbeitrag Maybe - but I did refer to it as regfree COM ornews:ODaizjFTLHA.456@TK2MSFTNGP06.phx.gbl... > "Schmidt" <s**@online.de> wrote in message > news:i5trnn$3b9$1@speranza.aioe.org... > > As Mayayana has said, there's a relative simple > > solution for regfree COM (at least for ActiveX-Dlls - > > regfree OCXes are a little bit more difficult) - and > > you can extract the small Helper-Dll (DirectCOM.dll) > > from the toolset-zip on my site: > > http://www.thecommon.net/3.html > > It would be really helpful if you didn't refer to this > technique as reg-free COM, since it isn't. "regfree instantiation" already before the first manifest- based SxS-solution was available on XP or mentioned in this group. Will try to talk about it as "regfree instantiation" in the future anyhow, if that does make everybody happier. ;-) > The term has a specific meaning in Windows and Nah, in the end it *achieves* the same thing (for AX-Dlls)> what you are doing is not that AT ALL. It does use GetClassFactory and then works with the Classfactory at a lower level, but there's no hack involved. The MS-approach to the same problem is more complete (involving OCXes) and the App provided with the manifest does not know, it is not working against the "real registry" (for the parts, defined in the manifest). > It is perfectly good, and is especially helpful for pre-XP Yep, and I would trust its lower level approach and> Windows, ... the few API-calls which work at the base-level of COM anytime over a manifest-based MS-solution, as long as only AX-Dlls are involved. > I'm not trying to flame you or anything, just hoping As said above, the chronological order really was a> to avoid confusion like that we see when people > refer to VFred as VB. different one, but perhaps you're right - and in the meantime the "regfree COM" term is associated by more "VBClassic-people" with the MS-SxS- stuff. Olaf "Schmidt" <s**@online.de> wrote in message Don't worry about it Olaf. One dot netter complaining about the political news:i5vm2g$4p1$1@speranza.aioe.org... correctness of labeling everything as it should doesn't change the fact that we all know what your work does and the brilliance of it, regardless what some "this is this" and "this is that" stick in the mud thinks. We use our AX stuff with directCOM minus the registration during setup step, and it's regfree as far as I'm concerned...and...that's what I'm going to continue to call it, regardless what the minority insists. THe so called "proper" way MSFT thinks is standard, by using all the manifests is just a PITA no matter how one slices it...and I have yet to see anyone (myself included) get that MMM thing to work properly, much less do what it claims to do. DirectCOM on the other hand...no problem. :-)
Show quote
Hide quote
"Kevin Provance" <k@p.c> wrote in message Poor guy, somebody done you wrong! Sorry to see that.news:i60426$5gc$1@news.eternal-september.org... > > "Schmidt" <s**@online.de> wrote in message > news:i5vm2g$4p1$1@speranza.aioe.org... > > Don't worry about it Olaf. One dot netter complaining about the political > correctness of labeling everything as it should doesn't change the fact > that > we all know what your work does and the brilliance of it, regardless what > some "this is this" and "this is that" stick in the mud thinks. We use > our > AX stuff with directCOM minus the registration during setup step, and it's > regfree as far as I'm concerned...and...that's what I'm going to continue > to > call it, regardless what the minority insists. THe so called "proper" way > MSFT thinks is standard, by using all the manifests is just a PITA no > matter > how one slices it...and I have yet to see anyone (myself included) get > that > MMM thing to work properly, much less do what it claims to do. DirectCOM > on > the other hand...no problem. :-) > http://encyclopediadramatica.com/Kevin_Provance On 06/09/2010 06:39, Bob Riemersma wrote:
> Poor guy, somebody done you wrong! Sorry to see that. Nice, someone had fun... :p> > http://encyclopediadramatica.com/Kevin_Provance (Sorry Kevin :) -- Dee Earley (dee.ear***@icode.co.uk) i-Catcher Development Team iCode Systems (Replies direct to my email address will be ignored. Please reply to the group.) "Dee Earley" <dee.ear***@icode.co.uk> wrote in message Well, you know what they say, accuse others what's true about yourself.news:O5l1wpaTLHA.5716@TK2MSFTNGP02.phx.gbl... > On 06/09/2010 06:39, Bob Riemersma wrote: >> Poor guy, somebody done you wrong! Sorry to see that. >> >> http://encyclopediadramatica.com/Kevin_Provance > > Nice, someone had fun... :p > (Sorry Kevin :) "Nobody" <nob***@nobody.com> wrote in message I'm no coward. What's your excuse?news:i62gl2$c7g$1@speranza.aioe.org... : : Well, you know what they say, accuse others what's true about yourself. "Kevin Provance" <k@p.c> wrote in message Yeah, that's what I thought.news:i63iss$ghe$1@news.eternal-september.org... : : "Nobody" <nob***@nobody.com> wrote in message : news:i62gl2$c7g$1@speranza.aioe.org... :: :: Well, you know what they say, accuse others what's true about yourself. : : I'm no coward. What's your excuse? : "Kevin Provance" <k@p.c> wrote in message That's strange. I see conformism as cowardice too. You know, they push fornews:i63iss$ghe$1@news.eternal-september.org... > > "Nobody" <nob***@nobody.com> wrote in message > news:i62gl2$c7g$1@speranza.aioe.org... > : > : Well, you know what they say, accuse others what's true about yourself. > > I'm no coward. What's your excuse? people to use their real names or ID so they can be easily tracked by anyone, and push for people to promote their ideas, who toe the line out of cowardice. But I see that a balance is needed between anonymity, and using a real ID. I will use some other handle in the future. P.S.: I am not sure if you misinterpreted the remarks that you quoted above. I was referring to the author of the article in question.
Show quote
Hide quote
"Nobody" <nob***@nobody.com> wrote in message Can't even turn on some of the features of my DroidX phone without google news:i6725o$29o$1@speranza.aioe.org... > "Kevin Provance" <k@p.c> wrote in message > news:i63iss$ghe$1@news.eternal-september.org... >> >> "Nobody" <nob***@nobody.com> wrote in message >> news:i62gl2$c7g$1@speranza.aioe.org... >> : >> : Well, you know what they say, accuse others what's true about yourself. >> >> I'm no coward. What's your excuse? > > That's strange. I see conformism as cowardice too. You know, they push for > people to use their real names or ID so they can be easily tracked by > anyone, and push for people to promote their ideas, who toe the line out > of knowing exactly where I'm at.. )-: Show quoteHide quote > cowardice. But I see that a balance is needed between anonymity, and using > a > real ID. I will use some other handle in the future. > > P.S.: I am not sure if you misinterpreted the remarks that you quoted > above. > I was referring to the author of the article in question. > > > > > > > | Can't even turn on some of the features of my DroidX phone without google You mean like the feature to report to the| knowing exactly where I'm at.. )-: | world where you are via 4Square? :) Couldn't agree more. When I Twitter to my friends that I'm brushing my teeth, I don't want the whole world to know it's me. :) I saw an article in Nat. Geographic last month about locational tech. Apparently one can point a "smart phone" (superfluphone?) at something and get information. (What a particular building is. If it's a restaurant, get a rating. Etc.) The prediction is that by next year the cutting edge crowd will be wearing glasses fitted with small cameras that show what's in front of you, with information overlayed on the screen. People will no longer have to be hassled by relating to their own experience at all. But I suppose it could create new problems. If you look too long at a mother changing her baby's diaper, you might get picked up on a child po*n charge. Or if you walk by Starbucks more than 3 times without redeeming the instant, GPS-derived coupon on your phone, you might be up for a charge of "undermining economic progress". ...And there's no chance of beating the charge. It's all on video. "Dee Earley" <dee.ear***@icode.co.uk> wrote in message Bill McCarthy. Everything after that was trolling. They didn't even get my news:O5l1wpaTLHA.5716@TK2MSFTNGP02.phx.gbl... : On 06/09/2010 06:39, Bob Riemersma wrote: : > Poor guy, somebody done you wrong! Sorry to see that. : > : > http://encyclopediadramatica.com/Kevin_Provance : : Nice, someone had fun... :p : (Sorry Kevin :) phone number right. ;-) | Poor guy, somebody done you wrong! Sorry to see that. It doesn't look to me like you're sorry to see that.| You're jumping at the chance to demean and smear someone who disagrees with you. Kevin might be a bit coarse and insensitive sometimes, but he's not deliberately malicious. If you would just post your *opinions* and not always try to present them as The Law then you'd probably avoid a lot of criticism. "Mayayana" <mayayana@invalid.nospam> wrote in message No, I really do think that goes far beyond fair play. Lots of hitting below news:i62src$f84$1@news.eternal-september.org... >| Poor guy, somebody done you wrong! Sorry to see that. > | > > It doesn't look to me like you're sorry to see that. > You're jumping at the chance to demean and smear > someone who disagrees with you. > > Kevin might be a bit coarse and insensitive sometimes, > but he's not deliberately malicious. If you would just post > your *opinions* and not always try to present them as > The Law then you'd probably avoid a lot of criticism. > the belt. I'll admit I wasn't too happy about that ultimate insult Kevin posted though. Who enjoys being called a "dot netter" after all? As for "The Law" all I try to do is pass along information that will help people keep their VB6 programs working as Microsoft alters the ecosystem in new Windows releases. If being aware of Microsoft's chosen path through the sands they choose to shift can help, then people should know what that path is. If that means calling things by their proper names so people can navigate the rocky shoals of MSDN then I don't see what the problem is. Oh well, that's just how things run in here I guess. Mayayana formulated on Monday :
>> Poor guy, somebody done you wrong! Sorry to see that. BS.>> > > It doesn't look to me like you're sorry to see that. > You're jumping at the chance to demean and smear > someone who disagrees with you. > > Kevin might be a bit coarse and insensitive sometimes, > but he's not deliberately malicious. -- Tom Shelton | > Kevin might be a bit coarse and insensitive sometimes, Happy Labor Day, Tom. Nice to see that you're your| > but he's not deliberately malicious. | | BS. | usual cheery self. :)
Show quote
Hide quote
"Bob Riemersma" <nospam@nil.net> skrev i meddelandet Sad sad... and I guess your'e not smart enough to feel ashamed for that news:eCd$sXYTLHA.5716@TK2MSFTNGP02.phx.gbl... > "Kevin Provance" <k@p.c> wrote in message > news:i60426$5gc$1@news.eternal-september.org... >> >> "Schmidt" <s**@online.de> wrote in message >> news:i5vm2g$4p1$1@speranza.aioe.org... >> >> Don't worry about it Olaf. One dot netter complaining about the >> political >> correctness of labeling everything as it should doesn't change the fact >> that >> we all know what your work does and the brilliance of it, regardless what >> some "this is this" and "this is that" stick in the mud thinks. We use >> our >> AX stuff with directCOM minus the registration during setup step, and >> it's >> regfree as far as I'm concerned...and...that's what I'm going to continue >> to >> call it, regardless what the minority insists. THe so called "proper" >> way >> MSFT thinks is standard, by using all the manifests is just a PITA no >> matter >> how one slices it...and I have yet to see anyone (myself included) get >> that >> MMM thing to work properly, much less do what it claims to do. DirectCOM >> on >> the other hand...no problem. :-) >> > Poor guy, somebody done you wrong! Sorry to see that. > > http://encyclopediadramatica.com/Kevin_Provance post... /Henning If I were you, I would calculate the checksum of the DLL's and warn the user
of compatibility issues, and ask him if he wants to proceed anyway. Search newsgroups for "vb crc32" or "vb md5". To find an ActiveX DLL location, you need to look in the registry: HKLM\SOFTWARE\Classes\CLSID\<someGUID>\InProcServer32 Here is a VB library that contain a class to make it easy to access the registry. Download it and check out CRegKey.cls. This is a lightweight class to allow easy access to the registry, and to String and DWORD values. There is another class CRegistry.cls, but this is fully featured that includes more functionality that is not needed by the average application. It includes additional functionality such as enumerating subkeys and values, and reading or writing binary values. http://sourceforge.net/projects/codebox/ Example code: Option Explicit Private Sub Form_Load() Dim reg As New CRegKey Dim sDllPath As String sDllPath = "" If reg.OpenKey(cbrkHKLocalMachine, _ "SOFTWARE\Classes\CLSID\<someGUID>\InProcServer32", _ cbrkKeyQueryValue) Then ' Success sDllPath = reg.GetString("", "") ' Get the default or unnamed value Debug.Print sDllPath reg.CloseKey End If End Sub You need to replace "<someGUID>" with GUID that the DLL uses. This doesn't change from version to version, unless they are not using binary compatibility. Thanks, that looks like what I need for a first start!
Show quoteHide quote > If I were you, I would calculate the checksum of the DLL's and warn the user > of compatibility issues, and ask him if he wants to proceed anyway. Search > newsgroups for "vb crc32" or "vb md5". To find an ActiveX DLL location, you > need to look in the registry: > > HKLM\SOFTWARE\Classes\CLSID\<someGUID>\InProcServer32 > > Here is a VB library that contain a class to make it easy to access the > registry. Download it and check out CRegKey.cls. This is a lightweight class > to allow easy access to the registry, and to String and DWORD values. There > is another class CRegistry.cls, but this is fully featured that includes > more functionality that is not needed by the average application. It > includes additional functionality such as enumerating subkeys and values, > and reading or writing binary values. > > http://sourceforge.net/projects/codebox/ > > Example code: > > Option Explicit > > Private Sub Form_Load() > Dim reg As New CRegKey > Dim sDllPath As String > > sDllPath = "" > If reg.OpenKey(cbrkHKLocalMachine, _ > "SOFTWARE\Classes\CLSID\<someGUID>\InProcServer32", _ > cbrkKeyQueryValue) Then > ' Success > sDllPath = reg.GetString("", "") ' Get the default or unnamed value > Debug.Print sDllPath > reg.CloseKey > End If > End Sub > > You need to replace "<someGUID>" with GUID that the DLL uses. This doesn't > change from version to version, unless they are not using binary > compatibility. > > > 
Other interesting topics
What Is the User Path for Deployment Similar to $(AppPath)?
Looking for VC6 newsgroup Error 481 Invalid picture Global class and WithEvents Distibution of VB6 program Closing Grouped instances in the taskbar Componenet not installed correctly by PDW Error 5: ERROR_ACCESS_DENIED when accessing registry in Windows 7 Calling function pointers Call for votes: New german discussion group for VB.classic in de.* |
|||||||||||||||||||||||
