Right — OK — -init method only because the actual loading of the Input Manager is done via supported mechanisms. Still it is a foreign piece of code modifying a system service in an unsupported fashion.

That is about as innocuous as an unsupported hack can be. But it is still an unsupported hack. It still taints crash reports and taints my work environment. No thanks.

As for detecting memory smashers/crasher, the tools on the system specifically for doing exactly that are far more effective than relying on random behavior. MallocPreScribble/MallocScribble, libgmalloc, zombies, etc…

For InputManagers, you are guaranteed that Foundation, AppKit, Carbon, and CoreFoundation are loaded before the InputManagers are even queried. So linking to any of these will not change the order of initialization or plugin loading at all.

To be pedantic: that is incorrect. While the frameworks might be loaded, all of the classes in said frameworks will not be initialized. Class initialization only happens on first reference. In SCR’s case, the only class referenced in the conditional is NSBundle and that pretty much has to be initialized prior to loading SCR.

So, Yes, SCR is about as safe and low impact as such a product can be. Flog the horse: It is good engineering. But it is an unsupported change to system behavior. It taints my system that raises both reasonable and unreasonable questions in regards to system integrity.

1. Perhaps we should change the executable name to Smart_Crash_Reports_If_This_Is_Not_CrashReporter_SCR_Is_Unrelated_to_the_Crash. Although from experience, people will still blame it for crashes it can’t possibly have anything to do with.

2. Uhm… ok.. that seems rather pedantic. Especially since cocoa itself does more than that. Loading AppKit massively slows down app launches and increases the memory footprint greatly. This is why the Dock doesn’t link to Cocoa, why the Finder doesn’t link to Cocoa, and also why not a single APE we make links to Cocoa (unless it targets only specific applications like iSWAD).

3. Actually, it doesn’t have a +load method, just an -init method. Secondly, if you’re testing for bugs, then wouldn’t every single person having the *same* configuration lead to many uncaught memory smashers? What do you call those bugs that appear and disappear if the environment changes slightly? And if it’s doing that much damage, it sounds like a bug in the Objective-C runtime (which you say may be fixed)

My understanding of haxies is that they often twiddle the system well below the high level frameworks.

Not, really, no. We try to be as high level as possible for everything. For example, Menu Master actually installs Carbon Event Handlers on menus. The lower we go in haxies, the more we have to rewrite them for major OS X updates so we avoid them like the plague. A little effort today can save a lot of effort tomorrow.

As for PhotoShop: If I’m understanding the problem correctly, they have a scripting addition that is required for CS’s operation? Just like an Input Manager, a Scripting Addition is a well supported means of extending a particular subsystem in the system. And just like an IM, an SA can easily step outside of the bounds of that particular interface’s intention and cause major hell (or it could just be written poorly and cause major hell).

Yes, it installs a CFM scripting addition. And a bug somewhere causes nested functions to blow up if the CFM runtime is loaded. Nested functions are deprecated in both gcc and OS X. Yet for some reason, iSync uses them. This is not something Adobe can fix. It’s not something I can fix either. However, it is something that can be worked around, which iSWAD does until Apple fixes the bug.

However, the Scripting Addition “suffers” from all the points you’ve mentioned above. Every single plugin does no matter the plugin API. For InputManagers, you are guaranteed that Foundation, AppKit, Carbon, and CoreFoundation are loaded before the InputManagers are even queried. So linking to any of these will not change the order of initialization or plugin loading at all. SCR links to AppKit, Foundation, and CoreServices (which is linked to by Carbon, so it is guaranteed to be there by the time InputManagers are even looked at).

If an app installs something that is loaded into every app (or every Cocoa app) and that app doesn’t tell the user, it is bad. That is the primary issue.

The reason why this is of concern to me is because I choose to not run a system with any modifications for both personal and professional reasons. Others may not feel the same way.

SCR does load and execute code in every Cocoa app. This does cause change that I find problematic. Three off the top of my head:

- it makes my system work differently than my colleagues. Then I have to waste time explaining that the mystery item in my crash report or otherwise in my debugging environment is somehow benign.

- it ever so slightly increases the memory footprint of every Cocoa application. Not by much, but every page counts and since I am often using my machine to determine benchmarks and track performance metrics, every unaccountable variable is problematic.

- it uses a +load method which will potentially change the order of class initialization or other framework infrastructure. While their shouldn’t be any order dependencies (there have been in the past, but I think they are fixed), it is another change that pushes my system away from working the same as my colleagues.

As for Haxies — sure, Unsanity has put together a great product for managing them. Kudos. My understanding of haxies is that they often twiddle the system well below the high level frameworks.

As for PhotoShop: If I’m understanding the problem correctly, they have a scripting addition that is required for CS’s operation? Just like an Input Manager, a Scripting Addition is a well supported means of extending a particular subsystem in the system. And just like an IM, an SA can easily step outside of the bounds of that particular interface’s intention and cause major hell (or it could just be written poorly and cause major hell).

Anything that modifies the behavior of every Cocoa app on the system is the problem

Installing something that is loaded at launch of any Cocoa app on the system (by that user) is unacceptable, regardless of how well engineered said solution is.

I’m all for user’s having full control over their system. If a user wants to run Haxies

You seem to be going back and forth on your stance, if I’m reading these correctly.

And can you please elaborate on your definition of “modify” as it clearly does not seem to match the standard definition of “change” since you use it in regards to SCR and you can clearly see from the posted source code just exactly what it is doing in “any Cocoa app” which is definitely not changing anything.

And haxies are actually probably one of the least invasive methods. The user can control exactly which applications they want to modify and APE won’t load as root, for security reasons, unlike many other methods (like SIMBL and the like).