DLL fight

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?

0
Igor
9/4/2010 7:44:22 AM
vb.general.discussion 1016 articles. 0 followers. Follow

53 Replies
1293 Views

Similar Articles

[PageSpeed] 33

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" <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?
| 


0
Abhishek
9/4/2010 8:08:07 AM
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-manifest.html
>
>
>
> "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?
> |
>
>

0
Igor
9/4/2010 8:52:06 AM
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?

0
mscir
9/4/2010 9:02:51 AM
"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


0
Schmidt
9/4/2010 9:55:01 AM
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
>
>

0
Igor
9/4/2010 10:11:23 AM
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


"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? 


0
Abhishek
9/4/2010 10:59:09 AM
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?
|


0
Abhishek
9/4/2010 11:02:42 AM
  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.



0
Mayayana
9/4/2010 1:14:59 PM
"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.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



0
Schmidt
9/4/2010 4:23:16 PM
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.


0
Abhishek
9/4/2010 4:27:44 PM
"Schmidt" <sss@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. 

0
Bob
9/4/2010 5:45:25 PM
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.


> "Schmidt" <sss@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.

0
Igor
9/4/2010 8:01:08 PM
  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.


| 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 


0
Mayayana
9/4/2010 8:29:44 PM
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.



0
Nobody
9/4/2010 8:57:38 PM
Thanks, that looks like what I need for a first start!


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

0
Igor
9/5/2010 5:55:59 AM
"Abhishek" <user@server.com> schrieb im Newsbeitrag
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.
Yep, good catch - but as you say, only necessary,
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





0
Schmidt
9/5/2010 7:57:13 AM
"Bob Riemersma" <nospam@nil.net> schrieb im Newsbeitrag
news:ODaizjFTLHA.456@TK2MSFTNGP06.phx.gbl...
> "Schmidt" <sss@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.
Maybe - but I did refer to it as regfree COM or
"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
> what you are doing is not that AT ALL.
Nah, in the end it *achieves* the same thing (for AX-Dlls)
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
> Windows, ...
Yep, and I would trust its lower level approach and
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
> to avoid confusion like that we see when people
> refer to VFred as VB.
As said above, the chronological order really was a
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


0
Schmidt
9/5/2010 8:58:59 AM
"Igor Bolschewski" <angrycoder@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



0
Schmidt
9/5/2010 9:50:41 AM
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.

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.

-- 
   Jim Mack
   Twisted tees at http://www.cafepress.com/2050inc
   "We sew confusion"

0
Jim
9/5/2010 12:54:52 PM
"Schmidt" <sss@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.  :-) 

0
Kevin
9/5/2010 12:56:42 PM
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:
> "Igor Bolschewski"<angrycoder@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
>
>
>

0
Igor
9/5/2010 5:08:48 PM
On Sun, 05 Sep 2010 19:08:48 +0200, Igor Bolschewski
<angrycoder@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.

-ralph
0
ralph
9/5/2010 6:53:37 PM
"ralph" <nt_consulting64@yahoo.net> wrote in message 
news:afp7861ec3t53a0agegqhgog9lg1g6an4h@4ax.com...
: On Sun, 05 Sep 2010 19:08:48 +0200, Igor Bolschewski
: <angrycoder@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. 

0
Kevin
9/6/2010 12:04:12 AM
On Sun, 5 Sep 2010 20:04:12 -0400, "Kevin Provance" <k@p.c> wrote:

>
>"ralph" <nt_consulting64@yahoo.net> wrote in message 
>news:afp7861ec3t53a0agegqhgog9lg1g6an4h@4ax.com...
>: On Sun, 05 Sep 2010 19:08:48 +0200, Igor Bolschewski
>: <angrycoder@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. 

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.

-ralph
0
ralph
9/6/2010 12:43:31 AM
"ralph" <nt_consulting64@yahoo.net> wrote in message 
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.

Not a problem old top.  Occasionally I have a useful purpose or two. 

