Amen.

That was one kickass post - I learned a lot, and I have nothing to do with APE. :)

I accept the APE Framework is safe. I accept that APE can't cause a kernel panic any more than any app can (really, they only can by exposing bugs in the kernel or driver layers). However, I still don't understand what keeps one APE Module from conflicting with another APE Module. Ultimately, what keeps APE Modules from crashing applications the same way as an extension crashed OS 9?

Excellent post. I wasn't aware all this FUD had been spreading ;)

BTW, I will note that there's one problem I've noticed. I don't know if it's actually true or not, but leaks *tells* me that APE is leaking at least 1 string when I run it on my program. Actually, it's apparently ShapeShifter's CrashGuard. Here's the string:

__Unsanity_Haxies_CrashGuard.com.unsanity.shapeshifter

I got this from leaks by converting the hex output to ASCII and deleting the garbage chars at the beginning/end of the string.

Nice post... I'd suggest to include it in the information provided with the preference pane (or as a separate document).

Raf

> Why would a program designed to warn on outgoing
> connections not warn if one is being made?

Simple: because APE modifies Little Snitch to keep it from doing so. Or because Unsanity paid off Objective Development to put a back door in Little Snitch. Actually, I think that Unsanity and Objective Development are part of a larger conspiracy.

And don't think you can get around this by using tcpdump to watch your outbound traffic because APE gets its tenticles into that, too. You could try running tcpdump from another system, but if you've got APE installed there as well then it won't show you any packets heading for unsanity.com. A clean system will be able to see the packets, but since they are encrypted (even the destination address), you won't be able to tell what they are.

I'm telling you, this APE stuff is *bad news*!!! Those goons from Unsanity are insidious, evil geniuses! They're out to learn everyone's secrets so they can engage in widespread blackmail and identity theft. The Secret Service or the CIA or the NSA or someone needs to pay them a visit before they topple the government and set up a technocracy.

For the satire-impared, that's a joke.

Topple the government? Why would they want to do that?

They already control the government, remember.

The only reason I'm wary of the APE framework is because it left a banana peel in my CD drive. It's a very intelligent APE, but seems a tad forgetful at times.

I always thought Unsanity was the most respectable of the respectable shareware developers. It's a shame you get so much crap from inferior people.

I've never had any problems with APE or any other Unsanity hacks except Silk 1 on Panther.

Clearly APE wasn't responsible for that problem, since shutting down the Silk module stopped all Carbon apps from instantly crashing on startup.

As for Unsanity apps being spyware, that's clearly bollocks too, judging by the number of people I know who have shared haxie registration codes on their systems for many months now.

I have many APE modules installed right now and they all seem to be working properly and not causing instability or slowdown.

ClearDock
ICeCoffEE
Metallifizer
Paranoid Android
ShapeShifter
Silk 2 (admittedly without any font substitution on)

I easily achieve 30 day uptimes on my very busy 1GHz Al PowerBook, so I call bullshit on anyone who says that APE or it's modules cause crashes or slowdown (font substitution in Silk being an exception - it can cause a zillion pageouts/pageins).

I'm very pleased with Unsanity's applications and particularly APE, which gives people a standardised and homogenous method of performing things which could otherwise get very messy, and they give it away for free. :)

No I don't work for Unsanity. :D

I've been using APE ever since I first saw the ClearDock module running somewhere, MacAddict perhaps.

Love it, never had any issues I can attribute to APE or the modules I run. It's interesting that people are now attacking something the provides features seldomly found elsewhere.

--
d a v e

Dear Unsanity,

I don't seem to be able to get any dates with girls. Is that because I've got the APE framework installed? After reading your post, I have learned that APE doesn't crash or kernel panic, but does it prevent girls from liking me? Has it placed a curse on me?

worried,
Lonely

Hm.... No trolls yet. Interesting....

Hey Josh,

I'm here to fix that problem ;-)...

ARRR, APE STINKS!

Seriously though, thanks for posting this Rosyna. It clears up a lot of lingering questions I had about APE in general. :-)

No trolls here because only the true fans visit Unsanity.org to read the news. ;)

Long live APE. It is pure genius.

I had APE installed on my powerbook, when I upadated to itunes 4.5 it would not work, I tried for days and nothing. I was looking around a seen a couple posts blaming APE. Although I wasn't running any APE modules itunes wouldn't run. I completly uninstalled APE and finally got itunes 4.5 to work. I was always a little worried about having APE installed on my computer, wondering if it could mess up my computer. After reading this post I have a little bit more understanding how APE works, and feel that I must of missed something before uninstalling APE that I did afterwords to get itunes to work. I've seen a lot of FUD about APE in different forums and I started to believe what they were saying but after reading this excellent post I'm going to reinstall APE. I now know why APE is in the crash report with the crash log explanation posted. A very helpful post.

A lot of the flack over PA with APE comes because of the latest exploits of the URL handlers in Mac OS X.

A simple program like RCDefaultApp to disable or reassign the URL handlers is more secure than "trusting" PA won't get fooled.

Installing a "haxie" as a fix may be a bit extreme and unnecessary, may even cause problems later when Apple provides a patch or the use installs updates for their programs.

Never less, it's good there are people out there that are taking action and providing alternatives.

Paranoid Android, More Internet, RCDefaultApp, whatever a person chooses, they can make their own intelligent choices.

http://daringfireball.net/2004/05/help_viewer_security_update

I've been using FruitMenu for a long time. Never a problem. It works very well and it is very useful. Thank you very much. Keep on doing little good softs than are not so expensive by the way.

This part:

" uses the same system infrastructure and Apple provided and documented APIs that gdb uses. GDB is an Apple supported debugger engineered by Apple to "work" on OS X. Since Apple does not provide a way (other than with kernel extensions) to change the behaviour of different applications, we had to engineer one on our own. Kernel extensions are just too dangerous for the small modifications we wanted to make to applications and they function on the system level instead of the much preferred application level.

Apple also provides other methods of getting inside applications such as QuickTime components, Contextual Menu Modules, Internet Plugins, Input Managers, and AppleScript Additions. The problem with most of these is that there is no guarantee that they will be loaded into another application. If they are loaded, there is no telling if it will load soon enough to change anything. And in the case of Input Managers they don't load for all native applications so they become useless if you want to affect things like the Finder, Firefox, iTunes, or BBEdit."

sounds odd. Comparing APE to Scripting Additions is silly. OSAX are only used when you need to run a script that accesses them. The only exception might be standard additions. If you never run a script that uses given additions, then you never run them. Internet Plugins don't run outside of the browser they're designed for.

However, if I'm reading what you said about APE and aped correctly, it injects itself into the run space of every application I use, and modifies things depending on the Haxie. So while Apple does provide limited ways to do this, and gdb can indeed do this, there is no way that Apple intended for gdb to be running 24x7 diddling every application's process space.

APE and it's associated modules have cause problems in applications, including MS Entourage. That's fact. Whether it's the fault of the modules or the framework or the daemon is immaterial to the user. The fact that gdb is allowed to operate in this fashion being used as a way to say "See, this is supported" is not completely straightforward. gdb is a *debugger*. It HAS to operate in the way it does to function. A debugger that cannot watch execution steps and track variables, etc., would be rather useless. APE isn't a debugger. It's a hack framework. A very good one, but a hack framework, and it's using something that isn't designed to be used that way for that long. So while you're technically right in saying the API that APE uses isn't undocumented, it's not exactly correct to compare it to the QuickTime module framework, or the OSAX framework.

john

::::applause:::: I'm SO glad you posted this, Rosyna!

I've been running half a dozen haxies for nearly a year, first with Jaguar, now with Panther, with ZERO problems, and I cringe every time I see yet another mini Tome-o-FUD about APE posted anywhere. Love 'em, wouldn't run without 'em here!

Oh, wait, I do have ONE problem....

