Info about APE
 

I was wondering if anyone had any current info on Unsanity's Application Enhancer, and it's 'Haxies'.

I run an older machine and some of the thing like ShadowKiller seem like a good way to maybe give me a bit of a performance boost.

I have heard some bad stories in the past though about the 'haxies' and APE.

Most of the reviews on VersionTracker are dated back to November, so I am looking for some current info about compatibility with 10.2.3 etc.

Seems fine on my G4 with 10.2.3; I usually have WindowShade and LabelsX running...

-rob.

It's a Little Bit Creepy...
 

APE seems fine on my machine as well.

however...

it installs a bunch of things to /Library and /System. i really, really, really don't like that.

i wouldn't install it now, but unsanity got me hooked back before APE, when their various haxies could be installed safely within ~.

buyer beware.

the thing that really pisses me off is that i'm sure most of their haxies would still function fine, without them making me mess with my X installation.

as far as i know, Shadowkiller and Silk run without APE, so they should be save.
appart from that, i agree with petey: i see no reason for the APE with some haxies and they do not provide proper information about what it actually does. i would really love to use Windowshade, XLabels or XSounds. but under the circumstances...

Several months ago I traced several very odd problems to APE. Was very hard to diagnose, but the end result is disabling APE cleared up all problems instantly. Last week I decided to give APE another go as its been updated a few times, and I really wanted to use the Full-screen Safari APE plug. So I enabled it, and things seemed to be going ok. Then after installing SpellCatcher - yesterday - all hell started breaking loose. Several Finder quits, several app crashes, all day - about 10 different crashes. This on a normally rock steady machine. Chatted with SpellCatcher developer and he indicated it might be APE. Disabled APE and all is well again.

Bottom line is - APE is probably fine if you are running a basic vanilla install of OS X - without much extra. Start adding other 3rd party items into the mix and APE can be found to be the nasty neighbor in almost all cases. I couldn't agree more - its really irritating they changed to the APE format when all was working fine. And to this day Unsanity refuses to admit that the APE can or will cause problems.

Here's a related question...
I use default folder X, which is listed on the unsanity site as "using APE technology". However, I have never installed APE itself. What files can I look for to see if default folder installed part or all of APE?
I don't/won't use any of the haxies that require APE.

Thats odd - I never heard of Default Folder using APE. I have used Default Folder since v000000.1 ... in other words a long time. You would have to kill me before removing my Default Folder. If I find out that DF uses APE. I WILL go POSTAL on the CREATOR of APE and then I will badger the APE developers to fix their damn product. Face the facts and admit their product causes problems! ..... ooops.... I'm late for my anger management class .... ;)

i run a goodly number of 3rd party add-ons, and APE gives my system no trouble.

at least no trouble that i'm aware of. chimera crashes a few times a week, but it's a .6 release. and ms word crashes sometimes, but that's microsoft.

my problem with APE is that it's messing with my X installation. i've always liked the idea with X, that if something went blooey, it would almost definitely be a problem with my user account, not my X installation.

if people accept things like APE, it seems like that concept will disappear, and we'll be back to a OS 9 kind of extension voodoo.

agreed.

i found very subtle problems with APE installed. nothing points to the product, but it's elimination seemed to have squelched some curious anomalies.

Unsanity's Line
 

as a paying customer, i've been corresponding/complaining to Unsanity about this issue. Rosyna, the customer service person, has been patiently responding to me. here is the gist of their argument:

---begin snippet---

> only a few versions ago, WindowShadeX did not require APE,
> and was able to install all of its stuff inside the user's home folder. it worked. really.

Yes, however it caused many problems in many applications. And Mac OS X 10.2 broke that method. We could fix it for 10.2, but then 10.2.4 might break it again so we'd have to rerelease all the haxies for every version. Right now all we have to do is update APE if the OS breaks it.

That and the person that wrote the original way worked for apple and he was told to stop working on it.

---end snippet---

my suggestion: write to Unsanity and tell them you want haxies that install inside the User Folder. be polite, of course. and let them know if you've bought their products in the past.