0
Kevin
9/6/2010 3:00:02 AM
"Kevin Provance" <k@p.c> wrote in message 
news:i60426$5gc$1@news.eternal-september.org...
>
> "Schmidt" <sss@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 

0
Bob
9/6/2010 5:39:53 AM
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 :)

-- 
Dee Earley (dee.earley@icode.co.uk)
i-Catcher Development Team

iCode Systems

(Replies direct to my email address will be ignored.
Please reply to the group.)
0
Dee
9/6/2010 9:56:29 AM
"Dee Earley" <dee.earley@icode.co.uk> wrote in message 
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 :)

Well, you know what they say, accuse others what's true about yourself.


0
Nobody
9/6/2010 10:43:20 AM
"Igor Bolschewski" <angrycoder@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



0
Schmidt
9/6/2010 11:13:13 AM
"Jim Mack" <no-uce-ube@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?

Olaf




0
Schmidt
9/6/2010 11:21:32 AM
After serious thinking Schmidt wrote :
> "Jim Mack" <no-uce-ube@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?
>
> Olaf

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

-- 
ClassicVB Users Regroup! comp.lang.basic.visual.misc
Free usenet access at http://www.eternal-september.org


0
Leo
9/6/2010 11:26:43 AM
On 06/09/2010 12:21, Schmidt wrote:
> "Jim Mack"<no-uce-ube@mdxi.com>  schrieb im Newsbeitrag
> 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?

http://msdn.microsoft.com/en-us/library/ff919712.aspx

-- 
Dee Earley (dee.earley@icode.co.uk)
i-Catcher Development Team

iCode Systems

(Replies direct to my email address will be ignored.
Please reply to the group.)
0
Dee
9/6/2010 12:34:08 PM
  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
|
| -- 
| ClassicVB Users Regroup! comp.lang.basic.visual.misc
| Free usenet access at http://www.eternal-september.org
|
| 


0
Mayayana
9/6/2010 2:03:44 PM
On 06/09/2010 15:05, Schmidt wrote:
> "Dee Earley"<dee.earley@icode.co.uk>  schrieb im Newsbeitrag
> 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.

Erm, yes, I read it in passing a few days ago, then I saw the post here 
and gave a link, forgetting they were separate. My apologies :)

(Oh, and it is she, not he :p)

-- 
Dee Earley (dee.earley@icode.co.uk)
i-Catcher Development Team

iCode Systems

(Replies direct to my email address will be ignored.
Please reply to the group.)
0
Dee
9/6/2010 2:05:16 PM
"Leo" <ttdhead@gmail.com> schrieb im Newsbeitrag
news:i62j47$la0$1@news.eternal-september.org...
> After serious thinking Schmidt wrote :
> > "Jim Mack" <no-uce-ube@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/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

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



0
Schmidt
9/6/2010 2:05:31 PM
"Dee Earley" <dee.earley@icode.co.uk> schrieb im Newsbeitrag
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?

Olaf


0
Schmidt
9/6/2010 2:05:31 PM
| 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. 


0
Mayayana
9/6/2010 2:13:35 PM
"Dee Earley" <dee.earley@icode.co.uk> schrieb im Newsbeitrag
news:OQfGy0cTLHA.5716@TK2MSFTNGP02.phx.gbl...

> (Oh, and it is she, not he :p)

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

Olaf


0
Schmidt
9/6/2010 2:46:29 PM
"Mayayana" <mayayana@invalid.nospam> wrote in message 
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.
>
No, I really do think that goes far beyond fair play.  Lots of hitting below 
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. 

0
Bob
9/6/2010 3:09:30 PM
Mayayana formulated on Monday :
>> 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. 

BS.

-- 
Tom Shelton


0
Tom
9/6/2010 3:42:20 PM
"Bob Riemersma" <nospam@nil.net> skrev i meddelandet 
news:eCd$sXYTLHA.5716@TK2MSFTNGP02.phx.gbl...
> "Kevin Provance" <k@p.c> wrote in message 
> news:i60426$5gc$1@news.eternal-september.org...
>>
>> "Schmidt" <sss@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