I can't afford to get Silk & FontCard yet. (-:

Thel

Nice post Rosyna. For the record, neither the APE framework or APE Modules have never caused a crash on my Mac that I know of. Oh, and no noticable slowdowns.

looklost, if I recall correctly, iTunes 4.5 was crashing due to the way that Shapeshifter (an APE Module) was caching something about the interface.

Sorry I can't be more specific - I googled but couldn't find the blurb with the details. Perhaps someone here can clarify.

Found one of them, from http://www.macthemes.net/articles/news/000320.php

"POSSIBLE FIX: It now seems that the Party Mix image problem is related to ShapeShifter's caching, and Max Rudberg suggests that users revert to Aqua, log out, in, and apply your theme again to clear the cache."

In addition to John's comment above:

Using the debugging infrastructure only gives you access to the code space of the application. To perform interesting 'enhancements' to an application requires that functions and data that are used internally by an application be modified via the same means a debugger can modify code. These functions and data may or may not be documented - but they are most certainly internal and the applications were not written with intent to expose these publicly.

So there is danger that these 'enhancements' will cause instability. I should also point out that your descriptions of backtraces is quite misleading. It is entirely possible that the actions of an APE module could cause a corruption in the memory space of an application, resulting in a crash of a thread other than the APE one. Your discussion entirely ignores this possibility.

I replied to John privately as I mentioned a particular program that DOES use Scripting Addition to patch applications.

Re: Chris.

No, the backtrace is not misleading as this is exactly what I did in FontCard to produce the crash. Overrealesed some memory then tried to reuse it.

The APE framework does NOT use the debugging infrastructure. It uses the same system infrastructure that GDB uses. Specifically, mach messaging.

it's never been about being "safe" or not... but more on the level of usefulness. all the modules on unsanity are not something i want or need, so why bother?

Re: TigerKR, there was no crash related to it. Apple's servers were extremely busy that week and since then there have been no reports of any problems with the iTMS

It would work sometimes and fail the next.

As for the Party Mix issue, that was a missing image, not a crash.

I've been running APE with a couple of modules on 4 machines under 10.2 and 10.3 for nearly eighteen months. Not a single problem or issue to report. Thanks for a great product!

I have been meaning to suggest this for some time, but I feel that the icon and the APE (ape) connotations alone make it suspect. That aspect of it really, really needs to go to make it more acceptable, just as a marketing issue, so it can be taken seriously.

nick,

I'm totally with ya dude. It's just like coffee. I hear coffee's not good for you, but y'know, it's never been about the caffeine. I just don't like the taste so I don't drink it....

Sheesh, what a rube...

The 10.3.4 install failed on my 1.33 17" PB with Paranoid Android installed. I had to remove it before I could install.

This was definitely caused by PA!

When will apple buy your technology so everybody can have nice customisation, and forget the monkey ?

(dark chocolate theme is a must !)

anonymous - the 10.3.4 install worked without a hitch for me. PA is not at fault.

I don't like daemon ape.

"No, the backtrace is not misleading as this is exactly what I did in FontCard to produce the crash. Overrealesed some memory then tried to reuse it."

Which is of course not what Chris said - a double-free is quite likely to cause the thread making the second free() go bang straight away. But how exactly can you stop a buggy APE module from scribbling into random memory anywhere within the host app's address space, and cause either the application code to crash or some subsequent call made by the app to crash? E.g., perhaps it overwrote one of the app's own pointers - the app then crashes millions of instructions away from any injected code when it tries to use that pointer. Or perhaps it scribbles over a GWorld - only for QuickDraw to crash when the app later asks it to draw it.

The correct answer is "you can't" - an APE module is running code within the app's address space that the app did not expect to be there. If that code is buggy, all bets are off: it's _exactly_ like Mac OS 9 trap patching, except it only affects one app at a time (so you might get lucky and avoid a crash in 7 out of 10 apps you happen to be running within).

I don't have a problem with either code injection or patching in code: both of those techniques use system APIs and are 100% safe. My problem is with the code that gets patched in - that's code my app didn't expect to be there, and yet it's running alongside it.

It's as if you sent me a mystery static library just before I release a GM, and say "this is completely safe, but you don't get to know what it does - please link it into your app and ship your product". It's nuts: you're asking me to trust something that didn't go through my QA process, I have no idea what it does, and yet I'm the one who gets the stack crawls from users complaining that my app crashes...

If you think that's overly dramatic, can I send you a mystery static library to link in to the next release of APE for you to ship to all your users?

I have APE installed. I've purchased several Unsanity shareware products. I'm a generally happy customer. That said, I have several issues with APE that are similar to the FUD you speak of:

- APE does not come in a transparent installer. I don't like this.

- APE installs into the /System directory. I don't like this.

- APE installs for all users whether I want it to or not. I don't like this.

I value the functionality APE adds, and so I've made my decision to live with the issues I list above.

But the FUD you speak of IS NOT IRRATIONAL. While I choose to use APE, I don't recommend it to inexperienced users the way I do with other useful shareware.

And you could eliminate the widespread suspicion by correcting these issues. Look in the mirror instead of yelling at 13 year old script kiddies.

I installed Ape on both 10.2 and 10.3, i did not put ANY modules at all on. The computer crashed (by crash i mean kernel panic) whenever i used ANY APP ON MY SYSTEMt. This happened right after installing Ape framework (note framework, no modules installed). So i disabled it an all is good. It is definitly safer to go in and unix the crap then attempt to load a module in (like windowshadeX). I looked in the log file and it had no information about the stupid Ape thing causing crashes anywhere. Note: I have no other hacks on.

Great posting. Thanks for the clearification.

I have a question. Is APE a vector for worms/viruses? If someone can get a file into the right place, will aped load and run it?

-blake

I've been using APE modules for ever, it seems. I've had times when it wouldn't seem to work for some reason, and never had a time when a logout/restart wouldn't fix it.

I'm sure that of all of the people who have had problems, they are *leaving* out some item of info that would be essential in narrowing down why they had a crash or whatever in the first place. But it seems that they probably can't admit that they can't remember what that was, so they sieze on a recently read rumor, and fall in line in blaming a good software company.

'Nuff said.

Re: Kernel panic person.

APE did not cause any kernel panic. And I doubt what you say even happened because that would mean that you downloaded the APE Framework installer with no intention whatsoever of using any modules and then what would be the point?

Re: petey, what do you mean by "doesn't come in a transparent installer?"

There is no way for anyone to link to the APE Framework unless it is installed in a fixed path. This is a serious limitation of dyld. The path must always be known. Granted, dyld has some variables for placing in parts of the path but these are extremely difficult to use for developers. A frequent problem is that developers completely forget about dyld's nature, will have something work on their system, will ship it then be surprised when it doesn't work on anyone elses computer. dyld likes to crash applications that reference symbols that do not exist.

Re: Developer, if that is your real name. I suppose if you release an app that was only tested on 10.3 then a user runs it on 10.3.4 and it crashes, you wouldn't support it because they loaded in libraries and memory addresses that you never tested against?

TigerKR > maybe you should've repaired permissions ;)

Okay, so if your APE framework doesn't phone home, and you said that you revoke a license for anyone who may abuse APE, how do you stop the rouge module from running on pre-existing installations?

What if someone gets a legit license and turns to the dark side?

I think you missed the core issue here which is that someone else's code is running inside *my* software and is able to affect largely anything and everything. We are not so concerned so much with Unsanity's haxies as we are third-party's haxies.

They can throw up a window asking for personal information that appears within my app. Guess who would get blamed?

Mac OS X users are already well-conditioned to automatically enter a password when the Authenticate window pops up, which is for just about anything these days.

If all people using computers were honest and used their technology for legitimate purposes we wouldn't need apps that phone home or be concerned about standardized, clean methods of injecting unknown code into *any* application.