they're great coders, and perhaps some consumer pressure can convince them to write haxies that practice good hygiene.

For what it's worth, I did have odd problems before that seemed to point to APE - when I disabled it the problems didn't seem to go away.

After a fresh install of Jaguar I've placed APE 1.2.1 back in - no problems yet. I really like the ClearDock (triangle color changes do not stick however, many report this bug), iChat and Safari hacks.

The comments about APE harkening back to OS 9 daze are dead on the money.

The problem with APE is diagnosing the problems. I spent months with a quirky OS X install.. never able to point directly to APE, but disabling it cleared all the problems up!

What items are you referring to? All I found was an *empty* directory in /Library/Application Enhancers. I couldn't find anything in /System, nor could I find any other suspicious items related to APE.

And just to be clear, *many* programs install things into /Library, and that's fine. It's supposed to be the repository for things you want available to all users on your machine. Examples of other items in /Library include Adobe application support, an empty "Global.regs" file from Mozilla and system themes, if you're into those.

Is anyone aware of any problems with APE conflicting with GoLive? My GoLive has been really crash-happy the last couple of days. That is the first time I had used it since installing APE.

corinthian,

do a finder search for "ApplicationEnhancer"

i have no problem in APE installing stuff in /Library/Application Support/. that is normal.

but it installs its PrefPane globally in /Library/PreferencePanes/, which makes it kinda like a global StartupItem. (it spawns the "aped" process.)

and it indeed installs stuff into /System/. do the search if you don't believe me.

After months of troubleshooting my oringinal installation of 10.2 (which seemed plagued with problems) I thought I had tracked the problem down and suspected that it was APE. However, it later transpired that it was the preference file from my 10.1.5 installation of Fruitmenu. When I deleted that file everything almost returned to normal. After further troubleshooting I decided that FruitMenu was also a culprit so I disabled it and switched to MaxMenus.

I do have Xounds, ClearDock, Metallifizer and WindowShade installed, all of which seem to run without problems. Sure, there's a speed hit in having these items, but no quirky behaviour that I've noticed.

I did the search and found the ApplicationEnhancer.bundle, so thanks for the pointer. I must confess I dislike the idea of anyone installing things into /System/Library -- no matter how innocuous. I'm only using it to enable deMetalliifizer, but I'll be sending feedback anyway.

I still don't see what the big deal is with APE installing into /Library. If you're not happy with that, move the prepane into ~/Library/Prefpanes -- it works just as well. Although the framework doesn't function in ~/Library/Frameworks, aped launches with the rights of the current user, which is much better than launching as, say, root.

corinithian,

i'm glad you agree that the /System installation is objectionable.

and thanks for doing the testing i'm too lazy to do.
i've got no problems with them installing stuff in /Library/Frameworks. that's definitely kosher.the PrefPane was my problem with the /Library installation. i'm glad to hear you can move it to ~/Library, and will do so before my next reboot. i wonder, though, if it won't screw up stuff other than Metalfilizer.

this also brings up the following question: if you move the PrefPane, reboot, and login as a user who doesn't have the PrefPane installed, will the /System component still launch 'aped'? if so, then moving the PrefPane doesn't accomplish much. (a plain vanilla user is still running an APE process.) and, of course, who knows what else the /System component is messing with.

non-lazy testers, please get to work.

Hello all,

I wanted to clear some things up about Application Enhancer to avoid possible misunderstanding.

First of all, what does APE do and how does it works? Application Enhancer allows to load plugins into running applications address space to perform certain tweaking on the application behavior (this is what WindowShade X does, for example, it redefines the _CoreDockMinimizeItem call to iself in order to do windowshading). To load plugins into other applications there's an aped process that lurks in the background and watches launches of new applications. This being said, that if an application is owned by root, or any other user different from the current user, aped will not touch it (it simply can't due to the way protected memory works). In order for aped to function, it needs to be a SystemConfiguration plugin. Unfortunately, Apple has not provided any different location for SystemConfiguration plugins other than /System directory. We know how uncomfortable it is to have something in the base system directories, but we simply have no choice.

