Re: System-wide hooking, VB+ASM

Paul Clement wrote:
> On Wed, 1 Jun 2005 09:44:49 -0600, "Jonathan Wood"
> <jwood@xxxxxxxxxxxxxxxx> wrote:
>
> Jonathan,
>
> ¤ > You may be able to find any number common attributes, in
> particular
> ¤ because we're talking about a
> ¤ > type of Windows PE, specifically a DLL.
> ¤
> ¤ Exactly.
> ¤
> ¤ > However, for whatever reason, you seem to want to
> ¤ > marginalize the differences in the implementation between a COM
> and
> ¤ non-COM DLL.
> ¤
> ¤ No, I just know that adding COM functionality to a DLL does not
> change the
> ¤ underlying architecture. It only adds something more.
> ¤
>
> Interesting point,

The very one I made earlier, btw.

> but with respect to Visual Basic, COM *is* the
> underlying architecture that has been implemented.

No, COM is the *overlying* architecture, added for VB's benefit.

> ¤ > I think it's rather obvious that an ActiveX DLL doesn't implement
> the same
> ¤ standard Windows DLL
> ¤ > calling convention.
> ¤
> ¤ Well, the underlying architecture implements exactly that when
> exporting COM
> ¤ functionality. Only by using a high-level language such as VB is
> that hidden
> ¤ from us.
> ¤
>
> Once again, it's the COM implementation which defines the underlying
> architecture

LOL! Without the baseline "underlying architecture", COM wouldn't be possible. You
got yer chickens before yer eggs, man.

> and the mechanism by which the functionality is made
> available.

Again, wrong. The functionality is made available by standard exports that, when
called, register the COM elements with the system.

> The fact that it follows a minimum level of standards for
> a Windows PE doesn't really tell me much,

Clearly.

> ¤ For this thread, it was stated (not by you) that VB DLLs could not
> be used
> ¤ for system-wide hooks because they were not regular DLLs.
> Certainly, in that
> ¤ context, the statement is false.
>
> Can't say I've ever been able to create a system wide hook with
> Visual Basic, so I'm assuming you're referring to using some type of
> extension which enables you to do so.

And here we are, full circle. Why do you think you'd need to use an extension? What
would said extension provide that isn't "in the box" already?
--
Working Without a .NET?
http://classicvb.org/petition


.

Relevant Pages

  • Re: Problem using a UNC Path within a COM component in asp.net
    ... If you write a VB6 app, does the dll work with the string? ... I have granted permissions on the FileServer to ... ¤ I would appreciate any help that would shed some light on this problem... ...
    (microsoft.public.vb.general.discussion)
  • Re: System-wide hooking, VB+ASM
    ... ¤> What would you call a non-COM DLL? ... just so we understand that an ActiveX DLL is not a non-COM DLL (or ... ActiveX DLLs are not the same as native Windows DLLs. ... Any DLL can export COM functionality, flat function functionality, or both. ...
    (microsoft.public.vb.winapi)
  • Re: System-wide hooking, VB+ASM
    ... ¤> ¤ Windows DLL? ... or what others refer to as "standard" Windows DLL, which is absent of a COM implementation. ... ActiveX DLL in Visual Basic. ...
    (microsoft.public.vb.winapi)
  • Re: Problem using a UNC Path within a COM component in asp.net
    ... If you write a VB6 app, does the dll work with the string? ... I have granted permissions on the FileServer to ... ¤ I would appreciate any help that would shed some light on this problem... ...
    (microsoft.public.vb.general.discussion)
  • Re: System-wide hooking, VB+ASM
    ... ¤ standard Windows DLL. ... but to omit the fact that it's an ActiveX DLL would be imprecise - especially if ...
    (microsoft.public.vb.winapi)
Loading