I generally regard APE as all right, but poorly written APE modules can wreak havoc. I had a problem where the Finder was utilizing all of my PowerBook's CPU. After some digging, I removed APE and the only module I had installed (Nudge) and the problem stopped. I really liked it, but it was a bitch to figure out what was doing it until I realized that a bad APE module was to blame.

"You will often see people say that Little Snitch (a tool which warns about outgoing connections) gives no warning about APEs, but these people still "know" it is spyware. Why would a program designed to warn on outgoing connections not warn if one is being made?"

If the outgoing connection is from an application that Little Snitch allows. The question is, can Little Snitch distinguish between a message from an APE Module and a message from the app the module's code is running in?

"Developer, if that is your real name."

It's not.

" I suppose if you release an app that was only tested on 10.3 then a user runs it on 10.3.4 and it crashes, you wouldn't support it because they loaded in libraries and memory addresses that you never tested against?"

Of course I would - I'm not sure why you think I wouldn't. There's obviously a difference between running an app on a new system update supplied by Apple (where backwards compatibility is a big deal, and a crash like that is much more likely to be my bug) vs running it with 3rd party code code that I have no way of knowing the background to.

The reality is that if my app crashes my users blame me. You might think it incredible that someone would download a Haxie, forget they have it installed, then start slamming an app developer when it starts corrupting their documents weeks later because of some stupid bug that only shows up if the app tries to mmap a file bigger than 512Mb. But that's what happens, and it comes with a real cost attached - support for my existing users, and sales for future users.

If you want to get Haxies a better rap, include some code to monitor apps for crashing. If you see an app crash at any point after a new Haxie is installed, offer to disable it for that app automatically. If it turns out to be an app bug then the user can always turn it back on, if it's due to the Haxie then you'll get the support rather than us. Yes, you'll get a bunch of false positives whenever any app crashes on the system: but until you take your code out of my application, you should take responsibility for the fact that you're modifying my code in ways I had no way of knowing about.

You didn't answer my offer though - can I send you a mystery library to link in to the next release of APE?

I run an Application Enhancer.

It's called Windows XP. It runs my apps pretty well.

Thanks,

Foo.

I find it hysterical that folks who avoid APE at all costs forget about mach_inject and mach_override. Using CodeTek? Desktop Manager? You're already using a patch technology which is arguably more dangerous than APE.

Check the list http://rentzsch.com/mach_inject/mach_Users

As developer and concerned developer pointed out, APE is dangerous.

Recently I just discovered that a recurring issue in my application on users system was, surprise surprise, an APE plug-in overwriting memory and causing that thread to die and leaving the UI hanging in limbo waiting for data that will never come.

This issue has affected all users of my application who use APE and has caused many users to _not_ purchase my license. Am I going to be reimbursed for those losses?

Maybe as developer is pointing out, maybe I should also get a library added to APE which takes 10% of your sales out on each esellerate purchase, or maybe randomly crashes APE on systems where my applications are installed. How does that sound?

I know my complaints and the complaints of others, including Apple, will remain unheeded as long as your greed stands in the way, but feel free to make our lives harder than they have to be. :)

If Unsanity would give me a dollar for everytime I wasted time debugging a difficult crasher whose backtrace doesn't really even make sense, then noticed APE in the binary images section of a crash report, then asked the user to try turning off all unsanity hacks, then got back a 'Wow, thanks, that fixed it!', I promise never to criticize Unsanity again.

Until that happens, I'll criticize this article for what it is, a calculated and completely uninformed attempt to put a happy face on what's essentially sabotaging other programs and hurting developers, who waste untold hours debugging problems that end up being Unsanity's fault. Your reading of a backtrace is completely bogus and belies a complete misunderstanding of threading and memory management. If you do ANYTHING in an application's memory space that an application developer has not accounted for, bad things can (and clearly do) happen.