Sad sad... and I guess your'e not smart enough to feel ashamed for that 
post...

/Henning


0
Henning
9/6/2010 7:48:02 PM
"Schmidt" <sss@online.de> wrote in message 
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
:

I made the same mistake once.  :-)

Anyone who shuns political correctness is A-OK in my book.  Cheers! 

0
Kevin
9/6/2010 8:20:41 PM
"Dee Earley" <dee.earley@icode.co.uk> wrote in message 
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 :)

Bill McCarthy.  Everything after that was trolling.  They didn't even get my 
phone number right.  ;-) 

0
Kevin
9/6/2010 8:27:28 PM
"Nobody" <nobody@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? 

0
Kevin
9/6/2010 8:28:11 PM
| >   Kevin might be a bit coarse and insensitive sometimes,
| > but he's not deliberately malicious.
|
| BS.
|
  Happy Labor Day, Tom. Nice to see that you're your
usual cheery self. :) 


0
Mayayana
9/6/2010 10:05:28 PM
"Kevin Provance" <k@p.c> wrote in message 
news:i63iss$ghe$1@news.eternal-september.org...
:
: "Nobody" <nobody@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?
:

Yeah, that's what I thought. 

0
Kevin
9/6/2010 11:53:04 PM
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.


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

0
Igor
9/7/2010 5:29:24 AM
Schmidt wrote:
> "Jim Mack" schrieb...
>> 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?

The reporting was somewhat confused. Because most programs either
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.

-- 
   Jim Mack
   Twisted tees at http://www.cafepress.com/2050inc
   "We sew confusion"

0
Jim
9/7/2010 10:03:05 AM
|
| 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
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. 


0
Mayayana
9/7/2010 1:23:00 PM
Schmidt has brought this to us :
> "Dee Earley" <dee.earley@icode.co.uk> schrieb im Newsbeitrag
> 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?

That's always been my understanding, yeah.

-- 
..NET: It's About Trust!
http://vfred.mvps.org


0
Karl
9/7/2010 9:34:42 PM
"Kevin Provance" <k@p.c> wrote in message
news:i63iss$ghe$1@news.eternal-september.org...
>
> "Nobody" <nobody@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
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.







0
Nobody
9/8/2010 4:06:47 AM
"Nobody" <nobody@nobody.com> wrote in message 
news:i6725o$29o$1@speranza.aioe.org...
> "Kevin Provance" <k@p.c> wrote in message
> news:i63iss$ghe$1@news.eternal-september.org...
>>
>> "Nobody" <nobody@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

  Can't even turn on some of the features of my DroidX phone without google 
knowing exactly where I'm at..  )-:

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


0
mbyerley
9/8/2010 11:43:53 AM
|  Can't even turn on some of the features of my DroidX phone without google
| knowing exactly where I'm at..  )-:
|

  You mean like the feature to report to the
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. 


0
Mayayana
9/8/2010 1:06:42 PM
Reply:

Similar Artilces:

LNK2019 error when trying to export class from dll
I am creating a DLL using MS VStudio C++ 2003. I have created a class in the DLL that I am wanting to export. Everything compiles with the exception of getting a linker error 2019 related to the constructor and destructor. I have 2 functions that are not a part of the class that are exported, one that returns a pointer to the class and the other which destroys the object. I have defined DLL_EXPORTS in the project settings- >preprocessor. Can someone Tell me what the problem is? I am posting the header file below along iwth the source. any help is greatly appreciated. BTW...I am new...

MFC DLL Dialog Box
Hello All, I am trying to link a MFC DLL to a MFC executable. The MFC DLL has a dialog template in it and has one entry point function in it. Dialog box template has the corresponding class as CLoadDlg. >From the executable I call the entry point function. Everything is working fine till this point. Now in entry point function I am creating a dialog box object and trying to display the dialog box (by calling DoModal). But this is not working and I see an assertion failure. Can someone give me some hints on how to get this dialog box up from the DLL. In DLL: ======= extern "C" ...

