[Mono-devel-list] Can one "hook" API functions?

Miguel de Icaza miguel at ximian.com
Sat Jan 31 02:00:50 EST 2004


Hello,

   [ I have a tendency of always replying to the same messages that
     Jonathan has already replied, and his answers are always better
     than mine, but today I have something to add ] 

Like Jonathan said, given the criteria you have, the only possible
scenario is to intercept calls to methods in a "MarshalByRef" hierarchy
which specifically allows for this, but this is not a general purpose
mechanism.

It is possible to modify Mono to add a generic hooking feature, and I
encourage people to use Mono to testbed these sort of ideas, because it
is not really hard to do, but it would be a Mono-only feature.


> <snip/>
> > Is there any way in Mono, and hopefully a standard way that will
> > also work on MS .NET, to "hook" system functions/classes?
> > 
> > To be more specific, I want to replace the File and Directory
> > Open/Close/Read/Write classes and methods with my own ones that
> > augment the behaviour of the standard routines, and are transparently
> > available to all programs, old and new, that previously used the
> > standard implementations.
> <snip/>
> 
> No.
> 
> There are only two basic mechanisms to change the behavior of an
> existing function: virtual functions, and delegates (or something using
> delegates, such as an event).
> 
> Both of these require prior planning on behalf of the original class
> author, as functions are non-virtual by default, and delegates/events
> would require that the programmer actually do something to explicitly
> support it.
> 
> Furthermore, even if the functions were virtual, you'd still need to
> make sure that, somehow, the user was creating instances of your class,
> not your base class.  There are design patterns to do this, but for
> anything created directly by the user (Strings, arrays, files, pretty
> much everything) there is no way to substitute your class for the
> original class.
> 
> Why is this the case?  There are likely several reasons, but two that I
> can think of are performance and security.  By ensuring that people can
> only override functions in explicit ways, the runtime can better
> optimize those patterns, helping to improve performance.  And if anyone
> could replace any function, you'd have security holes introduced in no
> time.




More information about the Mono-devel-list mailing list