10.3.2 has saved me hours of time a month, thanks to showing when APE is intruded into an application's memory space. If you take steps to subvert that, it's transparently obvious that you not only don't care about the Mac OS X platform or its users, but you also don't care about the time and cost of great third party developers that is wasted by your products. Why try to lie about your presence in an application's memory space? Any good application developer would support their users, even if their problem turns out to be another program's (or Apple's) fault, rather than try to obfuscate matters.

If you were at least honest and utterly up front about what your products are (for example, I can download any of your apps without EVER knowing that it's essentially violating application address spaces), I'd have some respect for you, but you are instead profiting off other companies who have to pick up the pieces.

I'm happy that some people don't have problems with your products and given the cool things that your products do, I can see why they vigorously defend you. But you cause a lot of pain and you should take steps to fix that (it's possible!), rather than diseducating people with this article which is almost completely false and misleading.

Cheers,

- cricket

So cricket, I must ask again, where is even ONE of these backtraces you are talking about that you said you'd send me?

It seems you don't care enough about other OS X developers to tell them about the bugs you think you are seeing.

And for those that care, cricket is a developer on Apple's Mail.app team.

I must ask the same thing of "Another Concerned Developer". Where exactly are all these crash logs you say you have that clearly point to APE?

Frankly it is developers like you two that annoy me the most. The ones that complain and complain about bugs in other people's software and yet do absolutely NOTHING to even inform them of such a crash. Like they are magically supposed to know.

You can take my Haxies from me when you pry them from my cold, dead hands.

Yes, it would be better if Apple provided clean(er) hooks for things like Windowshade and FruitMenu. But they don't, and I'll take Unsanity's implementations over nothing at all and day of the week and twice on Sunday. They make my computing life so much better that they are, by far, the best investment I have ever made in software, dollar for dollar (I bought where they were $7 too :-)

Lots of "code that you didn't write" runs in your application's process space. I don't see how Apple or the DivX guys or anyone else are any better or more trustworthy than Unsanity in this regard. If a QuickTime plugin causes a crash, disable it. If an APE Module causes a crash, disable it (or exclude that app using APE Manager). IMO, Unsanity's record is impeccable thus far, and they are certainly a lot more responsive than a big company like Apple.

Yes, being a developer is hard. Sometimes you have to debug problems caused by other people's code. Sometimes new versions of the OS break your app. How dare those users upgrade their OS! How dare they install software that runs in your process space! Sorry, but that's the right of the user.

If you want to blame anyone, blame Apple for not providing "nicer" ways to do the things that so many users so obviously want to do. Unsanity would have been out of business long ago if there wasn't a real demand for the services they provide--despite the particular way they are forced to implement them.

Wow, Unsanity has great support! My posting got a response in a matter of seconds! Roysna asked me why I don't send all backtraces I find like this to them. I responded that since they clearly don't know how to read backtraces (see article above) that it was even more of a waste of time than I already spend debugging crashes that end up being Unsanity's fault. For those that don't know, it can take HOURS to debug something before you finally realize, you know, this situation that's happened in this backtrace doesn't even make logical sense. Then you see APE in the binary images, ask the user to turn it off, and they're happy.

When I said I didn't think it was worth the additional effort to compile and send these backtraces to Unsanity, given their lack of understanding about threading and memory management (see article above), this was the extremely professional response I got:

"Well, the it is obvious that it is you that do not care about the users.

It doesn't matter who reads it. The fact is you don't even bother to make an effort to address the problem."

So, _I'm_ not making enough effort to debug crashes that are Unsanity's fault. Me, completely unpaid already by Unsanity, am not making enough effort. And, to cap it off, once I find a crash that is Unsanity's fault, they'll just write an article on their website about it, 'educating' people about how the backtrace I sent isn't really their fault, because Unsanity is not in the crashing thread. Sheesh. :)

These people are soulless profiteers. Feel free to enjoy their products, just _really_ understand how dangerous their programs are and keep that in mind whenever you see another application behaving weirdly. First thing you should do is turn off Unsanity haxies. If the problem doesn't reproduce, contact their friendly and professional support department.

- cricket

Gathering a crash log and emailing it takes around 30 seconds.

But opening mail.app, sifting through my imap account (imap support in mail.app is rather lacking, telnetting to the server is better) and then emailing can take days sometimes...

Reporting problems to apple takes a long time too. Not only that, but when you do send in something, it takes a rather long time to get a response, if at all.

Which is the greater evil?

The developers in here, whining about lost costs and whatnot, shouldn't be developing for other people for money. In case they were wondering, you support your users. If people choose to install hacks, that's their perogative, and not Unsanity's fault. Unsanity provides the river, and the boats sink. The river doesn't grab them and pull them down.

Reevaluate your priorities, developers. If you think a haxie is bringing down your app, and they aren't having issues with any other app, maybe you have some code you need to look at.

"Frankly it is developers like you two that annoy me the most. The ones that complain and complain about bugs in other people's software and yet do absolutely NOTHING to even inform them of such a crash. Like they are magically supposed to know."

Well, perhaps they've learned that Unsanity is distinctly unresponsive to notifications of defects in their software, so they just don't bother anymore.

I, for instance, regularly get emails that start out with some variation of "I try to minimize your app window, and I get this unclickably useless piece of junk floating on the screen!!" The first time this happened, I was extremely confused, until I found out how WindowShade X acts; it chops your window to a rectangle of the structure region bounds' top ... even if THERE IS NO ACTUAL STRUCTURE THERE. That struck me as somewhat of an oversight, even though my funny shaped windows are unusual enough that it was a reasonably understandable oversight.

So, I emailed support@unsanity.com my concerns, with accompanying screenshots to demonstrate the issue precisely, on August 20 2003. Get a response back saying "add them to the Exclude list then". Point out that the connection between the mangled unclickable floating blotches my windows turn into is not intuitively caused by WindowShade X to the users. Point out further what seems to me to be a reasonable approach to take, let me quote from my email to you exactly what that approach is:

"... But looking at those screenshots, you can see that the structure region that you guys set the windows to is not a subset of their designed structure regions, the parts drawn in white being the difference. Checking that you're not going to mangle the target window like that would seem to be a rather straightforward way to avoid this issue."

To this day, I regularly get support emails with the same issue. It's not all that big a thing, but it certainly annoys me whenever it comes up and inspires a great deal of sympathy with the Unsanity-is-the-spawn-of-Satan contingent, indeed.

And precisely where on the scale of developer annoyance would you place those developers that when one *does* inform them of defects in their software's behaviour which make your product unusable when triggered, *with* what appears to be a simple and easily implemented resolution they could probably implement in under half an hour, and they completely ignore it? Wouldn't you agree that's a completely different level of inconvenience and annoyance than a little harmless whining?

"Well, the it is obvious that it is you that do not care about the users.

It doesn't matter who reads it. The fact is you don't even bother to make an effort to address the problem."

"Frankly it is developers like you two that annoy me the most. The ones that complain and complain about bugs in other people's software and yet do absolutely NOTHING to even inform them of such a crash. Like they are magically supposed to know."

You know, that attitude is extremely pig-headed and is completely deflecting the issue. If you pay me, sure I will help you debug your problems.

If I allow people to write plug-ins for my software, I am giving them permission to do it. If they crash my application with the plug-in I will let them know because I gave them permission. I never gave permission for Unsanity to imbed plug-ins into my applications, so don't ask me to deliver reports to you that will simply be ignored.

And of course, as I said, a crashed thread is not going to cause a crash report to be written to disk. You know that as well as I do, so stop trying to convince the readers that we are at fault.

Also, I don't see an apology anywhere in there... would you have the common courtesy to give one in public?

"If people choose to install hacks, that's their perogative, and not Unsanity's fault."

Ah, I respectfully disagree. When Unsanity has been told of a problem with their products that makes other developer's products unusuable, in the particular case I refer to any product with windows with non-rectangular structures, and Unsanity does nothing to address that problem, causing me ongoing support time and unhappy users -- that MOST DEFINITELY *IS* THEIR FAULT. I'm happy to give them the benefit of the doubt and write it off to their incompetence rather than active maliciousness, but it is still THEIR FAULT.

"Reevaluate your priorities, developers. If you think a haxie is bringing down your app, and they aren't having issues with any other app, maybe you have some code you need to look at."

And in my case, where there is *no* code of my own involved -- only that suddenly when you install an Unsanity product, double-clicking the top of my window makes the product unusuable, through no mechanism I can affect or control -- what would you suggest I look at then?

oZ:

Your analogy is incorrect. Apple provides the highway that is nice and flat. Unsanity adds the downpour that turns the highway into a choppy lake. Of course cars are going to get stuck in it, but I am not going to build a boat to sail on it.

I will develop my software for Apple's highway. APE is not part of the Cocoa frameworks so I shouldn't have to deal with it. If the application crashes and its my fault, I will fix it. If the application crashes and unsanity is causing it, I will have to work around it to avoid lost sales. Is that fair? No way.

I love this line of thought:

"It is the app developer's JOB to somehow make their app run correctly with every hack that is available for OS X and anticipate every way that an as yet unknown hack may affect their app."

Of course, since the only way to do this is to *buy* every.single.APE.module and then test them in every possible configuration against an application.

that's ridiculous. If an application runs correctly on a clean installation of Mac OS X, *the developer has done their job*. It is absolutely ridiculous to say that any app developer must ensure that their app works correctly with every possible combination of haxie.

The contention that *Apple* should provide a way to do haxies is an utter strawman and silly to boot.

john

why are people complaining so much. if the software doesnt work for you, then dont use it. if unsanity is unresponsive, dont buy their product. in no way are they forcing you to use ther product, which by name "haxie" should give a user an understanding that this product may not work with everything that can run on your computer.

i have been running APE with cleardock for as long as they have offered it. i have run it on several versions of OS X without issue. my computer runs most of the adobe and macromedia suites with no issue.

i am happy with the product, have never experienced slow downs or funky network traffic with them running, and will continue to use the product until it does cause a problem.

best of all: FREE

"The contention that *Apple* should provide a way to do haxies is an utter strawman and silly to boot."

Apple should provide a way to do the things that the most popular haxies do (Apple menu customization, window minimization plug-ins, etc.), without resorting to "universal code injection." That's very different than saying that "Apple should provide a way to do haxies." In fact, it's just the opposite.

By providing clean hooks for commonly desired functionality, Apple can substantially decrease the demand for and usage of APEs (and other, worse software that, say, actually modifies your system files).

But the demand for APE-like thingies will never be eliminated entirely because there is a large class of things that users want their computers to do that, by definition, affect every running app. Themes are just one example.

The most constructive course of action for Apple is to recognize this fact and try to come up with a way to allow such software to be created as safely as possible. Thus far, Apple has tried to discourage and prevent such software, but attacking the supply side is not the answer. First, recognize the demand, then try to provide for it (or allow others to provide for it) is the best way possible.

Failing that, well, then you have to deal with the reality that someone, somewhere will meet the demands of users in any way possible because there is a financial incentive to do so. I'll bet those developers are also part of the "demand" for these features as well, so they're scratching their own itch in the traditional developer way.

If you have to support networks, you end up having to deal with this kind of thing.

My major problem isn't with the idea behind APE...that's pretty cool.

I don't have a problem with modifying your system. I'll use TinkerTool for as long as Marcel feels like writing it.

It's that Unsanity takes the stance that "Everyone ELSE has to play nice with us". Well, no. they don't. You have to play nice with them. Again, if the application runs correctly on a clean OS X system, that's what the developer is supposed to do. That would be the reason for all this memory protection and the like...so that one app can't pooch another. APE of course facilitates bypassing this, so it's Unsanity's job to test this.

Oh, and only APE is free, most of the modules you have to pay for.

John C. Welch:

I support your comments. I propose a key in the Info.plist that looks like this:

AllowUnsanity
0/1

If 0, do not load into the applications memory. It's an easy fix which they could probably do in 30min and it would easily make both parties happy.

The gay thing about this post, Rosyna, is that you don't address my Number 1 Gripe with APE; that it slows my system down. And the more modules you have loaded, the slower everything gets. You didn't address it, and you can't address it, because it's a real problem with APE, and it's why I don't (nor will I) use APE. In short, APE is crAPE.

"I propose a key in the Info.plist that looks like this:

AllowUnsanity
0/1"

Users would quickly figure out how to edit their Info.plist files manually and change that flag. Then an APE module would cause a crash and they'd email the developer and you're right back where you started :) If users want to, say, use windowshade in an app, you can be assured that they will do whatever it takes to get that to happen. Putting arbitrary barriers in their way will only delay the inevitable.

It may produce more bug reports to Unsanity ("Why doesn't WindowshadeX work in FooBarApp?") but I don't think that's a particularly useful goal :) Unsanity would just put up a FAQ item explaining the Info.plist key and how to change it and, once again, we're back to where we are now.

Users are demanding little buggers, eh? ;)

