[delete]

I'm pretty new to OSX and wonder how safe are haxies and do they affect system performance any?
I've been using Mighty Mouse/Fruit Menu/ASM and a couple of others (I don't know if Candy Bar is considered a haxie).

Thanks

[Basilisk]

The short answer is that it depends, but generally yes they affect performance and potentially stability. The long answer is below...

Haxie is a very specific term, used by the folks at Unsanity for their products. Most of Unsanity's "haxies" are modules for their Application Enhancer system (APE), which is basically a system for runtime patches to MacOS X. So effectively the term "haxie" is usually only applied to APE modules from Unsanity themselves.

There are some third party APE modules which use Unsanity's APE system, but are not usually called "haxies". In fact I'm not certain that "haxie" may not be a trademarked term for Unsanity's products.

The remaining examples you give (ASM, and CandyBar) are not "haxies" in either sense, they are not APE modules and they are not made by Unsanity.

So now that we're clear on terms, here's the real answer:

- APE modules from Unsanity and others definitely have an impact on performance, and may have an impact on stability.

The performace aspect is increased application launch times by 30-40 milliseconds. This is a known issue, and Unsanity are working on it. See this article on their blog for info: http://www.unsanity.org/archives/000155.php

The stability issue is more complicated as it depends on what the APE module does (APE modules can do practically anything). APE modules which have wide ranging effects on the system (like FruitMenu and WindowShade) can have wide ranging effects on stability. A bad APE module can crash or interfere with many applications (though not the system as a whole). A narrowly targetted APE (like iChatEnhancer) on the other hand, can usually only affect the stability of the app it patches.

That said, I and many many others use FruitMenu and other APE modules. Unsanity's stuff is very well written, and I haven't had a single stability problem using them. More info on this at: http://www.unsanity.com/haxies/ape/

- Stuff like ASM (which is technically a NSMenuExtra) have no more performance impact than running any other application all the time. From a stability standpoint their effects are limited to the stability of the application itself (ie. only the app can crash, not the whole system). NSMenuExtras are a special case in that they are actually plugins to the SystemUIServer application. If ASM crashed (it never has for me) it would crash SystemUIServer, taking all the other MenuExtras down with it, but SystemUIServer will automatically restart shortly thereafter, and the system will stay running.

- I'm not sure how CandyBar works, but I suspect its like the various "theming" tools. These usually patch system resource files with their own versions of the icons, windowbars, etc. These should not in principle affect stability, but in practice they do. Searching these forums will give examples of folks who have stability problems after installing themes. The problem here is that the resources patched by these tools are not officially documented by Apple, and Apple occassionally moves them around during system upgrades. So older tools and theme files will sometimes break newer OS versions. Usually these bugs are addressed quickly by the theming tool authors, so you best defense is to make sure to keep up to date on the latest version of these tools.

Hope this helps,

Bas

[delete]