We do not say that APE itself or its modules do not cause problems. They might, as all the software is written by humans and we are subject to err. However, realizing that APE may cause problems in other applications, we pay significant attention to ensure everything works as expected. I know we have stepped in somewhat muddy water with the whole 'load plugin to other apps' thing, but we had no choice to achieve what we needed to achieve the other way.

Due to the fact APE and its plugins operate behind the scenes, many of users and developers tend to blame things on us. In most cases, the source of the problem isn't APE, but we are and we will investigate every single case reported to us.

If you beleive APE or one of its modules is causing troubles, follow this routine:
1. Log out and log back in while holding down a Shift key.
2. You'll see an alert saying that all APE modules are now disabled.
3. See if the problem still occurs. If it does, then it cannot be related to APE because when you logged in with a Shift key, APE automatically disabled itself and was not loaded (aped process was not started, too).
4. If the problem does not occurs, then it could be APE-related. If you have a crash log, it is much appreciated (to enable crash reporting, start Console.app from Utilities and Enable Crash Reporting in the Crashes tab of its Preferences. Resulting crashlogs will be saved in ~/Library/CrashReporter/). Submit your doubts, crashreports and everything else you think might be helpful for us to urgent (at) unsanity.com. I personally monitor and answer that particular box and will investigate your case and do whatever we can to eleminate the problem, if it was caused by us.

The bottom line -- APE might stand on the edge of 'allowed things to do to your system', but -- it only does its thing when its loaded, and doesn't alters any frameworks or system files on disk, so to completely get rid of it, all you have to do is Uninstall or login with a Shift key pressed. We realize it may cause troubles, but we are working hard on not allowing this to happen. If you like the functionality behind our products, help us out. It doesn't takes much effort, and in the end, we all will be thankful to you. I believe that only together we will be able to make Mac platform the ideal working environment out there.

I am open to criticism, questions and suggestions on either this forum, which I will now visit frequently, or privately at slava (at) unsanity.com.

-slava
lead programmer @ unsanity

slave - thanks for your concern and post here at macosxhints. We welcome you. Its sad to see you toe the party line (APE causes no problems), but it sounds like you sincerely want to help. Unfortunately the evidence is never so clear as a crash report, etc. I honestly believe that what APE causes is some weird interaction between various apps, and 3rd party addons that you as the developers of course can not check every one available. Nevertheless - the facts are clear in my eyes - APE ON - 3-5 crashes a day, APE OFF - no crashes a day. I may not have the written proof, but I know my machine. I have written and sent reports in before - got tired and gave up when I realized everyone at Unsanity was toeing the line also.

I don't know what to tell you, but for me no Unsanity products which use APE will be on my machine and this is unfortunate, because the stuff out there that uses APE is REALLY NICE and VERY USEFUL stuff in most cases.

bluehz,

if i understand things correctly, then you should ditch Default Folder, as it uses the same method (and maybe the same code) to modify apps' memory space.

but i could well not understand things correctly. perhaps slava could comment.

---

basically, i can't figure out how to feel about all of this. i want the tweaks that APE provides, but i also want a rock solid OS. in a perfect world, i could have both, but i don't have enough programming knowledge to understand if this is that perfect world.

my system seems relatively problem free with APE. there are a few quirks, and i have no idea if APE is related or not. these quirks mainly have to do with mounting and unmounting volumes. sometimes disk images will fail to mount. sometimes my iDisk will refuse to unmount. also, sometimes my DHCP address will revert to a 169 address, when others on OS X using the same router don't have that problem.

i've been guessing these problems aren't APE related. unfortunately, they are all intermittant enough that i'm not eager to spend the time testing properly.

All APE modules work by reassigning certain system calls to themselves in order to modify the standard behavior. This means that there can be only 2 kind of APE-related bugs:

