[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

microsoft.public.vb.general.discussion

DLL fight

Igor Bolschewski

9/4/2010 7:44:00 AM

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?
52 Answers

F*CK

9/4/2010 8:08:00 AM

0

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-man...



"Igor Bolschewski" <angrycoder@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?
|


Igor Bolschewski

9/4/2010 8:52:00 AM

0

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?


> 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-man...
>
>
>
> "Igor Bolschewski"<angrycoder@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?
> |
>
>

Mike Scirocco

9/4/2010 9:03:00 AM

0

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.

<snip>

And what about registering the local copies each time the program is run?

Schmidt

9/4/2010 9:55:00 AM

0


"mscir" <mscir@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

Igor Bolschewski

9/4/2010 10:11:00 AM

0

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?

> "mscir"<mscir@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
>
>

F*CK

9/4/2010 10:59:00 AM

0

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

here is article on reg-free COM
http://www.devx.com/vb/Art...


"Igor Bolschewski" <angrycoder@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?


F*CK

9/4/2010 11:03:00 AM

0

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.

"Igor Bolschewski" <angrycoder@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?
|

Mayayana

9/4/2010 1:15:00 PM

0

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.

Schmidt

9/4/2010 4:23:00 PM

0


"Igor Bolschewski" <angrycoder@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.

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

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

F*CK

9/4/2010 4:28:00 PM

0

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.

"Schmidt" <sss@online.de> wrote in message
news:i5trnn$3b9$1@speranza.aioe.org...
|
| "Igor Bolschewski" <angrycoder@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.