I love APE, but cannot use it. There is an incompatibility somewhere between APE / an APE Module and OSXVNC that keeps me from running it. I do not know which side of the fence the bug is coming from, APE or OSXVNC, but VNC is a requirement for me, so APE has gone.

As for the article itself, it should have been more fair about the indeterminate nature of crash reports. Honestly, it's impossible to tell with complete certainty whose code, exactly, caused a crash simply by looking at the crash log. As others have pointed out, an APE module could have corrupted memory somewhere else in the app's memory space, causing another non-APE thread in the app to crash. On the other hand, it's equally possible than a bug in the OS itself is the root cause of the crash, regardless of which thread got tripped up. You can't really tell from a crash log. That's just a starting point in the debugging process.

I think what Rosyna was really trying to say is this: "Just because you see the letters a-p-e in the crash log, that doesn't necessarily mean that an APE module caused the crash."

"I think what Rosyna was really trying to say is this: "Just because you see the letters a-p-e in the crash log, that doesn't necessarily mean that an APE module caused the crash.""

that's true...but to say that every app developer needs to test for APE (module) compatibility is insane, as is the idea that none of the reports that APE (modules) cause problems are correct.

It's the attitude I see here that is making me really start thinking about an "unsanity killer" script.

john

I don't know where I suggested that application developers test every single APE Module for compatibility with their application. I never meant to. If someone gives me a reference to where I made such a suggestion, I will fix it.

I only meant to suggest that developers at least tell us if they believe an APE Module is causing a problem instead of just ignoring the thing altogether, filing it in /dev/null and immediately posting to the internet about how bad APE is.

What about Alex Curylo and his WSX bug reports? I'd like to know Unsanity's side of that story.

Why doesn't Unsanity release the module which changes guikits into dlta?

