MasterCard MarketPlace™
Margin Note: The dangers of haxies in Mac OS X 10.2.x
While Mac OS 9 had an Apple-developed and sanctioned system for extendibility (the Extensions and Control Panel folders), no such add-on architecture exists in Mac OS X. As such, developers have taken to offering "haxies," retrofit modifications that can cause severe troubleshooting problems without the user ever realizing the cause.
Many of these add-ons fall under the APE (Application Enhancer) umbrella. Application Enhancer is a utility which - according to its own documentation - a system "which allows for 3rd party modules to modify and enhance the way applications behave and operate."
The documentation goes on to note "Application Enhancers work on an application level, therefore they do not affect the stability of the underlying system. The technology behind Application Enhancer system has been in research and development for more than 1.5 years now, and many Unsanity haxies (including WindowShade X, FruitMenu, Silk and others) are now using it. The software development kit for developing modules is also available on the Application Enhancer home page."
Unfortunately, we have known since the early days of Mac OS X that individual applications - particularly those that make any modifications to the System folder - can certainly affect the stability and performance of other applications, including the Finder.
Many troubleshooting issues received in the MacFixIt inbox that are at first attributed to a Mac OS X incremental upgrade or a disk permissions problem are actually easily resolved by temporarily removing Application Enhancer and restarting. Though APE itself has rarely been the culprit, individual haxies have been over and over again.
A system can be completely problem-free with multiple installed and active haxies. But if you are experiencing inexplicable glitches in the Finder, disable your haxies as a troubleshooting step.
Feedback? Late-breakers@macfixit.com.
Resources
Safari) since the intro of Jaguar without incident. I find these products
incredibly stable and compatible, especially compared with any of the
theme manager/installers available for OS X. Every single sttempt at
theming OS X, using several generations of theme apps, has resulted in
continual kernal panics on my iBook (likely for the exact reasons cited in
the article).
I've had far fewer problems with haxies than the so called theme
changers. Not only that but if you do have any problems with Unsanities
haxies the installer makes it a simple matter to uninstall the problem
haxie.
I've used Windowshade, Xounds, Fruitmenu, FontCard (new), Tinkertool,
Menu Master (new) and Mighty Mouse for some time now and they've
never given me a lick of trouble. I've checked crash logs and never seen
them involved, not even the APE Manager. Unsanity posts particularly
good software and updates it when needed and alerts you. And the
installer/uninstaller is without compare in its foolproofness. Other
haxies may cause problems with the system stability, but not the ones
from Unsanity. I've been using them since Unsanity had only two or three
available and they were 1.0 releases. And would not hestiate to try a new
one if I felt it offered something unique that Apple had neglected.<p>---<br>Scott Evans Hummel
<br />Phoenix, AZ graphic designer and budding developer
<br />Currently working off the books. Looking for a graphics design or desktop publising job.
Same here. I've found Unsanity to be a reliable vendor. Its APE-based
apps have been stable, useful, and frequently updated. No problems
here (G4 Powerbook, OS 10.2.6).
Using Fruit Menu, Labels X, Silk 1.1, Clear Dock, and (sometime) Mighty
Mouse. No problems whatsoever.
I sincerely doubt haxies are either dreadfully dangerous or totally
benign. I'm afraid the experience is quite similar to extension
problems in 9. (Only there's no Conflict Catcher equivalent)
I personally suspect the combo of Labels X (with something else)
for frequent System crashes (the type requIring reset button
restarts - no crash
report written)..
I'd used Labels X without issue through 10.2.0. without issue.
I then ugraded to 10.2.4 (unfortunately at just about the same time
as upgrading Labels and APE manager, Quicktime, iTunes) So it's
difficult to point fingers. I have several other 3rd party
products(Font Reserve, DragThing, SuperGetInfo, Watson) so it
could be the some combo-issue (I cannot move to 10.2.6 for
assorted reasons, so that won't be my solution).
However, Labels X and/or my current version of APE Manager is
almost surely part of the mix. (I'm almost always sure to have a
crash at some point after I've assigned a Label and APE Manager
is frequently mentioned in crash logs. ) Unfortunately, the crashes
are erractic enough to be difficult to analyze -- my only recourse is
to disable APE Manager and Labels X for at least a week to truly
verify that's the problem.
Lastly, despite my problems, I'm thrilled that there are developers
out there creating some of the most needed system add-ons. No
way I'd slam Unsanity for not creating the worlds first perfect piece
of software. OSX has been a moving target since its inception - its
rather amazing third-party hacks work at all.
Anyway that's my 2cents,
xandra
Finder), how does one "disable your haxies as a troubleshooting step"?
I admit that I've installed more of these things than I can remember and
don't have the knowledge of OS X to know how to disable them.
There are a number of ways to remove or disable haxies. Most of them
are preference panes. If you want to see what you've added to your
system, look at your System Preferences under Other at the bottom of
the window. Some added features will show up in Login Items. The
simplest way to troubleshoot all these is with Alfred, which is the closest
thing I've found to an extensions manager for OS X. With Alfred you can
turn potential troublemakers off for testing purposes or remove them
entirely if you find you have no further use for them. This is much easier
than navigating to the various folders and removing them manually. The
only things Alfred cannot manage are Login Items. If you prefer the
hands-on approach, user added preference panes can be found in the
Library/Preferencepanes folder and/or the ~/Library/Preferencepanes
folder.
---
Don't anthropomorphize computers.
They hate that.
To uninstall Unsanity haxies just run the original installer and click on
the uninstall button.
I tried to uninstall the Menu Extra Enabler because I suspected that it
was the reason why ALL my menu extras disappeared from the right side
of my screen one day--even the Apple ones. (And my machine would
not let me enable any of them from the System Preferences window.)
However, I couldn't delete the program because the trash told me it was
"in use". So, I tried restarting and holding the shift key down while
the status bar was loading up. This did the trick and disabled the Menu
Extra Enabler. I was able to empty the trash...and all my Apple menu
extras reappeared. :-)
Oops... I forgot to mention that I did run the Menu Extra Enabler Installer
and pressed the "Uninstall" option. That was how I got the program to
the trash in the first place.
application authors, including Apple, would listen to their paying
customers and attempt to incorporate those features in future releases.
---
M2/.
I find my APE to be quite polite and Stable running the indispensable Labels x, Windowshade X , Cleardock and my beloved Fruit Menu.
Sylk was another Story:(
So as much as I detest the ubiquitous Lucinda Grande, I could not uninstall Sylk fast enough! Messing with the System font is risky biz.
For this geek chick that translates to a passing the test with a 'B' instead of the 'A'
I Celebrate the fact these Haxies thoughtfully come with an uninstaller! Also, Fruitmenu can be configured to not load for any application as you see fit. Personal choices!
I believe we who aspire to expand our envelope of computing need to accept responsibility for OUR attempts to expand the system- and allow developers space for the experimentation (with the occasional inevitable failed experiment) to DEVELOP without being blasted! This is the environment where the truly expansive, creative brainstorming happens-not in the "SAFE" corporate boardroom.
---
First off, the term 'haxie' is meant to only apply to Unsanity released
application modification software. The general term for things that use
APE is... APE Module. Second, you can quite easily disable all APE
Modules if you just open the APE Manager preference pane and click on
the topmost Information tab then click on "Disable Temporarily". Finally,
Apple does provide an Apple developed and sanctioned method for
modifying applications called an InputManager. Unsanity has two such
haxies that use InputManager, "Menu Extra Enabler" and
"SafariNoTimeout". Even an Apple employee has released one called
TextExtras. But sadly, InputManagers can only work in Cocoa
applications.
And most importantly, APE Modules cannot cause kernel panics. There is
no way for them to. They do not go into kernel space and do not do
anything the current logged in user cannot do. Buggy kexts (Norton) are
what cause kernel panics, not APEs. In the entire life of APE there was
not a single reported kernel panic that could be traced back to APE or an
APE Modules.
I have had issues with FruitMenu disabling menu commands in
photoshop. For months I couldn't figure out what the deal was when I
tried to edit a file or add a layer, the command would be there after
opening the application but upon using it through either menu
selection or keyboard shortcut it would disappear and become
unusable; then it occurred to me that there may be an issue and sure
enough, after disabling FruitMenu (which I LOVE and miss sorely) the
problem went away and my system is now even faster now that it is no
longer active.
Know that you do not have to give up FRUITMENU for the Photoshop thing- I run Photoshop 7, Go-live, and a myriad other image editors, macromedia apps, too, and have no difficulties. The fruit menu , since you love it, as I, may be set up to not "launch" when Photoshop is active. The settings are available from the system preferences- the fruit menu module has its own icon there, in the "OTHER" section, where Tinkertool lives as well.
Sometimes it is not the non apple software that screws things up, but the synergistic mix of several shareware applications duking it out for which app does what when. A cyber-rumble. I've learned to read the fine print-and try to avoid the overlap of tasks my shareware is responsible for.
---
First off, the term 'haxie' is meant to only apply to Unsanity released
application modification software. The general term for things that use
APE is... APE Module. Second, you can quite easily disable all APE
Modules if you just open the APE Manager preference pane and click on
the topmost Information tab then click on "Disable Temporarily". Finally,
Apple does provide an Apple developed and sanctioned method for
modifying applications called an InputManager. Unsanity has two such
haxies that use InputManager, "Menu Extra Enabler" and
"SafariNoTimeout". Even an Apple employee has released one called
TextExtras. But sadly, InputManagers can only work in Cocoa
applications.
And most importantly, APE Modules cannot cause kernel panics. There
is no way for them to. They do not go into kernel space and do not do
anything the current logged in user cannot do. Buggy kexts (Norton) are
what cause kernel panics, not APEs. In the entire life of APE there was
not a single reported kernel panic that could be traced back to APE or an
APE Modules.
Why? Why? Why?
I've been outspoken against Haxies from day one. It has not been a
popular position. (For example, see my comments on VersionTracker for
WindowShade X -- I'm told to go to the PC if I don't like the Haxies.)
I think this whole thing is shameful.
First developers that patch should clearly explain the risks to end users
in a way that they will understand. Their ethics disturb me. They are
taking advantage of the most people's igorance and the myth that you
can't patch on OS X so therefore OS X is rock solid.
Second, a big problem is the pain this causes innocent developers,
includig Apple. I can't tell you how many developers have taken support
calls from angy customers only to find in the end it was a conflict with
something that patches (a haxie, default folder, etc.) If you don't believe
me, search the carbon-development archives for haxie or crapxie and
see how many developers complain about it.
Third, it's a security risk. I don't care how they defend this, but when
anything can use APE and run foreign code inside the address space of
another process the system is compromised. How long before we have a
virus or worm built on APE technology or some other type of port
injection? I look forward to Apple shutting down this loophole. From
conversations I've had with some folks at Apple it sounds like they are
not at all happy about this and are worried about the implications.
Fourth. Why do people feel so strongly about going backwards? Why do
people want to go back to the OS 9 days of application conflcits,
extension conflicts (with other APE modules!) and OS conflcits. Why go
to hacks like incompatible application lists and so on and so forth. Is it
really worth it to have Silk, WindowShade and the other haxies? It's too
high of a price for me to pay. I want to move forward with technology
not stay stuck in the past.
The developers of patching software must, at a minimum begin full
disclosing what they are doing. Ideally they would discontinue the
practice of patching altogether.
yes, agreed. Apple should also dump support for QuickTime plugins (see
all those component not found messages caused by toast?), Scripting
Additions, Internet/Browser Plugins, InputManagers, InputMethods (can't
have Ink working), DYLD_INSERT and other methods since every single
one of these inserts code into applications. Every single one. Guess we
also have to kill frameworks, shared libraries, and gdb.
Lest not forget that Apple has in the past fixed bugs in OS X that could
easily be exposed by APEs but were infrequent and hard to track down
otherwise.
And the only person that every used the word "crapxie" on Carbon-Dev
was you.
- by Bryan Pietrzak August 29, 2003 2:32 PM PDT
- <class="merchant"><span>>>></span><div class="datestamp"><i>This is a reply to a previous comment by Rosyna--2008</i></div></class><br />
- Like this Reply to this comment
-
Showing 1 of 2 pages (36 Comments)True, the only person that <i>posted</i> to carbon-dev
and used the word was crapxie was me. It does not mean I'm the only
person that <i>uses</i> that word.<br>
<br>
That said, your argument is weak. If you don't see the difference
between supported and encouraged techniques vs. what you're doing
then there is no point in going further with this conversation. We'll
simply never find commmon ground.<br>
<br>
You can still choose to take the ethical high road. You can still choose
to do the right thing. You could still chose to <b><i>at least</i></b>
be open, honest and upfront about the risks. You can educate your users
to make sure they know they are using software that patches. You could
choose not to write this kind of code.<br>
<br>
But, you've made your choice and you have a right to do that. I just
happen to think what you do is wrong. I don't argue with the service you
provide, I argue with the cost of that service. I personally think it's too
high.