Can you do system wide hooks in .Net?

  • Thread starter Thread starter Jim Hubbard
  • Start date Start date
J

Jim Hubbard

I don't think you can hook system events outside your application in .Net
without using an unmanaged DLL, but I thought I'd ask.

Jim Hubbard
 
That's right. You have to use Win32 API (through P/Invoke).

I don't think you can hook system events outside your application in .Net
without using an unmanaged DLL, but I thought I'd ask.

Jim Hubbard
 
Thanks for the confirmation.

BTW, it seems to me that Windows can never be fully .NEt....that some
unmanaged code will always be required to do things that managed code just
can't.

Isn't that a step backwards?

Jim Hubbard
 
Jim Hubbard said:
Thanks for the confirmation.

BTW, it seems to me that Windows can never be fully .NEt....that some
unmanaged code will always be required to do things that managed code just
can't.

To an extent, thats true, however the number of things that are actually
only possible in unmanaged code are *extremely* small. Many things, like
hooks, etc, require pinvoke simply because windows hasn't exposed managed
interfaces to the functionality. It will be a while.
Most of what can't be done with managed code is stuff that any normal user
will never do. I don't think I will be writing a driver for anything in the
near future, nor do I need kernel mode access to anything(and though it may
be possible for .NET to operate at kernel mode, I wouldn't be surprised if
it never does). As it is I never write down to that level in C++, so why
should I be upset if C# doesn't let me?

And more to the point of your question, system hooks are pretty limited from
a managed language like C#. You can implement a certain subset, but I think
all you can do *globally* is keyboard and mouse hooks. Everything else
requires a dll that can be loaded by the OS seperatly, so you have to be
able to write atleast those entry points in unmanaged code. You can probably
do it with mixed C++, but I do not think it is possible from C# or VB.NET.
 
I agree with Daniel. Unmanaged code is still required for functionality that
have not been yet exposed to the managed world through the framework.

Thanks for the confirmation.

BTW, it seems to me that Windows can never be fully .NEt....that some
unmanaged code will always be required to do things that managed code just
can't.

Isn't that a step backwards?

Jim Hubbard
 
Daniel O'Connell said:
To an extent, thats true, however the number of things that are actually
only possible in unmanaged code are *extremely* small.

Small in number, but big in the OS......like Remote Desktop and Remote
Assistance. These cannot be done purely in .Net.
Many things, like
hooks, etc, require pinvoke simply because windows hasn't exposed managed
interfaces to the functionality. It will be a while.

So you think it can be done in .Net? Exposing the OS to hooking and across
the whole system would violate the memory management features in .Net.

It just looks to me like .Net is a giant step backwards in capability. Sure
it's faster to write code.....but it's less capable and less secure than
what we had.
Most of what can't be done with managed code is stuff that any normal user
will never do. I don't think I will be writing a driver for anything in the
near future, nor do I need kernel mode access to anything(and though it may
be possible for .NET to operate at kernel mode, I wouldn't be surprised if
it never does). As it is I never write down to that level in C++, so why
should I be upset if C# doesn't let me?

You shouldn't. But those of us that do that sort of thing are.
And more to the point of your question, system hooks are pretty limited from
a managed language like C#. You can implement a certain subset, but I think
all you can do *globally* is keyboard and mouse hooks. Everything else
requires a dll that can be loaded by the OS seperatly, so you have to be
able to write atleast those entry points in unmanaged code. You can probably
do it with mixed C++, but I do not think it is possible from C# or VB.NET.

Just thought I'd ask to amke sure I wasn't missing anything.

Thanks for your help.

Jim Hubbard
 
Back
Top