Yes, guikits and SS are cool.
But I am still 14 years old. Working is even impossible. There is also no pocket money from parents(I don't think that it is unhappy).
I also want to enjoy changing Theme of OSX.
However, SS has the market share of the form of the theme of OSX mostly........
Since there is no money, do I miss fashion? I think that it is strange...

I hate to interrupt everybody's favorite rant, but the reality of crashes caused by APE/haxies are not quite this black and white. I'm about to use logic, reason, and a healthy dose of real life experience and observation in the field of computer science... so feel free to ignore me.

Applications have bugs. System Libraries have bugs. And yes, even APE/haxies have bugs. It is incredibly shorted sighted and quite arrogant to think otherwise, and yet it is human nature to do so. Everybody feels their component is the infallible one, and that any problems are caused by the others.

The reality is that applications, system libraries, and even APE/haxies are never released in an infallible form. Software is just too complex, and unfortunately, coded by beings of very limited ability to understand the context necessary to make the logic infallible. Humans make mistakes, most of them are unintentional. Most software is literally riddled with frailty.

It is better to think of applications, system libraries, and even APE/haxie releases as relative islands of stability. Any given release, of any given component, is reasonably stable when run against the myriad of other components that is in its target operating environment. Commonly established development processes ensure this. Programmers write the code. Testers test the code. Found problems are then give back to the programmers to fix... and the cycle continues. It ends when the testers do not find any more problems. It is incredibly shorted sighted and quite arrogant to think the cycle stops when there are no more bugs to be found, and yet it is human nature to do so.

The reality is that applications break when APE/haxies are added, and system libraries break when APE/haxies are added. Sounds damning to the APE/haxies... except... applications also break when system libraries change... and even system libraries themselves break when other system libraries change.

Why?

The environment the individual components were tested against has changed. Unfound bugs are being brought to the surface. The cycle continues. To suddenly say the rules have changed, that the development process doesn't make sense anymore, that the last modification to the environment is solely at fault is incredibly shorted sighted and quite arrogant, and yet it is human nature to do so.

Its simple cause and effect, and we as humans, are very good at confusing them. It could be bugs in the APE/haxies, it could be bugs in the applications, or it could be bugs in the system libraries. Without convincing evidence, who can say?

Not I.

It's pretty silly all of this FUD being spread considering.. people always jump to conclusions when something crashes or brings down their machine- they have to blame it on _something_, and because people know very little about how software works, they automatically assume something that isn't the case. I'm not surprised.

Great product, zero problem thus far with it.

even the simplest program,
cout has errors in it.

re: John Siracusa

At the time the bug was reported, we asked where to get the application and were told it was still in beta and there was no way for us to get an app to reproduce the issue. This has since changed.

It is really hard to fix something you cannot reproduce.

I can't understand why everybody is blindly defending Unsanity. Obviously they ARE writing very good software. But what they are not doing is to tell their users that patching a system comes at a price, they even try to tell users that their method of patching is no patching per se...

It is inherently dangerous to mess with another application's address space. To imply that the author of that application's code is responsible if an error occurs is just, erm, dumb. How on earth could he/she even know what that haxie is actually changing inside the application?

So how would you feel if you'd spend hours debugging code/supporting dispaired users/not getting several registrations due to a product of another company?

I'm sure APE is avery clever piece of code, but Unsanity MUST be more open about its risks, they MUST educate their users that if there is an error occuring with another program, it might be worth trying to disable APE/put that program on an exclude list and see if the error's still there before contacting the author of that program.

And please remove the "APE might reveal hidden bugs in external programs" crap from your product page. It is misleading and you know it. If you write things like that, you would also have to write that "APE might introduce new bugs in external programs" to stay fair and balanced.

Bravo, rosyna, cricket, alex, concerned developers, and everyone else...

Thanks for posting the article and discussion of the APE Framework and Modules; it provided me with a better understanding of this compex issue from both points of view.

For what it's worth, I continue to use APE Modules, usually without problems, and will continue to do so until I find a reason not to. I haven't found one yet.

Bob
--
Bob "Dr. Mac" LeVitus
wordsmith + raconteur

I wish all these developers, concerned developers and other "concerned" people would tell us what application they are developing that is conflicting with APE. Then when push comes to shove - I (a user, not a coder, not an Apple employee) who will/has paid the money that keeps all of alive - will decide between APE and the Application.

My gut feeling is that APE is so wildly popular that the "concerned" application developers are afraid that their app would sink if users were asked to choose.

I have over 200 apps on my Mac - almost every app including M$ crap - yet I have never had a crash I could attribute to APE. Perhaps APE is not perfect but until some other "concerned" developer can provide someting with the functionality of FruitMenu, Pull-Tab and other haxies - I have no choice but to continue using it.

AM

hmm.

I'm from another school , the support class, ive done Alpha&beta testing , and in anycase it DOSENT MATTER WHAT THE DEVELOPER WANTS

if a user Runs photo shop and it conflicts with excel, whose fault is it ? is what you're asking here

its up to the DEVELOPERS to test with ANY app their customers use in concert with their own.

if quark wouldnt run with photoshop runnign .. where would our graphic designers Be????

thats right , im for unsanity in this one.

if Mail.app users use APE, then the mail developers need to test it (for the sake of their own customers!!!), AND VICE VERSA.

if unsanity KNows somethign dosent work toghether , THEY TELL YOU, they dont say , "uninstall any other applications by anyone NOT us and check again , work now , OK, solved"

Do your users a favor and pay attention to their needs , and Dont say : "my code this , my code that , my code is better than yours, i invented the internet", weenie

Hoop:

Your analogy of Quark and PShop is a wee bit off - neither one of those apps is a haxie and niether is impeding on the other's code.

Developers who have suffered through debugging their software should never have to test for anything other than Apple-supported OS configurations. If a user has a problem with that, discuss it with the author of the software that is breaking rules (which is what Unsanity apps are doing).

As has been reported by many people, the facts are that adding any Unsanity software to your system is a risk that will eventually cause serious problems.

Buyer beware.

Having read this thread I will be less quick to dump on Unsanity haxies, but having said that, the framework is easy to turn off, so troubleshooting will nearly always start with a trip to system preferences to turn the ape off. I just wish every one set their mind to going with cocoa and working wholeheartedly with Apple rather than trying to reinvent a pretty impressive wheel.

>It is inherently dangerous to mess with another application's address space.

Why? What makes this dangerous vs business as usual? Perspective? Apple does this with every system release. QuickTime codec authors do this with every update. OSAX developers do this with every update. CMM plugin authors do this with every update. Etc. It would seem that dangerous application address space meddling *IS* business as usual.

I'm not taking a pro or con haxie stance, I'm just pointing out the hypocrisy of the thought process surrounding them. The differences between dangerous hack and business as usual are often not technically grounded, they are often political beliefs. Humans are very good at obscuring facts behind vague, and often incorrect, beliefs.

>To imply that the author of that application's code is responsible if an error occurs is just, erm, dumb.
> How on earth could he/she even know what that haxie is actually changing inside the application?

This is a common myth shared by most programmers. It is also a very wrong one. Correctly written code will not make assumptions, it will not depend on varient behaviors being invarient, it will not break when exposed to legal behavioral changes. Unfortunately, this kind of code is exceedingly rare, as humans are unable to write it outside of extremely limited contexts.

Ironically, it is the programmer "knowing what is going on" that causes the majority of problems. It causes them to make assumptions they wouldn't ordinarily make in the lack of such information. Programmers use APIs to write code, but they tend to structure their code around behaviors. APIs don't change. Behaviors do, breaking assumptions, exposing bugs.

A bug in a haxie will break an application, there is no denying that. What most programmers are in denial about, is that a legal behavioral change, caused by a haxie, is not a bug... even though it will break an application just the same. It is human nature to assume that working code is correct code, but this belief could not be further from reality.

We don't need fewer haxies. We need better ways to write correct code.

>And please remove the "APE might reveal hidden bugs in external programs" crap from your product page.
>It is misleading and you know it.

There is nothing misleading about it. In fact, it is such an obvious statement of truth, it shouldn't even need to be said. Unfortunately, humans do not live in a world of fact and truth, they exist in a world of belief and assumption, and this is not something that is easy to believe without a full understanding of the facts behind it.

>If you write things like that, you would also have to write that "APE might introduce new bugs in external programs" to stay fair and balanced.

This is true, as well. It is also such an obvious statement of truth, it shouldn't need to be said either. It just happens to be one which most humans already believe. Beliefs and assumptions, they are our greatest strength, and our biggest liability, even in the deterministic world of computer science.

"At the time the bug was reported, we asked where to get the application and were told it was still in beta and there was no way for us to get an app to reproduce the issue."

Errrrrm .... no. Look closer at the email in question -- from me, August 21, 2003, 9:24:20 AM PDT -- and you will see *immediately* following the note that currently it's a beta,

"I'll mail you it directly..."

Are you now claiming that Unsanity's tech support is incapable of receiving an email attachment? Or what, exactly?

"It is really hard to fix something you cannot reproduce."

Well, in general this is true, yes. However, in this particular case, the attached screenshots clearly showed that the problem is that WindowShade was always setting the window structure to the top 20 or so pixels of the bounding rectangle of the structure region, ignoring the *actual* structure region, and thus making the window unusable. It rather escapes me why that problem would not be easily evident just looking at the code where WindowShade calculates what the new structure is to be, or why it would not be easily evident from the screenshots I provided that this was in fact the issue.

But all this is neither here nor there; now that I realize that a copy of the affected application is an irreducible requirement for Unsanity to address a bug report, and I further realize that offering to email them a copy directly does not meet their standards of convenience, I shall proceed to resubmit this bug to them with a link to the freely downloadable version of a product demonstrating it, and hopefully that will meet their requirements. Anyone who'd like to do a followup on Unsanity's responsiveness to developer complaints about their products is welcome to contact me, alex at xten dot com, for updates on how resolution of this issue proceeds.

Reading the arguments about program instability and who is to blame, there is no simple solution. a few possibilities are:

- include in the 'Read Me' of your application a disclaimer about use of haxies and the likes. Hoping that users will actually read the thing :-/
- for the relevant application developers to share their crash logs. If necessary create a closed forum for this discussion - at least have somewhere for the discussion to happen.
- and for Apple (I don't know whether this is already done): provide the possibility for a developer to register something in the info.plist, such as a registered application ID, e-mail address or URL, so that the crash log can be CCed to the developer.

Some of these are maybe a little idealist, but writing quality software takes time and effort. The other problem is users often want to do more than a single developer has energy to support. Trying to work out issues is never easy, especially when you are working on multitasking system where so much can happen at once and in so many ways - developing for a console in this respect is so much simpler.

Re: Alex. The email I quoted was the last one I saw. Otherwise it went to slava (the developer of wsx) and I have no idea what he did with it. I missed the original line about willing to send it.

I've since downloaded the free version and refiled the bug. Hopefully this ugliness won't happen again.

And no, I know of no programmatic way for you to address it. The thing that I wonder about though is why the region suddenly becomes opaque when windowshaded (or minimized). How be you drawing the BG? A custom WDEF, perhaps?

"I've since downloaded the free version and refiled the bug."

Why, thank you. And did you notice that the ReadMe specifically mentions this problem? Well, at least a couple people a week don't get as far as reading that before emailing support whining "what happened to my windows?" It gets kinda old after a while.

"The thing that I wonder about though is why the region suddenly becomes opaque when windowshaded (or minimized). How be you drawing the BG? A custom WDEF, perhaps?"

Drawing is all done in response to update events; the WDEF, which is cribbed from Apple's 'CustomWindow' sample, does nothing except return regions for structure and content. And those regions are identical. You guys are welcome to look over that code too if you figure it would help make this problem go away...

Re: Alex

Taking this to email since you don't get email notifications of when this thread is updated.

Wow. First Rosyna, thanks much for the post. I had started noticing a tide turn against APE. What brought the issue to a head for me was John Gruber's Daring Fireball post, "About the Help Viewer Security Update, and, Also, Why I Don’t Think You Need Paranoid Android." While reading it, I was just disappointed that he seemed to be making unnreasonable statements against APE, without just saying, I don't like it.

Personally, I love Unsanity, APE, and the various haxies I use. They make my life better. So keep up the good work.

As for the complaining developers, I'd probably feel far more supportive if they actually linked to their own websites, instead of to Apple or dummy addresses, or posting anonymously. It doesn't inspire my trust in you, your code, or your product if your posting anonymously.

Admittedly, I'm not your average user, but I expect that most users who go out of their way to adapt their system to function the way they want, do expect that occasionally something bad will happen. Yes, APE Modules can cause crashes. I don't think anyone will disagree with that, and definitely Unsanity has already claimed that this can be true. But so can context menus, other system add-ins like Synergy, or Little Snitch, and a whole host of things better not mentioned. Hell even Apple updates can break previously "perfect" software.

I'm not dealing with how responsive Unsanity is to other developers, because I have no idea whats true across the board or what's just one developer's story. But as a user, I've always felt support by Unsanity. And while I may be willing to give up Shape Shifter or Label X, I'm NOT willing to give up APE, its far to valuable in my day-to-day work life.

> even the simplest program,
> cout > has errors in it.

Well, that one may do... but not all programs have errors...
If I define an assignment statement in a language to have the following structural operational semantics:
-> s' where s'=s[x |-> A[[a]] ]
then I can prove that if I want a program that makes x equal to 5, then this is correct:
x := 5.

I can continue defining rules for each programming language construct (or in fact machine instruction) and eventually be able to prove that a program is correct.

Bob

hmm... appears html is parsed oddly... let's try that again
> even the simplest program,
> cout << "hello, world";
> cout has errors in it.

Well, that one may do... but not all programs have errors...
If I define an assignment statement in a language to have the following structural operational semantics:
<x := a, s>-> s' where s'=s[x |-> A[[a]] ]
then I can prove that if I want a program that makes x equal to 5, then this is correct:
x := 5.

I can continue defining rules for each programming language construct (or in fact machine instruction) and eventually be able to prove that a program is correct.

Bob

I'm not a developer, but I hang with developers a lot, and I'd like to pipe up here…

1) I've always found haxies to be fairly stable, except for iTunes 4.5. I was unable to connect when I had ShapeShifter on. Before contacting Unsanity support I tried a new user with haxies disabled (no issue there) and then enabled the haxies one by one until the issue happened again…at ShapeShifter, in the new user. Yes, I did report this.

2) Haxies can (and do) cause problems/crashes that aren't obvious as being related to the haxie, but they tend to be more subtle. I had one person who was unable to mount disks because of some haxie or another.