I'm glad you mentioned theming because on top of the various haxies, programs etc. I run a theme called Rhapsodized. Everything so far has worked without a hitch, but it's good to know what exactly these things do (and what they're called).

Thanks for such a complete answer.

[Anomalous]

Originally posted by Basilisk:
The short answer is that it depends, but generally yes they affect performance and potentially stability. The long answer is below...

Haxie is a very specific term, used by the folks at Unsanity for their products. Most of Unsanity's "haxies" are modules for their Application Enhancer system (APE), which is basically a system for runtime patches to MacOS X. So effectively the term "haxie" is usually only applied to APE modules from Unsanity themselves.

There are some third party APE modules which use Unsanity's APE system, but are not usually called "haxies". In fact I'm not certain that "haxie" may not be a trademarked term for Unsanity's products.

The remaining examples you give (ASM, and CandyBar) are not "haxies" in either sense, they are not APE modules and they are not made by Unsanity.

So now that we're clear on terms, here's the real answer:

- APE modules from Unsanity and others definitely have an impact on performance, and may have an impact on stability.

The performace aspect is increased application launch times by 30-40 milliseconds. This is a known issue, and Unsanity are working on it. See this article on their blog for info: http://www.unsanity.org/archives/000155.php

The stability issue is more complicated as it depends on what the APE module does (APE modules can do practically anything). APE modules which have wide ranging effects on the system (like FruitMenu and WindowShade) can have wide ranging effects on stability. A bad APE module can crash or interfere with many applications (though not the system as a whole). A narrowly targetted APE (like iChatEnhancer) on the other hand, can usually only affect the stability of the app it patches.

That said, I and many many others use FruitMenu and other APE modules. Unsanity's stuff is very well written, and I haven't had a single stability problem using them. More info on this at: http://www.unsanity.com/haxies/ape/

- Stuff like ASM (which is technically a NSMenuExtra) have no more performance impact than running any other application all the time. From a stability standpoint their effects are limited to the stability of the application itself (ie. only the app can crash, not the whole system). NSMenuExtras are a special case in that they are actually plugins to the SystemUIServer application. If ASM crashed (it never has for me) it would crash SystemUIServer, taking all the other MenuExtras down with it, but SystemUIServer will automatically restart shortly thereafter, and the system will stay running.

- I'm not sure how CandyBar works, but I suspect its like the various "theming" tools. These usually patch system resource files with their own versions of the icons, windowbars, etc. These should not in principle affect stability, but in practice they do. Searching these forums will give examples of folks who have stability problems after installing themes. The problem here is that the resources patched by these tools are not officially documented by Apple, and Apple occassionally moves them around during system upgrades. So older tools and theme files will sometimes break newer OS versions. Usually these bugs are addressed quickly by the theming tool authors, so you best defense is to make sure to keep up to date on the latest version of these tools.

Hope this helps,

Bas

Good description! See, people with low post counts sometimes do make excellent posts.

[gorickey]

Agreed, that was one good insightful post filled with 100% correct information.

[-Q-]

Originally posted by Anomalous:
Good description! See, people with low post counts sometimes do make excellent posts.

Post count is certainly not the only qualifier to providing good answers.

I nominate Basilisk's response as "Best Reply on a Wednesday."

[smeger]

Basilesk gave a great answer.

To add a personal perspective, I'm the author of Mighty Mouse and iChat Enhancer. iChat Enhancer is really simple code, so it's fairly "raw". If I managed to get something wrong in the 20+ lines of code that it consists of, it would crash iChat, but wouldn't affect the rest of the system (iChat Enhancer's code is only loaded into iChat, so I don't need to worry about other apps).

Mighty Mouse, on the other hand, is loaded into all running apps, so it needs to be more robust, as a mistake could take down all of your applications. The APE portion of Mighty Mouse consists of roughly 2/3 error-checking code to 1/3 functional code. That is to say, the majority of the code is dedicated to making sure that conditions are as I expect them to be, and bailing gracefully without affecting the application if they're not.

APEs don't seem to have too much impact on system performance (this depends on the APE, of course). Application loading time is increased on the order of 100 (micro or milli, can't remember which) seconds, which ain't too big of a deal. Unsanity is, as Basilesk pointed out, working on decreasing this.

I believe also that "Haxie" is an Unsanity tradeword, and only their APE modules can legally use the term.

[delete]

So just out of curiosity when I read something that says using using the Unsanity haxie Shadow Killer will help speed up things a bit, is that gain just offset by the fact that the system is being taxed a bit by using it in the first place?

Just wondering.

[Basilisk]

Thanks for the postive feedback folks

delete So just out of curiosity when I read something that says using using the Unsanity haxie Shadow Killer will help speed up things a bit, is that gain just offset by the fact that the system is being taxed a bit by using it in the first place?

In the era when ShadowKiller was most relevant it made a considerable difference in performance. The improvement certainly offset any slowdown from the APE itself.

These days I'm not so sure that ShadowKiller makes much of a difference. Since the introduction of Quartz Extreme transparency effects like window shadows have mostly been offloaded to the graphics card (assuming of course your machine supports QE) and so the shadows may not make as much of an impact.

I'm sure someone who's tested ShadowKiller more extensively on a QE Jaguar machine can answer better. As for me, I dropped ShadowKiller pretty quickly. Since MacOS X windows are borderless running without shadows can make it hard to distinguish window edges, which I find too annoying to live without shadows, slowdown or not.

Bas