Can't open Outlook Express...reason MSOE.DLL could not be loaded
Would appreciate any help! Send to my email address. Thanks!! "Jan" <jemccright@iwon.com> wrote in message news:1f89501c4587d$ff2f6930$a601280a@phx.gbl... > Would appreciate any help! Send to my email address. > Thanks!! This newsgroup is for support of Outlook 97/98/2000/2002/2003 from the Office suite of products. Outlook Express is actually a separate program despite the similar name. For help with your OE questions, try an OE newsgroup such as microsoft.public.windows.inetexplorer.ie6_outlookexpress (for OE 6), or an OE help website such as http://insideOE.tomst...

How to create *.lib from DLL and a header file.
Can I create a import library for DLL ( no source code ) and a header file ? GetProcAddress() is working fine, but I need to generate *lib file for my project. Regards, Kamil Try the following batch file to create the import library. echo EXPORTS > YourDll.def for /f "skip=19 tokens=4" %i in ('link /dump /exports YourDll.dll') do echo %i >> YourDll.def link /lib /def:YourDll.def /out:YourDll.lib -- Cheers Check Abdoul [VC++ MVP] ----------------------------------- "kamil" <kamildobk@xxxpoczta.onet.pl> wrote in message n...

crdb_odbc.dll
Hello: I know that it may be heresy, my asking about two competitive products on this board. But, I created a payables report in Crystal 9.0 yesterday and it will not refresh when run in Citrix. When refreshing, I get the following error: "The database object crdb_odbc.dll cannot be loaded". It does refresh if I do not launch it in Citrix. All of those that I know with Crystal expertise do not have any ideas on how to get rid of this. Any ideas? childofthe1980s I am guessing Crystal is installed directly on the on Citrix server? Are other Crystal reports working or is...

Use Dll created from .Net
Can I use a dll created from .Net in a Visual C++ 6.0 project? ...

Finder vs.Outbak.dll -- 2
.... FINDER caused an invalid page fault in module OUTBAK.DLL at 018f:01a65468 Also, when the .psf backup dialog box runs, a dos window runs in the background... Someone previously posted this - I have the same issue. Does anyone have a clue as to why this happens and how to correct it? Of course, there is nothing in the MS Lack of Knowledge Base! -- Message posted via http://www.officekb.com ...

Shared memory not being shared in dll
I'm creating a DLL with a data segment of READ WRITE SHARED I have two different application that reference this shared memory. The first application starts and sets the memory to some values, the second application starts and it seems to have its own set of the memory that I'm trying to share. This is how I'm using the section #pragma data_seg (".Outlook") BOOL bInitialized; #pragma data_seg() And when I link I'm using /SECTION:.Outlook,RWS Any ideas why its not shared ? Thanks! -- Michael Tissington http://www.oaklodge.com http://www.tabtag.com On Mon...

Error loading Publisher on XP -- MDT2DBUI.DLL
I loaded Publisher 2000 (on the second CD-ROM of Office2000) onto my XP laptop with no problem. But when I repeatedly try to load Publisher onto my new XP desktop from the same set of CD-ROMs, it reports an error reading a DLL on the CD-ROM. This DLL is called MDT2DBUI.DLL. The error it gave me is viewable at : http://www.improventures.com/publisher/errormessage.htm It gives the location where this file should have been found and accessed on the CD-ROM. I used Windows Explorer to look at the CD-ROM and I can see that the file is right where the error message says it's suppos...

Can I call FireEvent From Qsrules (DLL)
Please Someone to tell me , Can I call FireEvent such as PerformAddItem >From My DLL using Qsrules , Please Sample code For me thanks you That can only be done via the HTML windows. To add an item via hook the command would be Session.Transaction.Entries.Add(ItemID, ItemLookupCode, 1, 0, False, 0) hope this helps. Victor Lopez Computer Technical Systems victor@ctsrmspos.com "falunkai@hotmail.com" wrote: > Please Someone to tell me , Can I call FireEvent such as PerformAddItem > >From My DLL using Qsrules , Please Sample code For me thanks you > > ...