3) allgood2: How is APE "valuable in my day-to-day work life"?

4) Rosyna/Alex: I would like to see the result of the e-mail exchange here.

5) Why can't there be forums on Unsanity's site, allowing better discussion of issues around haxies? As it is all support is via e-mail and as such any knowledge of current issues is opaque to the end-user…and it would tend to prevent the kind of collaborative troubleshooting that allows real, deep-seated bugs to be exposed.

Here's an example, at:

http://macslash.org/comments.pl?sid=4549&op=&threshold=0&commentsort=0&mode=thread&pid=73932#73942

Now, that's pretty detailed. And you can get into all the finger pointing you want. But if this is an accurate report, (if), then it's pretty simple...APE is inducing instabilities, that ARE NOT A PROBLEM without APE. If APE is going to diddle every application a user runs, then APE needs to be a damn site more careful about how it screws around in an application memory space. Oh, and when you intercept an action and cause it to do something other than what the action would normally do? That's patching.

john

I am a developer, and there's a few things in here that I find quite disturbing.

1. If there is a theoretical bug in my code that APE reveals (as opposed to an APE or APE module bug), I'm thrilled I've had a chance discover and fix it. If it wasn't APE now, it would have been 10.6 or something a few years from now and a lot more users would have been complaining.

2. Alex Curylo's post and Unsanity's lack of a timely response disturbs me. I hope this is dealt with, and I hope Unsanity is much more responsive and less opaque about problems like this in the future. Obviously, Windowshade is an APE module not the framework, but the distinction matters little if Unsanity won't fix a defect in THEIR OWN module.

One more thing... I agree with what others have said about the APE icon, etc.

It's cute. I don't like cute on my system. Dump it.

I like Haxies. I have no principles behind this liking other than: they work for me; they don't cause me problems; they do cool things which I really miss when they're not installed.

And if you don't like cute - you'll have to ditch the Finder with its icon, for one thing : )

After reading this post, am I correct in believing that APE tags an additional thread onto every running GUI program? I am just wondering why there is a APE thread running in every app developer's crash log.

Thanks,

Curious Reader

In a word:

Yes.

I like how everybody from developers on down feels the need to assign a voluminous amount of blame to the "high and mighty" Unsanity. You have all come here just for your moment on the soapbox, or do you use it and just don't want to admit it?

Honestly.

They make a product. Use it, don't use it; support it, don't support it. Hate it, love it. We all do it for your programs and somehow you don't see a boatload of ppl heading to your UNNAMED products' pages and sites to bash its lack of quality or behavior.

Don't like the icon? Make your own if you're that good, otherwise, sit down and shut up. I've used nearly every product since the first releases, from beta testing to casual user. I've coded several commercial products (I don't feel a need for self-aggrandizement and I'm not here to cross-promote my own agenda, nor am I filing a bug so no need to discuss) and yet somehow I don't see Unsanity as the fifth of the Horsemen unnamed in lore... I must not be on the same stuff as you.

WHO EVER HEARD OF A PRISTINE SYSTEM? Developing for it as a target is like trying to bake in a pan without leaving any residue... impossible. There's no such thing. Within minutes of use dozens of preferences are set, files opened, apps installed, permissions altered, disk sectors fragmented and RAM filled with instruction calls. Never to be 'pristine and unaltered' again. Boo hoo, you have to wade through stack tracks and sift out some extra logging... you poor poor Apple coder you. (no, that doesn't impress me, I've seen your app crash often enough, haxie or no and false-positive enough spam to make a baby domo cry, not to mention the time I naively rebuilt my mailbox thinking it would compact it and instead it ate about 300 emails and 100 date settings, not to mention rule applying within that mailbox, kudos)

As for the suffering independent developer whom Unsanity is usurping the very bread from your mouth... grow up. They aren't stealing anything, if a user finds a reason (such as incompatibility with other apps they've CHOSEN to run) to not buy your product, they probably would have found another (much like piracy.) Step up to the plate, deal with it, develop a product that makes somebody buy regardless (iPhoto 2.0 anybody?) and reap the benefits.

It's your job to provide support... yet you find the time to bitch and moan that Unsanity is ruining your livelihood? Let's look around... Apple drops out Xcode to smack Codewarrior into yesteryear and Metrowerks keeps truckin', working on their product... not pissing and moaning like children whose favorite truck was stolen. It's business. Adapt, evolve, code. maturity++

In a similar vein, if their system is such a hack and inelegant and dangerous and every other evil unleashed from Pandora's Cube then why not develop your own piece of memory-safe, auto-configuring, issue-detecting,crash-proof software. And since you're so amazing, release it as open-source and impress us all instead of sideline bragging about yourself and bemoaning the pain caused by the evil Unsanity.

As both a developer and user, thank you Unsanity.

you need a table of contents for that post...wow.

How about offering an "Include" list instead of an "Exclude" list. This way, users would have to interactively add applications to the affected list on a per-APE-module basis, and then it might be more apparent to the user that they are indeed going to change the way a program runs. Ideally there would be an informative dialog that would pop up, along the lines of "Are you sure you want to use module "WindowShade" to modify the behavior of the application "Mail"?" (Yes) (No) (More Info)

Rosyna,

Re: petey, what do you mean by "doesn't come in a transparent installer?"

------

What I mean is that, unlike the standard Apple installer, I can't see what the APE installer is going to do. Neither is there a log afterwards of what's been installed where.

And, of course, unlike any other software i'm aware of that doesn't deal with hardware, you install into the /System directory. Could this be why you don't tell your customers what is being installed where?

This whole ranting thread, to me, is like having a complete stranger trespassing, sitting in my own backyard and doing his own thing. I never gave him a permission to enter into my yard and I am not required by the federal law to let him enter my yard so he can do whatever the heck he wants to do, but he is already in my backyard doing his thing anyway. If his actions start conflicting with my interests in my own property and start damaging my things, am I somehow obligated to work with him, put up with him telling me how burnt spots he created in my backyard is my fault and cooperate with him so *he* can do what he wants in *my* backyard?

