Haxies, Input Managers. How do they work?

[grotsasha]

the thing that puts me off trying fruitmenu, is that it's a haxie. as a macuser since system 7,5 who spent years wrestling with extension conflicts and random crashes, the introduction of OSX has made me a bit evangelical about not "tampering" with core system code. :lol:

I agree. I don't like to mess my system with haxies either. But it seems that Unsanity products are quite stable. Here is what Steve Gehrman thinks about it:

The programmer at Unsanity is insanely brilliant and I trust his code 100%.

In fact we have a piece of Unsanity code in our PF 4.0.1 installation (SmartCrashReporter). But it will no more be there in version 4.0.2. Details here (http://daringfireball.net/2006/01/smart_crash_reports/url)

[BrentN]

You also have to understand that Smart Crash Reporter is not a haxie. It is an Input Manager. There is a world of difference between how Unsanity's APE system, which is used in the 'haxies' and Input Managers work.

[grotsasha]

Ok, thanks for pointing this out. In fact I didn't read the article attentively enough and came to a conclusion that all Unsanity haxies are also Input Managers. I'll read some information on how APE works to get it clear for me.
But the Unsanity programmer still stay brilliant after that... :)
Anyway the FruitMenu is the only haxie on my system and it seems to cause no problems until now.

-------------------------

Ok, I read about APE on the Unsanity page. They say the following:

Once loaded, the APE module performs the needed modifications on the launched application memory space. Application Enhancer operates in user memory space

So isn't it the same procedure as Input Manager (like Smart Crash Reporter) follows? (Though I understand that Smart Crash Reporter doesn't need APE to function)

[BrentN]

Not precisely. Apple provides the hooks that allow Input Managers to run, limiting their access to certain parts of the system.

APE patches more indiscriminately. What it does is looks for calls to certain functions and overrides them with their own code. This is how Default Folder works, for example. By patching calls to, e.g. NSOpenPanel and NSSavePanel, Default Folder can display its little button window only when those routines are run. (Default Folder, however, does not use APE, but mach_inject, an open source competitor.)

[grotsasha]

Oh, that's definitively doesn't look good... :?
And if this part of code in the original programm is updated... :? :?
I see why I should disable all haxies, before a system update... And enable them with great care then!
Thanks for taking time to respond. I've learned something today.

[BrentN]

Oh, that's definitively doesn't look good... :?

This is why a lot of developers have a jaundiced view of the APE. Often, they take the blame for crashes and other issues that arise from interactions between APE and their application.

Rosyna, one of the Unsanity developers, has forcefully (almost comically so) pointed out that most of these issues are actually bugs in the host application that are not being discovered and are thus not Unsanity's fault. A more realistic view is that developers cannot properly regress these faults and that Unsanity is exacerbating what might be a minor issue into a major one.

It is of note that the early versions of APE did not have an "exclude list," so clearly the folks at Unsanity are sensitive to the issue, despite Rosyna's vociferous words on the matter.

Any time you hack your system, you are making a cost-benefit decision. Is the functionality you are receiving worth the potential conflicts and instabilities it might cause. For me, that answer is "yes" for Default Folder, but "no" for any of Unsanity's largely cosmetic hacks. For you, or for anyone else, the decision might be different.

[BrentN]

Also -

I've never written an Input Manager, so I'm not sure how much latitude Apple gives developers with that API. I was at MacHack and listened to Jon Gotow and Wolf Rentsch and others discuss what was to become mach_inject (which itself grew out of a tool called libPatch,) so I've got a good idea of how that works and I've toyed with mach_inject myself as a learning exercise.

Its a shame that MacHack is no more. I learned more about how to squeeze the most out of MacOS there than I have anywhere else. I also was the closest I've ever been to caffeine poisoning too. :)