1. APE module does something wrong in its own implementation of a system call and crashes. This bug is likely to happen when you use the functionality APE provides directly - collapse a window, use the Apple menu, open an Open/Save dialog box, etc. If the APE module is loaded, but you are not doing anything special, there's a very thin possibility the crash you got is related to the APE module. Think of it that way - APE module lurks in the background, doing nothing, until you try to do something it is intended to enhance. Only then the code kicks in, while being completely idle and not executed most of the time.

2. APE module does something on the application launch time that exposes a bug in the application. For example, we had an issue with one of the past releases of WindowShade X when it would load one additional system framework into an application, and one of well-known applications started to crash because they were over-releasing some memory object, but the bug didn't come up without the APE module because the above mentioned extra framework never was loaded. The developer issued a fix in a few weeks, but we did a small 'fix' on our own that would detect the faulty application and fix a bug in it.

To summarize, there's about only 2 circumstances when APE can cause an individual application crash:

1. During application startup when APE module does its own initialization too;
2. During actions related to the functionality APE provides.

The rest of the time APE module stays silent and is not being used, just like the rest of the system framework calls passively loaded into each application.

There might be exceptions, but I haven't heard of any in 2 years I am doing haxie programming.

In the case of something that poses a system-wide modification (e.g. SkinADock) isn't the module basically active all the time, or at the very least every time the user accesses the dock?

The most recent conflict I have found with APE was with SpellCatcher - which - depending on your settings - is active (e.g. interactive spell checking) all the time. Hence - I can't simply say.. "well everything is ok until I activate application XYZ" Now of course you could argue that application XYZ is at fault here, not APE. But that just leaves the next application XYZ to come along and conflict with APE. The way I see it APE lives on the edge - which believe me I am all for.... but when the edge ignores standardized API then I see that as a problematic item I do not want to tempt fate with.

True. But in that case, only Dock is affected, and the module is not loaded in any other applications, so the worst it can do is crash your Dock.

Who said we ignore standardized APIs? We might use them in a slightly different way, but that doesn't makes them less standardized. ;)

slava: thanks for taking the time to discuss the matter with us, could you please also take the time and explain why ape has to go with almost all unsanity haxies.
like petey reported the official answer is
but i fail to see how this would affect something like Metalize or XSounds of XLabels, since i assume the first only changes the nib files while the second and third should do no more than a single and permanent modification of the system and/or Finder respectively (i don't know much about programming though).
So why do these require APE?

Basically, the story is as follows. Before APE, there was a library providing the needed functionality of loading of our plugins into running applications. We used it, Default Folder X used it too (and still uses it at the moment, although its author uses some APIs from Application Enhancer in the recent versions of Default Folder X, as they are more stable, extendable and compatible than the old method). In order for that library to function, some background application had to be running to watch the launches of other applications (much like what aped does in APE). So every haxies needed to have its own daemon running that would do its thing. So we faced a problem there - first of all, it became much harder to maintain all of these haxies up-to-date with the library changes, if we make any; plus, the more haxies (or other products that used the same library) you had running, the more daemons would get spawned, sitting in your system, doing almost the same job.

So we decided to do a step further and make one universal framework that would take place of the multitude of daemons and provide all the needed functionality in the one place. Such framework would have a set of universal APIs that we (and other developers) can use; we also can update the framework at will in case any modifications or changes to the core functionality is required. This framework is named Application Enhancer. To rephrase, we have moved all of the commonly used code to one place, so it is easier to maintain and re-use.

If any of you is a developer, you can take a look at the list of the functions Application Enhancer provides - the free SDK download is available at http://www.haxies.com/ape/sdk/

:)

Forgot to mention (and pardon me for constantly emphasizing this fact), that Metallifizer doesn't actually touch any of the nib files on disk -- rather, it catches new window creation call and sets up a "metal" (or "no metal") attribute for the window, on-the-fly, in-memory. :)

slava,

so is there any reason that the PrefPane can't be put in ~/Library, rather than /Library?

and if the PrefPane is not global, am i correct that APE will not be active for any user that doesn't have the PrefPane installed?