[Basilisk]

This is just not true. Yes, plug-ins can crash the app, since they live in the same memory space. But, it is not true that all plug-ins have unlimited power. The reason you're able to do this with InputManagers is because of the dynamic nature of the Cocoa runtime, and because the things are run early enough in the loading process to override things using poseAsClass: and the like. With any other type of plug-in, for example a QuickTime codec, running in plain old C or C++, you'd be more limited in what you could do.

What?!?

It is true its easier doing some style of patching using poseAsClass and the like, but its not the only way to do it. In fact, poseAsClass is typically an ineffective way of doing things because you have to pose so early. Its much easier to patch the underlying C calls either directly (by patching a C framework entry point) or by patching the selector you want and replacing it with a new function (again in C).

You can patch almost any C function you can see from the plugin (which is effectively anything). Check out the docs for NSLookupAndBindSymbol and NSAddressOfSymbol (which despite their NS prefixed names apply to any mach-o binary).

Note that the Dock is essentially all C/C++ Carbon and folks patch around in there quite a bit (its a popular target for hacking).

Alex

[CharlesS]

Originally posted by Basilisk:
What?!?

It is true its easier doing some style of patching using poseAsClass and the like, but its not the only way to do it. In fact, poseAsClass is typically an ineffective way of doing things because you have to pose so early. Its much easier to patch the underlying C calls either directly (by patching a C framework entry point) or by patching the selector you want and replacing it with a new function (again in C).

You can patch almost any C function you can see from the plugin (which is effectively anything). Check out the docs for NSLookupAndBindSymbol and NSAddressOfSymbol (which despite their NS prefixed names apply to any mach-o binary).

Note that the Dock is essentially all C/C++ Carbon and folks patch around in there quite a bit (its a popular target for hacking).

Alex

Objective-C gives you almost unlimited access to everything - you can basically mess with anything at runtime. I didn't say poseAsClass: was the only way to do it, but it is a good example of how hackable Cocoa is since you can get total control over an object's behavior by forcing everything to use your subclass if you can load your code early enough. You generally don't see QuickTime codecs that change menu behavior or whatnot. If it were as easy to do, I should think people would do it. We see this stuff all the time in Cocoa through the use of things like InputManagers. If all the various things you can do to mess with the Cocoa runtime can be done with plain C apps, that would really surprise me, but since you deal with this sort of things more often than I, I'll take your word for it.

The fact remains, of course, that the vast majority of plug-in writers do not do this, and it is still completely out of spec and violating what the plug-in is supposed to do. Furthermore, since the application developer has designed his program to handle plug-ins, he at least has had the foreknowledge so that he can avoid making assumptions about things that might change when a plug-in is brought into the equation (barring the plug-in messing with the linker API's to go in places where it shouldn't). So, regardless of what can or cannot be done with a plug-in, it is still not the same situation as an APE because the fact remains that the programmer has willingly allowed the bundle in, whereas with an APE it has forced its own way in.