missing DCCEXT32.DLL and SBCMSYNC.DLL
After installing windows office xp for students and teachers on a brand new PC, and downloading cumulative updates from Office Update, I get the following messages when starting Outlook: First: The add-in "DCCEXT32.DLL" could not be installed or loaded. The problem may be resolved by using detect and repair on the help menu. Second: The add-in "C:\program files\microsoft office\office\sbcmsync.dll" could not be installed or loaded. The problem may be resolved by using detect and repair on the help menu. This worked fine when I first installed it (prior to up...

Regular or Extension DLL?
Hello World! I'm trying to decide if I need to create an MFC Extension DLL, or just a regular DLL that links dynamically to MFC. It all hinges upon whether I can call methods on MFC objects that are owned by the EXE from the DLL as long as the pointer to the object remains physically within EXE code. For instance: If the DLL calls a function in the EXE, and an MFC object pointer is used inside that function being called, is that okay, as long as the pointer does not get called directly from DLL code? Thank you very much, Rich. That depends on how the DLL / EXE &q...

mso9.dll files
I keep getting a message that my mso9.dll file is missing on my laptop. When I search for it, it appears where it is supposed to be (I verified it on my desktop). I am at a loss as to why it is happening. Every time that I click on my reminders (snooze or dismiss) I get the message; I also get it on sending emails. Message says "This application has failed to start because MSO9.DLL was not found. Re-installing the application may fix this problem." I just tried it on Data Management as well. I uninstalled Office XP and re- installed it. HELP! Jay, First, make sure yo...

HOWTO: Notify owner from a DLL?
Hi, I have an MFC based dialog app that is used to control external devices over a standard, RS-232 serial com port. The serial port code creates a secondary thread to handle incoming bytes and notifies the parent dialog when data is received by using ::PostMessage. Everything works great. Now I want to put the functionality of the dialog app into a DLL. But I have never created a DLL so here are some basic questions. 1. If I want the DLL to be useable by clients that are non-MFC, is it correct that I should create a regular DLL (as opposed to an extension DLL)? 2. I would prefer to sta...

DLL tell what type of application is running.
I'm writing a general purpose error handler that will be used by Windows Apps, Web Apps, Window's Services, ... In other words - just about any program will be calling it. Part of this error routine would be to put up a message box if it's a windows app but only if it's a windows app. How can I make sure that the application that is running is actually a Window's app. I currently am passing in parameters to display the message if appropriate but I want to make sure that somebody doesn't by accident call the routine with a message to display for something ...

FILE NOT FOUND: VBA6.DLL #2
Everytime I open excel (MS Office Professional 2000), I get the following error: "File Not Found: VBA6.DLL" The error pops up after excel opens but before the spreadsheet is displayed. Once I click "OK", then the spreadsheet grid appears. Any ideas? ...

Passing pointer between DLL boundary question
Hi This may be a stupid question, but I want to make sure my understanding is correct. I understand that allocating a memory inside a DLL and freeing the memory in the program that uses the DLL (or vice versa) is not a good idea, but if a pointer passed between a DLL boundary is allocated and freed at the correct place, is the code guaranteed to be safe? For example: 1. In dll implementation code: static const char someString[] = "a string"; void GetString(const char** ps) { if(ps) *ps = &(someString[0]); } And in application code: const char* aString; GetStri...

DLL Path in Visual Studio 2008 Orcas
Dear Team, I have a custom build library that whose functions are to be called in the application. I included the library path and called the exported functions. The project compiles successfully but at the run time I get a message that required dll is not found. If I copy the dll to the current project working directory, it is recognizing and executing normally. In the project properties, I tried to include the path of dll but could not find the exact field where I need to mention the path. Anyone who is working on Visual Studio 2008 Orcas, kindly provide a pointer to the field where I...

Array Bounds Exception Inside system.xml.dll
Array Bounds Exception inside system.xml.dll. Test data is a dozen GB (available for the asking on CD). Source code follows. Call into system.xml.dll happens at the while statement.. using System using System.Xml using System.Collections // This program reads an ASCII file of XML elements // The output is a list of unique NODE TYPEs // For example, <head> produces head in the output // There is no validation of the XML namespace xmlReaderAp /// <summary /// Summary description for Class1 /// </summary class Class /// <summary /// The main entry point for the...

howto only create a .lib file instead of creating/linking a complete dll
hi all, i have a librariy around here that gets compiled and linked to a dll. at the time of linking, visual studio 6 also creates a .lib file. how can i split that compiling/linking ? what i want to achieve is just only to generate this .lib file (because at that time i cant completly link my libs because of its dependencies) i already tried to export the dsp to a makefile and run: nmake -d mylib.dsp /MAKE "mylib - Win32 release but it seems that this also wants to create a .lib and a .dll file at the same time so i tried to run: nmake -d mylib.dsp /MAKE mylib.lib "mylib - Win3...

PB with OCX control integrated in Dialog in a DLL MFC project
Hi all, I develop a DLL MFC using VStudio 7.0. As soon as i integrate an OCX control in a dialog ressource, the CDialog object linked to this ressource doesn't load. I try modal and modless methods, Nothing happens. Is there an option i've forgotten? Please help ! Is the control properly registered? Does it require a license? Has AfxEnableControlContainer been called? In article <7E9200A5-922F-403C-A33C-2118B318E0D9@microsoft.com>, Flora@discussions.microsoft.com says... > Hi all, > > I develop a DLL MFC using VStudio 7.0. > As soon as i integrate an OCX co...

Passing a C++ 6.0 MFC File stream into a Visual Basic 6.0 dll func
Hello All, I am stuck trying to find a way to open a file in a C++ MFC application (using a stream), write data into it, then call a Visual Basic dll function and pass to it the file stream (or a file stream pointer or a file handle somehow) so that the VB dll functions can write their own data into the same open file. The problem is that Visual Basic 6.0 has no such thing as a file stream. There might be a way to do this using COM, but I do not know much about COM. Are there any guru's reading this that know a way I can pass a stream for an open file back and forth between MFC C...

.dll question
How do I access functions in a .dll from a Visual C++ .exe? Take a look at the following DLL tutorial http://www.flipcode.com/tutorials/tut_dll01.shtml -- Cheers Check Abdoul [ VC++ MVP ] ----------------------------------- "Chris Alanson" <alansonc@pacbell.net> wrote in message news:029a01c38c22$debe0e40$a101280a@phx.gbl... > How do I access functions in a .dll from a Visual > C++ .exe? Thanks Check. >-----Original Message----- >Take a look at the following DLL tutorial > > http://www.flipcode.com/tutorials/tut_dll01.shtml ...

MFC dll and exe porting to 64-bit
Hi I had several MFC Dlls and EXEs (32bit was built in VC6) to be ported to 64-bit. I recompile them using PSDK and VC6 on a 64-bit XP SP2 (amd64) development machine. The problem is, when testing, although they all compiled and built fine, my MFC exe was able to load the dll dynamically and can find the exported functions, BUT the parameters passed when calling the exported function have been messed up. The exported function CreateInstance(char*, char*, int, char*) taking four parameters to create an instance of a dialog, and I got an "Access violation - code c0000005 (first cha...

MSOE.DLL ERROR from latest MS Auto Update
ERROR MESSAGE: Outlook Express could not be started because MSOE.DLL could not be loaded Seems this problem from Win98 is back. I searched the Knowledge base only to find remnants of old operating systems using OE 5.5 or 6.0, nothing for W2K and OE 6.0 After allowing a MS Auto Update to install I now have to versions of this DLL on my system and neither function propperly. Does any one have information how to fix this annoying problem. Regards Rick Im thinnking I got lucky, I attempted a re-install of IE and OE and this worked. Might be a fix for this problem as I have found 17 o...