If I make loud noise and my next door neighbor complains, that's one thing I need to correct so both can live happily. If my contract handyman wants to fix something in my house for legitimate reasons, sure. That's in our contract and I would cooperate. But I am not going to deal with a trespasser whining about how messy my house is or how my house is crappy. That's none of his business, and he is wrong in entering my property without my permission in the first place. Now, he might be just sitting there in the corner of my backyard, not doing anything damaging and not complaining about things at all. He could be just sleeping silently and not doing anything there. But his presence is total nonsense regardless of what he does. It might not annoy anyone. It might not annoy me. But it is still nonsense, he shouldn't be there, and he has no right to tell me to cooperate. He could ask me, sure, but I am not obligated to listen to him.

Now, the trespasser might have his own home, and he has the same right I have here. But who's trespassing here?

Now, if the house is indeed messy and crappy, my guests are going to be unhappy. I invite them to my property but they won't like it, they would whine and they wouldn't come again. Sure, the illegal trespasser could've told me that beforehand, so maybe having a bunch of trespassers visiting my property illegally and complaining about things is not such a bad idea. Maybe he's got a million dollars and he would give it to me and my guests if I just allow him to trespass. It might be worth allowing such risk. But what's the catch? What's the trade-off? What's the "flip side" story that I should know about but I don't?

You guess....

Now, people get raped by someone they thought they knew well, and some of your welcomed guests might be mass-murderers. So having an illegal trespasser doesn't necessarily mean it's more dangerous or damaging, or not having an illegal trespasser (and more likely person to damage your thing) does not necessarily guarantee your safety. There is always a risk in everything one way or the other. But I ask myself, "What's more likely and less likely? What's the wise thing to do? What's my priority? What am I willing to take as risk?" Something to think about.

Re: John's MacSlash post. You don't notice something SERIOUSLY wrong with his report that casts a lot of doubt on his assertion it is APE? Namely the fact he rebooted? Why did he feel the need to do that? APE certainly doesn't require it.

It was the reboot that fixed his problems, not the uninstall of APE.

Am I right to assume that a correctly writte program would have no problems whatsoever with a correctly written APE module messing about in its memory space in Mac OS X?

What I remember from the days when I still wrote programs/patches for pre Mac OS X systems is that you needed to be very careful, some functions moved memory and others didn't. This was listed per function in Inside Mac. The OS wasn't pre-emptive and when a patch would move memory during interrupt time or during head patches you'd get unexpected results because the program whose memory moved couldn't have known about it.

Is this different in Mac OS X? Can I freely allocate and deallocate memory in another application's address space without causing problems (assuming the application is bug-free)?

Just for the sake of argument?

Re: pooh.

Since interrupt time isn't an issue any more, it doesn't quite apply to OS X. However, since OS X is multitasking and all that good stuff, thread issues become a huge problem.

Most of an APE Modules code is done on the main thread and APE Modules must only use thread safe calls if they use more than one thread to do work. Otherwise it could cause a race condition. I've created a few of these in the past because I ignored the OS X headers that say whether or not a call is thread safe. I now pay VERY close attention to the headers to know if a call is thread-safe or not.

However, if an APE Module needs to work on a non-thread safe function and the developer of the application calls that function in another thread, the APE Module will also do its work in another thread.

Now, if the addition of an APE Module causes a 100% reproducible race condition in an application that is calling functions that are explicitly not thread safe from another thread, who would you blame? The APE Module author for exposed the race condition or the applications author for using a function in an explicitly unsupported way?

Cocoa's header files and class/method documentation do not list thread safe and not thread safe methods unlike the Carbon headers. The nearest thing I can find to a list is at: http://developer.apple.com/documentation/Cocoa/Conceptual/Multithreading/Tasks/appkit.html

It is a round about way to answer your question, but yes malloc and free are thread safe so they may be used from any thread at any time without some problem occurring. Assuming of course you put a mutex lock on the variable you are freeing or mallocing (if it is going to be used from another thread). A race condition could occur if you do not put a mutex lock on it and one thread tries to free the memory while another thread tries to use the memory. You'd be ripping the memory out from underneath the thread using the memory.

And these threading problems being exposed by APE Modules are become a LOT less frequent as Apple has created more and more DP machines and the developers run into the threading bugs themselves. However, they are still very hard to find on single processor machines. Even harder to fix.

So, why worry about an illegal trespasser alone in my backyard unattended when he isn't even doing anything damaging? Who cares as long as he isn't causing any problems? Well, at least some probably do and should because.....

Say, I notice the fence is broken and my next-door neighbor is complaining. I tell the trespasser, "You know, you are bad after all because you broke my fence." The guy argues, "I didn't do anything wrong. I just punched and kicked just to see, and eventually it broke. That means the fence is not good enough, and you should rebuild it better."

Now, I go out to get materials to fix the broken fence. I come home, and this time I notice my flowers are all damaged. I curse the trespasser, and he argues back saying, "That's not my fault. I was just jumping around the backyard for fun, got tripped and accidentally stepped on those flowers. But there is nothing wrong with jumping around the backyard for fun. It's not like I was murdering people. Why do you blame me?"

I go, "But I never said you can be here in the first place. I was only putting up with you, and I don't have to do that anymore."

The trespasser demands, "Well, if you think I am wrong in jumping around in your backyard and you think jumping in the backyard is illegal, show me the evidence that I really am the one to be blamed."

In the mean time my guests visit my house before I am able to fix the broken fence and clean up the damaged flowers. They laugh at me for not taking care of my yard well, and they think I am a lazy and irresponsible home owner who can't even fix the fence quickly enough.

So maybe this time I will hire a 24-hour security guard so he can watch and stop this trespasser from doing evil. But then a trespasser shouldn't be here to begin with. His presence is nonsense no matter what he does or doesn't do. He came through the backdoor and it isn't technically illegal for anyone to open that door, but I never intended that door as a gateway for anyone to just walk in my backyard and do thing in there without my permission.......

"Re: John's MacSlash post. You don't notice something SERIOUSLY wrong with his report that casts a lot of doubt on his assertion it is APE? Namely the fact he rebooted? Why did he feel the need to do that? APE certainly doesn't require it. It was the reboot that fixed his problems, not the uninstall of APE."

But the report does not say that he actually killed the APE process prior to reboot. You are assuming things just as much as the people you blame to do so.

What does killing the ape process have to do with anything? As I said it was the reboot, not the uninstall of APE that did it. Not sure what he meant by "uninstaller didn't remove all files"

It does remove them all. Unless he is one of those that thinks an uninstaller should delete preferences as well.

Rosyna: I am

"one of those that think an uninstaller should delete preferences as well!"

Why should any part of an application stay on the system when i decide to uninstall an application?

After trying thousands of applications there stay thousands of useless preferences-files. What a mess!

Please decide to uninstall EVERYTHING your application (or haxie) has produced on my system!!!

But preferences are not installed by the installer so why should an uninstaller remove something it didn't even create?

I second fred on this one. The uninstaller leaves a few empty folders even after uninstall is "complete." Now, I am sure Rosyna will be very quick to point out that it shouldn't matter to the stability of the system, but the point is that it *does* leave something that shouldn't be there after "complete uninstallation." When I uninstall something, I delete .plist files and any other files/folders (Application Support is one typical example) because they don't need to be there, and they belong to the app that I am uninstalling. Whether it's the installer created that file/folder is irrelevant, and whether those things cause stability issues is pointless. When I say I leave someone's house, I don't leave my stuff there. I take them with me. At least some users who prefer not to have unused clutters around think "uninstall" means removing that app AND all supporting files (.plist, etc.)

Quitting ape process matters if ape really is the culprit in the OO issue. Simple.