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.

And, sure, you can just say "By definition it is impossible for APE framework to do anything by itself" but that is valid only under the assumption that it really stays that way in reality. If APE Framework has undetected bugs that affect other things in an unimaginable way things start to get iffy. And the fact is that there have been many bugs like that in the past with various things, so.....

As a developer and QA person in this industry for over 15 years, I find the juvenile rantings of some of the developer types on here amusing.

1) The computer belongs to its owner. They have every right to run whatever software they want on it. That may include a developer's software. Which for most developers, is the point.

2) The vast popularity of Unsanity and its haxies should set off the clue light - apparently, a need is being served here that is not being served by another mechanism. Until that other mechanism appears, they will continue to use the one they have. You can either deal, or write the better mousetrap yourself and supplant APE.

3) Since bugs happen, developers have to deal with them. That is part of what they are paid for. If you don't like debugging, and you write completely error-free code yourself, which I am sure is all of the developers on this thread, then you need to find an old single-tasking mainframe and run your apps there, and live serenely.

4) Unsanity is one guy. Apple, whose OS also contains bugs, is notorious for its glacial response to bug reports with a much larger staff. Why the outrage with Unsanity?

It's apparent to me that people like to have a bogeyman, esp. underpaid code drones who feel a need to lash out in reaction to all in their lives that is stale and deadening. Look - admit defeat, confess that Unsanity single-handedly destroyed your ability to function as a developer, and get that job at Wal-Mart! Or D E A L W I T H I T ...

I can indeed deal with it.

I can write a handy script that runs every morning looking for anything from Unsanity and deleting it on every mac on my network and give it to my IT compatriots to do the same, or Unsanity can drop the attitude, and make some good, solid, tech docs available. Even when there are reasonable explanations for why files have to go into /System, giving this "Oh the users wouldn't comprehend this" as a reason is silly. Treating your users like they're dumb is even sillier.

as well, if you read ALL the MacSlash report, there are some pretty good signs that maybe it was an issue with APE or a module. But, as far as Unsanity's concerned, "we are always blameless". Must be nice.

john

As if the whole world revolves around Unsanity. So this hack Framework is fine because it's made by Unsanity and they are proven to be the best programmers because they were able to come up with this clever hack. And APE isn't bad because it's the module that can cause crash. Ironically most modules in question is from the same people who made APE, and since APE modules are useless without APE Framework, the point becomes mute.

What a self-righteous group of people they are.

fred2: I don't know about you but I would complain out loud and try to eliminate if someone is illegally staying in my house without my permission and doing strange things to my house, even if he isn't doing anything damaging. Hack is hack. APE is hack Framework, its modules are entering into other people's property with questionable methods, and it's nonsense no matter how clever that method might be.

"I don't know about you but I would complain out loud and try to eliminate if someone is illegally staying in my house without my permission and doing strange things to my house,"

Oh please, drop the tortured analogy. Its not your house. Its my system, running applications for me. If I choose to use your application in conjunction with Unsanity's products that my choice to make.

Okay, quick question - why does anything need to be installed in /System? The reason was given earlier that the path must be known for dyld (which I confess to not understanding, but I'll gladly take your word for it). However, wouldn't installing it in /Library work just as well? As far as I'm concerned, /System is sacred ground, and I cringe when I even have to load my kernel extensions in there...

And why does APE have to be active for ALL users, instead of just the user I specify?

(I know you say the APE code does nothing without a module, but frankly, I don't believe this. You're spawning a process, and you've got that nice dialog box at startup if I hold down the shift key. Why can't I have my hacks confined to a specific user?)

>>Posted by: Cap'n Hector on May 28, 2004 05:29 PM3) allgood2: How is APE "valuable in my day-to-day work life"?

My system is customized, a lot, but the two haxies that I use frequently, are FruitMenu and MenuMaster. Viewing my current IP, switching locations without opening system preferences, and having my server admin, hard drive, and other repair tools at the ready with out clogging up my dock space as well as being able to assign command keys to launch specific tasks, are just things that I use so frequently but are practically invisible. I often forget that these items aren't components of the OS.

I use the control key + A to launch Activity Monitor, Control + T to launch iTerm (for telnet or ssh), and Control+D to launch Disk Utiltities, as just a few essentials. A folder for "Server Tools", a Folder of basic utiltites, broken down in subfolders by OS (OS 9, OS 10, Win98, Win2k/XP, Win23 (2003 Server). Not having to dig four to five levels deep to access them, and not having them clutter my desktop or dock is perfect.

FruitMenu and MenuMaster are like BuddyPop by Tynsoe and iSeek to me, addictive, possibly life altering. They modify the little things that you have do repetitively daily, from looking up a telephone number to searching on the internet, to launching an application, to just bring forward menus otherwise hidden within other applications. They are timesavers.

"4) Unsanity is one guy. Apple, whose OS also contains bugs, is notorious for its glacial response to bug reports with a much larger staff. Why the outrage with Unsanity?"

Unsanity is not one guy. It's a team of people.

I also have an issue that my e-mails and others were ignored, while criticising posts on this blog are within minutes replied to.

"So this hack Framework is fine because it's made by Unsanity and they are proven to be the best programmers because they were able to come up with this clever hack."

It's not Unsanity-originated: APE is directly based on libPatch which was written by an Apple engineer (Ed Wynne) as a side-project. WindowShadeX used libPatch before APE, and Ed is still listed in the about box (google those keywords for more info from his mouth).

Apple arguably has a right to claim this tech because one of their own wrote it, but they have chosen not to relive the conflict-ridden classic days. Ed was also wise to farm the fun-yet-dangerous tech off to another party to avoid being implicated by his employer as its usage grew more popular.

Now that Panther allows users to automatically send crash logs to Apple, they are flooded with reports. I've been told that one of the ways they cut down on the noise is to discard crashes with ape threads since the probability of a false signal makes it not worth the time to investigate.

"2. Alex Curylo's post and Unsanity's lack of a timely response disturbs me"

Rosyna did promptly contact me in email -- as a response to my last summer's report no less, so clearly Unsanity doesn't just immediately trash bug reports :) -- and we've established that the problem in question also manifests itself with Apple's 'CustomWindow' sample that I cribbed my funny-shaped-WDEF from; so I'm perfectly happy to write off last summer's apparent communications breakdown to an unfortunate mischance.

And that's exactly the point: Unsanity is doing an unnecessary favor by making things trickier and more suspicious for other people, both end users and developers, and there goes a bunch of finger pointing games not going anywhere. Power to Unsanity, good for them. The more attentions, the more sales.

"Oh please, drop the tortured analogy. Its not your house. Its my system, running applications for me. If I choose to use your application in conjunction with Unsanity's products that my choice to make."

Yes, but if your house is on fire, and you cry out to me to help you, and I refuse, because you told me you intentionally started it, don't act all pissy about me not helping you put out the blaze. You set your house on fire, you put it out. Can't put it out? Guess you shouldn't have set that fire in the first place, should you?

It's extremely naive to think that you're going to find a neighborhood full of people who are willing to constantly help out an arsonist who constantly sets his house on fire.

In other words, when a company's tech support asks you to disable APE to see if the problems go away, and the problems miraculously go away, don't expect to get any other answer besides the obvious one. You'd have to be daft to not see where the problem lies.

BTW, I run ClearDock & FruitMenu. I traced a number of crashes to WindowShadeX, so I gave up on it. Yet CD & FM will follow if they similarly misbehave. So far, so good, but hey, I understand the choice I've made.

Interesting thread. As a developer with 20 some years experience (mostly on Winblows platforms and relatively new to OS X) here's my 2 cents, FWIW

1) Unsanity providing an API that uses the gdb to hook into applications is dangerous. Fluffing off this danger with impressive technical back traces to prove it's not my fault disguises the reality of what is really happening here.

One of the great aspects of a modern operating system is that applications run in their own protected memory space so applications shouldn't interfere with the operation of other applications. APE modules are no longer applications that behave this way. Their intention is to affect the operation of an application, thus these APE modules are part of the operating system by their very nature.

2) As part of the test process to determine if a product is ready for release I test them on several different Mac systems. Some are basic installs with no other apps while others are daily use Macs with just about every application installed.

I also try to involve as many beta testers I can, encouraging as many different configurations of Macs as posible. Some of the bugs that pop up in the final release cycle are suprising, but none the less are bugs which get fixed - or if no solution is available they get documented.

From the looks of this thread, it looks like it's worthwhile to set up a system with Unsanity haxies installed as another test bed for discovering bugs or documented incompatibilities.

In a perfect world every users system would be identical to my development system.

Of course, Unsanity doing that would be silly because it's everyone else's job to make sure their hacks don't break applications

As far as I can tell, the vast majority of Unsanity's development time is spent modifying their code so that their software works with the other applications that their customers have installed. That's kind of their whole business, in fact.

If you're a software developer, feel free to tell your customers that your product is not supported when APE is installed. If 90% of your customers use APE, feel free to force them to make a choice. I'm sure another developer will pick up the scraps, in good capitalist fashion ;) But don't curse Unsanity for fulfilling a market demand.

Believe me, things would be a lot worse with 50 individual developers all trying to use their own custom-made code-injection systems. You think one extra APE thread per application is bad? Imagine 2 or 5 or even 10 extra threads, all trying to do similar things. (See the Menu Extras wars for an example.)

"It's extremely naive to think that you're going to find a neighborhood full of people who are willing to constantly help out an arsonist who constantly sets his house on fire."

Nothing like overextending a bad analogy is there?

My house isn't on fire. I just have two cranky developers in my living room playing the finger pointing game. Each one is right about some things and wrong about others.

The only point of this thread seems to be for developers to vent their self-righteous indignation that sometimes users do dumb things and don't fully understand their choices and sometime Unsanity is a part of those choices (good or bad).

"In other words, when a company's tech support asks you to disable APE to see if the problems go away, and the problems miraculously go away, don't expect to get any other answer besides the obvious one. You'd have to be daft to not see where the problem lies."

And thus far noone has brought forth any evidence that users don't actually understand this. I certainly do, and outside the context of the recent brouhaha I've seen little evidence that users don't actually disable APE when tech support suggests it. My own users certainly do.

But, of course, that's not really what your problem is. The problem is that users then want you to take the time to investigate or fix the problem. They have an expectation that your software will be compatible with their other software. For you that might involve *gasp* actually debugging the problem and getting a bug report to Unsanity.

I have little sympathy for those who think this is some heavy burden. Users have high expectations of the software they paid for, and developers may not like it but that's life.

One of my own products right now has a crashing conflict with another developer's products (not Unsanity). Neither of us use APE, mach_inject or the like. Its all 100% Apple documented API. Its 100% reproducible, and I'm pretty sure its his fault (IPC problem). I'm able to make that assertion becuase I _have_ spent the time to debug it. Because my users have a reasonable expection that my software is compatible. I've informed him with the relevant information and put it on the known conflicts list. That's the full extent of my responsibility, but it seems like its a hell of a lot further than some developers in this thread are willing to look.

Re: house analogy.

The way it is being used is REALLY bad. The reality is more like you just bought a lot of land and you ask a contractor to build some property on your new land. He builds a nice pool, a huge house, a guest house, a garage, and the other necessities.

Then one day your best friend from college comes by for a visit. He asks if he could stay in your guest house, and you oblige. He is barely ever inside the main house because the guest house also has all the amenities.

A week or so later. You notice that your pipes are busting from the seam, the wood is starting to crack, and the electrical is shot in the main house due to really poor workmanship. You call the contractor and he comes over per your continued support agreement for anything not force de jure. He then sees your best friend waving to you from the guest house. The contractor says, "Clearly, this is all his fault. This house wasn't designed for use by anyone but you."

And then the contractor just ups and leaves despite the fact that for the entire time your best friend was there, he was in the main house for no more than an hour and that was just to give him the tour.

That is basically what is happening here.

Off-topic, but if a person enters your property non-forcefully, and does not cause any damage, s/he is not breaking any laws. They could walk thought the frint door, sit down and start watching your TV and there's nothing illegal in that.

Kinda interesting...

I agree with an earlier anonymous poster that the incompatibility between APE/one or more APE modules and running VNC with OSXVNC is a show stopper for those of us who want to use our computers as a VNC server. As far as I can tell there is no alternative to OSXVNC that will allow coexistence of APE and running a VNC server on OSX. Correct me if I'm wrong. As far as I can tell Unsanity has not responded to this problem.
John

Re: OSXVNC problem

It's been reported multiple times by multiple people but none of us at unsanity are able to reproduce it. That's why it has yet to be fixed.

Can someone tell me the EXACT steps needed to reproduce it? Many of the bug reports sent to us on it are also rather vague.

"APE breaks VNC" and that kind of stuff.

Unsanity, stay the hell out of my applications! And the chuzpe to claim that all resulting problems are not the fault of APE attests to an outrageous arroganze of you.

Learn to spell chutzpah and arrogance before trying to be an ass, troll.

Clearly you are being the ass here.

"We had only even ONE bug, so blame it on the other guy." Since when is that not arrogance? The whole article is a lame attempt to put the blame on the app developers for problems that are clearly created by APE hacking into their apps. Problems that cost me time, reputation, and money due to lost sales.

I think the main point of the article is to inform the community that APE is not the cause of every crash. That is ok.

However, I think it would be admirable to see Unsanity putting more effort into making their applications work with everything, since they automatically inject their applications into everything.
That is the key, they mess with everything, so they must serve everything.

I think Unsanity has been doing fare so far, but I do not think it is enough. I think the community needs to be more informed about what APE actually does and is. I think that just lightly saying that it is something that can improve your system is not enough.

Unsanity will do what they want, alas. It is sad to have to take into account unknown code that could possibly be injected when you write an application...

Really sad...

Haxies provide functionality that users demand. Unsanity has provided a framework that developers can use. Like John Siracusa said, if APE weren't around, each utility would be using its own unsupported methods to get into applications. I'm glad there's a central API written by a well-intentioned company that lets developers write hacks.

Developers: people are going to use hacks to modify their system if no other method is available. Please recognise that to be a fact instead of wishing it away and blaming the one company that provides a clean way of doing it. By being a central method for hacking the system, APE is beneficial to both users AND developers. And until OS X is full-featured enough or extensible in such a way that hacks are no longer needed, be constructive about communicating with APE module developers about any bugs you find.

As for Unsanity needing to be more supportive or more responsive to bug reports, that's something I can't comment on as I have no experience with.

That's like saying I should tolerate and deal with some homeless guys breaking in my house and stealing food because they need to eat, they are going to do it no matter what and it's just a reality of my neighborhood.

The problem is not modifying the system. It's the trespassing of other people's application space. I don't care how clever its method might be. It is still trespassing, and users should know the consequences of allowing that to happen.

Re: Rosyna's "Best friend" analogy

Actually, here is what really happens:

Then one day your best friend from college comes by for a visit. He asks if he could stay in your guest house, and you oblige. He is barely ever inside the main house because the guest house also has all the amenities.

A week or so later, you notice that your pipes are busting from the seam, the wood is starting to crack, and the electrical is shot in the main house. It turns out that your best friend from college really is a nasty ass liar and you've never known that about him, and he was busting those pipes, breaking the wood and messing with electrical wires in the house just for fun while you were running some errands. you call the contractor and he comes over per your continued support agreement for anything not force de jure. He sees clear evidence everywhere in the house that someone was messing with your house. The contractor says, "Clearly, I can't fix all this under the contract because it is very clear that someone intentionally messed with this house." He then sees your best friend waving to you from the guest house. He goes in to see him and finds a piece of broken wire sticking out of his pocket. He realizes it is clearly the same wire used for the guest house, so he asks what he was doing in the guest house while you were away. He blatantly refuses to admit that he did anything wrong, and blame the contractor and you for making him stay in such a crappy guest house.

Rosyna, you are always right. The OS X platform really should revolve around you guys. Unsanity is *the* best engineering company in the world because they came up with the most clever hack on OS X, and you know what, that really does give you the right to tell other developers to work nice with you because you are better than everyone on this platform. This is especially true since you guys are so popular and all these people would defend your hack. Who cares if many of the APE modules are created by the same people who create the bug free APE Framework. Unsanity rules, and that's the fact. Other developers suck and they should just shut up and listen to what you say because you know better.

Why don't you just say to these whining developers, "Well, if you are jealous, come up with a better hack and I might listen to you a little bit" instead of beating around the bush.

"...they automatically inject their applications into everything."

Each haxie that I've installed - and I only use Unsanity's - includes the option to prevent its use within any individual application. Let's say, for example, out of the 100 applications that a particular user may have installed, your product happens to be the only one that suffers a conflict. Advise your customers to add your application to all of their haxies' Exclude lists. Problem solved.

Or...

You can question their wisdom in having installed a GUI mod that works fine with 99% of their other software, cast generalized aspersions on the product that has greatly enhanced their ease-of-use and increased their daily productivity, recommend that they abandon its use, then come into a forum and whine about how unfair *other's* expectations are.

It seems to me, some folks just enjoy making a situation far more complicated than it needs to be.

Or...

Write a code that blocks Haxies from loading upon launch so your customers won't whine about your crapware.

It seems to me that some folks just don't understand that Unsanity rules and the platform revolves around them since they proved themselves to be the most skilled know-it-all hackers. Whining developers, just shut up and do your job better. Unsanity knows better than any of you. Come up with something better or just shut up and start taking responsibility.

I think its funny that people are attacking whinging developers, like the ones that build Mac OS X. Do you want them and the developers of applications to just pack up and leave the Mac platform? That could be interesting. Unsanity building hacks to use on systems with no apps. :)

"Let's say, for example, out of the 100 applications that a particular user may have installed, your product happens to be the only one that suffers a conflict."

As a specific instance, your windows have funny outlines so WindowShade X trashes them to unusability when triggered? Yeah, let's say that.

"Advise your customers to add your application to all of their haxies' Exclude lists. Problem solved."

No, the problem is *not* solved. Notice above that around last August 20 I first figured out that this example problem was caused by WindowShade. Every distribution after that, from the August 24th beta release up to the present day has had this in the ReadMe:

"The "WindowShade X" system extension from Unsanity, which collapses windows to their title bars when minimized, does not work well with X-PRO and X-Lite's windows, as they have no title bars. If you are running this system extension, we recommend that you add the application to the "Exclude List" found in WindowShade X's System Preferences configuration pane."

Even with that, it seems around 1/5 of a percent of our downloads are still confused enough to send us emails about this when it happens. Which is annoying enough that I don't consider the problem to be solved. I consider a problem to be solved when it no longer exists. If WindowShade was revved to leave alone funny shaped windows, THAT would be a solution. If Unsanity had a programmatic way for me to add myself to WindowShade's Exclude list automatically, THAT would be a solution. But "Advise your customers..." is not a solution. At least, not advising them in a way more obtrusive than a ReadMe file, which would be even more annoying I think.

Re: Alex Curylo

Alex, it is YOUR responsibility to implement a workaround for YOUR customer. Your customer has the right to use Unsanity products, and since they use it with your application no matter what you want them to use, and you know that your customers already use Haxies, it is YOUR responsibility to do WHATEVER IT TAKES to implement a real solution so your customers would be happier. It is YOUR APP's non-standard window that is causing the issue, NOT Unsanity screwing up your app. Don't blame Unsanity for your own proprietary implementation of software.

Unsanity does everything right. I know it. I've used their products for over two years now. All apps work just fine for the most part. I usually get about 3 app crashes per week and a few Finder crashes, and I've seen some apps misbehave. But considering how buggy those things really are these days I am 100% sure it's not APE's fault.

"it is YOUR responsibility to do WHATEVER IT TAKES to implement a real solution so your customers would be happier."

That's why I brought the issue up in this forum, because implementing a real solution is, as far as I can tell, completely in the hands of Unsanity, so bringing it up here *was* "WHATEVER IT TAKES". (At the time, anyway. Seems a little better communication skills when it first came up could have avoided this, but whatever, we all make mistakes.) What real solution do you suggest it is possible that I *could* have implemented without their cooperation? Because if you can think of one, I'll certainly do that and forthwith cease giving a flying hoot what Unsanity might or might not choose to do about it.

"It is YOUR APP's non-standard window that is causing the issue"

Ah, Apple has a documented API which I am using -- correctly, as far as I can tell -- and Apple has on their website a piece of sample code called "CustomWindow" which also demonstrates this issue. So my windows may be somewhat unconventional, but they are definitely standard, if we define "standard" as "using APIs Apple makes public and writes sample code to demonstrate the use of" which seems like a downright sensible definition of "standard" to me.

Now, you are certainly free to think that if I use Apple APIs correctly, and if my window acts the same as Apple's sample code does, that it's still my fault for Unsanity's stuff not working with it -- but, you know, I kinda suspect that the vast majority of people would disagree with you and believe that if Unsanity's stuff doesn't work with Apple's published samples, it's Unsanity's problem, not Apple's, and not of anyone like me who follows Apple's API and sample code to the best of their ability.

"Unsanity does everything right. I know it."

No. If I have a window with a round top -- using Apple's public and documented APIs, and based directly on public Apple sample code -- and when WindowShade is active double-clicking the top results in a mostly white rectangular bar with no active controls available to click anymore, that is not done right. It's that simple.

"If there was a bug in one of your loaded APE Modules, then yes, disabling the APE Framework would prevent the crash. That does not mean there is a bug or anything wrong with the APE Framework it just means that if the APE Framework is disabled, it cannot load the APE Module causing the bug."

That is a bug. Period. Average users could care less, if they remove your product and the bug goes away ITS your product.

Re: Alex

> What real solution do you suggest it is possible that I *could* have
> implemented without their cooperation?

Yes, and it's so simple: Just do not use "CustomWindow" code! Just let it draw the basic window titlebar and be done with your nonsense. You KNOW the CustomWindow code conflicts with WindowShade, and you KNOW your customers use WindowShade. This is what we call "workaround." Got that?

If you insist on CustomWindow, why is it so difficult to tell your customers they should use WindowShade's Exclusion list? That *is* also called "workaround", and Unsanity is being extremely responsible there.

> So my
> windows may be somewhat unconventional, but they are definitely
> standard, if we define "standard"

So is Unsanity's APE Framework. It might be somewhat unconventional, but it is still using Apple-documented APIs.

> but, you know, I kinda suspect that the vast majority of people would
> disagree with you and believe that if Unsanity's stuff doesn't work
> with Apple's published samples, it's Unsanity's problem, not Apple's,
> and not of anyone like me who follows Apple's API and sample code to
> the best of their ability.

Apple isn't the only target here. Your customers have Photoshop, Illustrator, Flash, Entourage, Word, etc. etc. all the other companies' products running at the same time. You are fully responsible for making your app compatible with all those apps your customers are potentially running. Are you just going to ditch your customers if your app conflicts with Adobe's because they aren't Apple?

> No. If I have a window with a round top -- using Apple's public and
> documented APIs, and based directly on public Apple sample code -- and
> when WindowShade is active double-clicking the top results in a mostly
> white rectangular bar with no active controls available to click
> anymore, that is not done right. It's that simple.

No, Unsanity uses Apple's official API as well, so it's YOUR job to figure something out so your app works well with others. It's that simple.

Re: Taikahn

> That is a bug. Period. Average users could care less, if they remove
> your product and the bug goes away ITS your product.

No, APE Modules exposes memory bugs in other apps, so you can't say it's Unsanity's fault. Look at YOUR code first, then PROVE that it is APE's fault by using crash log before blaming Unsanity for your fault.

Thanks for taking the time to talk about these issues, but most of this article is above my head.

I can say however, that WindowShade X has never worked properly on my system. The 3.0 version always caused my input devices to be ignored, and I would have to hit the reset button just to get my computer back. Now, in the 3.1 version, that problem persists, although it takes a short time now before it happense instead of being nearly instantaneous as it was before. However, the 3.1 version no longer responds to double clicks in the menu bar as the 3.0 version used to.

I also purchased ShapeShifter, and have found that it slows my system down noticeably. (I have a Sawtooth with a 1.4GHz G4 upgrade and 1 GB of RAM, and I'm running 10.3.4) The problem is compounded when I am using WindowShade X at the same time. As such, I no longer use either of them and feel that my money was wasted on these products.

Technically, the APE framework and the modules may not be causing crashes, but overall my experience with them hasn't shown me the overall concept works well enough to use on a system that I rely on for my work and research. They DO introduce an unacceptable amount of instability into my system, and that's not something that should be the case for paid products.

Perhaps I entirely missed the point of the article, or perhaps the developers posting here are the ones with their heads too far up their asses to get that point.

The article did not say that APE haxies are never at fault. The article, if you had bothered to read the damn thing, said that the APE _framework_ was _not_ at fault.

And for the people bitching about their programs being mangled by WindowShadeX, I refer you to Apple's published Human Interface Guidelines (which contain _no_ reference to misshapen windows like the ones in question): http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHIGuidelines/
And since you won't bother reading it, I'll just tell you that it states that every window should have, at a minimum, a title bar and a close button. Should you bother to develop an application conforming to Apple's published guidelines, WindowShadeX would cause no problems whatsoever.

"Yes, and it's so simple: Just do not use "CustomWindow" code!"

Let me get this straight. You honestly believe that application developers are supposed to go to Apple's site, look at Apple's sample, which can be found here,

http://developer.apple.com/samplecode/CustomWindow/CustomWindow.html

and then say to themselves "Oh, wait! I can't use this, because Unsanity writes a system extension that doesn't work well with it!"

Welllllll ... I would say you have a rather unusual opinion, then. And one I, and the majority of developers I strongly suspect, are highly disinclined to regard as being sensible.

"If you insist on CustomWindow, why is it so difficult to tell your customers they should use WindowShade's Exclusion list? "

Errrrm, if you go back and read my posts, you will see that is precisely what I *have* done, and that is not sufficient to make my customers' experience as problem-free as I want it to be.

"Are you just going to ditch your customers if your app conflicts with Adobe's because they aren't Apple?"

The significant difference here is that Adobe's applications do not grab mouse events directed at my windows, and do things with them that destroy the usuability of my application. None of your other examples do anything of the sort either, so why you think that bringing them up amounts to some kind of an argument is rather difficult to follow.

"No, Unsanity uses Apple's official API as well, so it's YOUR job to figure something out so your app works well with others. It's that simple."

You are incorrect. Grabbing mouse events out of my application's queue and messing with the structure region of my windows behind my back is *not* officially supported by Apple. And I have figured something out, which is for Unsanity to not mangle custom window structures; or for Unsanity to provide some way for me to tell them to leave my windows alone, since what they do doesn't work. So I have indeed done the simple thing, have I not? If you have any other even simpler solution, I remain eager to hear what that might be so I can implement it immediately.

"And for the people bitching about their programs being mangled by WindowShadeX, I refer you to Apple's published Human Interface Guidelines"

First off, they're "Guidelines", not "Laws". That Apple provides an API and sample demonstrating how to do custom windows is sufficient to remove this from consideration as an argument.

Or would you agree, then, that Unsanity should remove from the market every one of their products that can be shown to infringe these guidelines in some way? No? Then why should anyone else?

"I'll just tell you that it states that every window should have, at a minimum, a title bar and a close button."

Then I suggest that you load up Apple's DVD Player application, to demonstrate in the form of its controller that these guidelines are not meant to be universal laws. My application is intended to simulate a telephone in roughly the same fashion in which DVD Player simulates a remote control.

Hmmmm ... now there's a thought ... if I made them kUtilityWindowClass, would WindowShade keep its mitts off them then? Seems worth a quick try anyway, let me go check that out...

Re: Alex. We've kind of fixed it. The opacity no longer gets trashed. I'll email you a "fixed" version if you wish to try it yourself.

If you change the window type to not have a minimize button, WSX will not affect it. However, it also means you couldn't minimize the window to the dock.

And there seems to be a bug in the CustomWindow sample code or something. If you minimize the window to the dock, the window loses its transparency and shows a white background.

"Re: Alex. We've kind of fixed it. The opacity no longer gets trashed. I'll email you a "fixed" version if you wish to try it yourself."

Please!

"If you change the window type to not have a minimize button, WSX will not affect it. However, it also means you couldn't minimize the window to the dock."

Yeah, that's exactly the behaviour I observed when I tried the kUtilityWindowClass idea just now. Hmmm. Maybe I could enable the kWindowCollapseBoxAttribute just long enough to collapse it when I want to collapse it myself, and otherwise keep it supposedly uncollapsible so WindowShade would ignore it? That should work maybe?

"And there seems to be a bug in the CustomWindow sample code or something. If you minimize the window to the dock, the window loses its transparency and shows a white background."

Yep, I've had a Radar bug in on that for quite a while. Unfortunately, Unsanity is the very apotheosis of responsiveness and attention to developer concerns, compared to Apple...

Ok, I am not against people using different programs on their system, but I believe it is Unsanity's responsibility to cater to everyone else because they are messing with everyone.

That is not hard to fathom, if I am designing a web application for a hospital and they all use Netscape and will not change browsers, I must make my pages accordingly...no IE proprietary stuff or even advanced layouts (well, not easily at least)...

Because my pages will be looked at by everyone there and I know that although my pages may be W3C standards compliant, that doesn't mean jack. I must cater to everyone's needs because my pages will be loaded into Netscape. That's the way it is.

If my stuff must be used by something that already exists, it is my responsibility to support it.

I have to agree with one of the posters way above. Reading the Info.plist files for a key something like "AllowUnsanity" adds perhaps two minutes to the developer's coding time, and could be implemented by Unsanity fairly easily; just have a script that runs to check the Info.plist files in all the usual places (everywhere, say, that the OS looks for system services) and make those non-editable entries in the exclude list.

How about if I remove the gdb attachments from my application. There is code to do this, will APE abide by this? If so it should remove the complaints from my code and move it to Unsanity's where it belongs.

Of course, if APE doesn't abide by the API's correctly it won't work. Rosyna?

Re: Nate

> Ok, I am not against people using different
> programs on their system, but I believe it is
> Unsanity's responsibility to cater to everyone
> else because they are messing with everyone.

Dead wrong.

Unsanity isn't messing with everyone. That's just what people think based on FUD, and that's the whole point of this article. APE Framework does nothing by itself, and it does NOT cause instability. The simple solution for all the whining is to ADD TO EXCLUSION LIST. Unsanity has already taken a great deal of responsibility there (how much work do you think would take to code just that part? It's not a quick coding job), and it is users' responsibility to utilize it.

Re: Alex

You should be totally grateful that Unsanity is helping you to solve *your* problem for free. Rosyna came up with a modified version just so you can solve *your* uncommon issue. He shouldn't have had to, but he did it anyway. That really proves to me very strongly that Unsanity is the right one here, and they care about their customers.

Agreed, APE should check for an external exclusion method such as the "AllowUnsanity"-plist statement.

No, this is the worst developer bullying I've ever heard. It is just as bad as saying W3C standard is meaningless as long as a web site shows up fine on IE/Windows.

Such external exclusion method will practically make Unsanity's products less useful. For example, what would be so great about ShapeShifter enabled only 5 out of 10 apps running? It would make ShapeShifter look like it is malfunctioning, and customers will complain to Unsanity for other developers' fault. That is an organized bullying, and it shouldn't happen.

APE Framework should be enforced and required consistently if users choose to use it, and other developers are to figure out how to work with it because that's what users need and want on their machine.

How about if APE only allowed, by default, modules to only interact with Unsanity - tested applications. In other words, make it an opt-in system, not opt out.

In fact, Unsanity could, in the name of PR and good karma, create a test suite for devs to use if they want that would at least test the effects of Unsanity - created modules on an application on the OS.

This would do a number of things:

1) By default, hacks would only interact with applications that had been tested in some manner. While not foolproof, this would help prevent "I installed APE and module and my system crashed" complaints from happening as much.

2) It would help create a database of issues found with applications and various modules that could be incorporated into the test suite, and maybe periodic "HaxNotes" that developers who were getting bug reports due to APE (modules) could use as a guideline to see what the root cause of the problem is.

3) It would give potential customers of Unsanity products the chance at least to see if they are running applications that weren't tested.

4) It would help Unsanity to get a rep as responsible hackers who are doing more than just telling people "Well, it's nor our fault that your program crashes with APE (Modules)

5) While Unsanity can't do much about third party modules, they could create a module test/certification suite with some kind of silly logo that again, would let people know that this module may not come from Unsanity, but it's at least gone through more testing than "Oh wow, this is SO KEWWWWWL!!!"

6) If there's a continual string of similar bugs that many applications show while interacting with APE (Modules), this kind of testing would be a good way to track this, which would be a good thing, since that would most likely point to an OS bug.

This way, out of the "box", APE and APE modules are operating in the most safe mode, not the most unsafe mode. If people want to add programs to the whitelist, then they have to take a positive action to do it, which makes it more likely that if a problem shows up, it will be found faster.

This makes Unsanity look like a responsibly maker of find haxies, it gives people a more safe way to use haxies, and it helps resolve problems faster. Sounds like a winning idea to me.

Of course the Cynic in me says "FOOL! This is the Mac universe. You cannot have a logical solution at this stage! There must be many more months of accusations and recriminations first!"

john

Re: A fan

Whoa, whoa, hold on a second here.

First, fine, so the APE framework doesn't cause any problems. But the modules appear to be causing problems. Note that the framework by itself is pointless if there are no modules, so saying that the framework is stable is pointless (though it is a positive thing).

Unsanity is not Apple. They are third party developers. Their code injects any module they want into the code of any program running on the system. It actually modifies the execution of another person's program, and the program has no idea that the module is changing its operation. I don't know about you, but in my opinion that means it is the module's burden to play nice with the program. Should Alex Curylo have written his program to detect WindowShade's presence and then write some custom code to take this into account? Certainly not.

Unsanity's programs should not be treated at Apple's level because they are a third party developer. Alex's program utilized standard OS X functions, and if Unsanity changes the operation of those functions, it is not Alex's fault; it is Unsanity's.

Let me bring up another example: If a multiple desktop manager is active like DesktopManager, and on quit it loses every single window that is not on the current desktop, it is not the responsibility of those programs to detect that and recover. It is the responsibility of Desktop Manager to correctly recover those windows.

Now if the program's code is badly written to begin with, then fair enough. Unsanity will just "expose the problem." But if the code is flawless on a stock OS X system and Unsanity's modules prevent it from working, is it really the original developer's fault?...

And by the way, I support a "Deny Unsanity" key in a .plist file - not an "Allow Unsanity" key, there's a difference. If a developer knows that his program's execution will be marred by Unsanity's, he/she should have the right to preemptively prevent this problem from happening instead of forcing it to happen at the user level.

Re: John

The problem with your proposed steps is that it involves in way too much added work to the Unsanity side while also limiting their products to perform system-wide. There are hundreds of developers out there, and Unsanity can't afford to just sit there and wait for them to be on the "white list." In that case, Unsanity's products will never work as intended (modify *all* applicable applications), and Unsanity will suffer a great deal of loss. That's not fair.

I have a question for you: Have you ever used Haxies and tested extensively on your own machines as well as other machines you have access to? So far all the worries, concerns and theoretical dangers you are talking about are only hypothetical. You haven't mentioned anything specific about actually having many issues with Haxies on your own machine. There are hundreds of end users out there using Haxies very successfully, and as long as we have that we must say the people having issues are at fault and they must look into other problems on their computer first before being so quick to blame Unsanity. Maybe what you should do is to actually install Haxies on your machine and see if your system will have any issues. Maybe if you do that you will accept that Haxies are safe and other developers might be at fault.

You should also know that Unsanity is not just about "Oh wow, this is SO KEWWWWWL!!!" There are many users who couldn't live and work without having a customized Apple Menu. WindowShade X really is a must have feature and no users shouldn't be without. You must use them if you need to be at the most efficient working mode. ShapeShifter is what Mac OS X appealing to potential switchers. Without it, UI is just too dull and monopolized.

Re: Peter

I can give you just a few examples of third-party developers working with other third-party developers.

1. DragThing integration of Super Get Info and Path Finder
DragThing has a built-in option to work nicely with Super Get Info and Path Finder so DT can make them open certain windows, etc.

2. LaunchBar integration with Path Finder
LaunchBar has an option built in so a selected item in LaunchBar is sent to Path Finder instead of Finder.

See, developers are working together and integrating each other quite nicely. DragThing users requested the DT developer to work nicely with Path Finder and Super Get Info because that's what they use on their Mac and they must have all of them. So the developer worked on it and made it happen. There is no "Oh, that's not my problem. Talk to Path Finder people" or "Oh, that's not my problem. Talk to Super Get Info people" whining and fussing. So it's quite possible that other developers work more diligently and code their app to work nicely with Unsanity's Haxies.

Enough said.

[The problem with your proposed steps is that it involves in way too much added work to the Unsanity side while also limiting their products to perform system-wide. There are hundreds of developers out there, and Unsanity can't afford to just sit there and wait for them to be on the "white list." In that case, Unsanity's products will never work as intended (modify *all* applicable applications), and Unsanity will suffer a great deal of loss. That's not fair.]

Nonsense, it's perfectly fair. What's unfair is to require developers who aren't Unsanity to test their applications against every existing haxie in every possible situation, which, considering what the frameworks can allow, works out a number of possibilities that approaches infinity. Quite honestly, Unsanity created this problem, they need to take the extra steps to mitigate wherever possible.

[I have a question for you: Have you ever used Haxies and tested extensively on your own machines as well as other machines you have access to? So far all the worries, concerns and theoretical dangers you are talking about are only hypothetical. You haven't mentioned anything specific about actually having many issues with Haxies on your own machine. ]

I tested them long enough to see that they aren't anything you can't live without. I've had enough end user machines that stopped being unstable when I yanked their stuff out to satisfy me that the "oh, it's never Unsanity's fault" line of thought is incorrect.

[There are hundreds of end users out there using Haxies very successfully, and as long as we have that we must say the people having issues are at fault and they must look into other problems on their computer first before being so quick to blame Unsanity. ]

There were thousand of people driving on Firestone tires that didn't have any problems. Should those defective tires have not been recalled since ALL users didn't get into accidents?

Nonsense. How are the people having issues at fault? What, it's the end user's job to test Unsanity's hacks for them now? Are you serious? If your machine is stable, and you install APE (Modules) and your machine is then unstable, and you then uninstall APE (modules), and your machine is stable again, it's perfectly reasonable, and logical to conclude that regardless of root cause, APE (Modules) created an unstable situation that does not exist in a user-noticeable form without them.

[Maybe what you should do is to actually install Haxies on your machine and see if your system will have any issues. Maybe if you do that you will accept that Haxies are safe and other developers might be at fault.]

I've been in the IT biz a looooong time, and there's one rule of Stable Systems that has never been proven wrong:

"The more you pimp up your system, the less stable it will be."

Following this maxim was how I had Mac OS 8.1 FTP servers with 18 month uptimes handling hundreds of GB of traffic a DAY.

I've yet to see a single haxie that was a mission - critical function. Period.

[You should also know that Unsanity is not just about "Oh wow, this is SO KEWWWWWL!!!" There are many users who couldn't live and work without having a customized Apple Menu. WindowShade X really is a must have feature and no users shouldn't be without.]

This is Unsanity's greatest triumph. This new 'racial memory' that makes a feature that only existed IN THE OS from Mac OS 8 to Mac OS 9.2.2 something that you CANNOT LIVE WITHOUT. It's marketing GENIUS, and it's utter tripe.

I can replicate a customized apple menu in the dock in about 15 seconds. If you have Panther, all you need is a classic system folder, and you can have a customized Apple Menu there too...in fact, it's the OS 9 one.

If you use the Script menu, you can have TWO customizable menus, and the script menu is really customizable.

It's how i launch a few select utilities. Only one of my current users have any haxies installed, and since he's a CEO, he does whatever he wants, but he understands that there's potential for problems there. I trust him to not go overboard, he trusts me to wait for his stuff to break. We agreed that if there's ever a problem that is caused by a haxie, Unsanity's or not, they get jettisoned without a peep until a new version comes out that can be tested to see if the problem was fixed.

the rest DON'T CARE. Once I taught them how the Dock and the rest of the system worked, they said, "Cool" and went back to work. Gee...they use a stock system and somehow survive...they thrive even.

[You must use them if you need to be at the most efficient working mode. ShapeShifter is what Mac OS X appealing to potential switchers. Without it, UI is just too dull and monopolized.]

How in the hell is OS Theme switching a way to increase efficiency? What in the name of Ross Perot's ears does "monopolized" have to do with anything. The entire HISTORY of the Apple UI design has been one of saying NO to excessive options. How does the UI increase efficiency and supportability. In fact, it's the opposite, because when you look for help from any stock locations, you have to factor in the changes you've made to your system when using non-haxie aware resources. By modifying your UI in these fashions, you make remote support incredibly difficult, because now, the person supporting you has to hope that you can translate what he/she is saying on a stock OS X system to your tarted-up one.

I also would really love to see if there's any studies that have been done to see how easy it is to use APE (Modules) in a DOS attack.

This is just the most tortured fanboy logic i've ever seen in my life, and is in fact, an insult to the word "logic".

[I can give you just a few examples of third-party developers working with other third-party developers.]

I can give you THOUSANDS, but nothing at the level that Unsanity lives at, and not nearly as wide - ranging.

[1. DragThing integration of Super Get Info and Path Finder
DragThing has a built-in option to work nicely with Super Get Info and Path Finder so DT can make them open certain windows, etc.]

Three applications working together along very narrowly defined functions. What does that have to do with Unsanity modifying potentially every UI op in an application?

[2. LaunchBar integration with Path Finder
LaunchBar has an option built in so a selected item in LaunchBar is sent to Path Finder instead of Finder.]

Two applications working together in a very narrowly defined function, which is SO not what Unsanity does.

[See, developers are working together and integrating each other quite nicely. DragThing users requested the DT developer to work nicely with Path Finder and Super Get Info because that's what they use on their Mac and they must have all of them. So the developer worked on it and made it happen. There is no "Oh, that's not my problem. Talk to Path Finder people" or "Oh, that's not my problem. Talk to Super Get Info people" whining and fussing. So it's quite possible that other developers work more diligently and code their app to work nicely with Unsanity's Haxies.]

you're talking about FOUR separate products working together, and they aren't even working with all four of themselves. How can you compare such a very narrow example, built around integration of specific functions to EVERY APPLICATION in the Mac market having to deal with a framework that allows for what is effectively an infinite number of potential modifications to every application on every Mac.

Gimme a break, this isn't even comparing apples and oranges, it's like comparing a poodle and a Klein bottle.

john

Blaming APE for crashes is like blaming guns for murders.
Blaming APE modules (Haxies) is like blaming the bullets.
Blaming Apple is like blaming society.
I blame the person that pulled the trigger. (Installed on system)

Use at your own risk.

All that said, I won't debug a crash that shows APE in backtrace.
--
Enjoy,
George Warner,
Schizophrenic Optimization Scientists
Apple Developer Technical Support (DTS)

Re: A fan

No, it is not up to Alex or anyone else to fix a bug in an APE Module. It is ESPECIALLY not his job to rewrite his code to not use CustomWindow. It is a bug in our code and we will fix it as we've done hundreds of times before. We work damn hard to make sure an APE works with the most popular applications out there and to make sure that something an APE does will not break any assumed or documented behaviours in an API. If a developer has a problem they think is caused by an APE, we will work just as hard to try to find it and fix it. Usually without having to ask the developer any more information. As long as we can reproduce it, everything will be on our side.

It is our job to do this and we take pride in it. It also has given us a very intimate knowledge of the innards of OS X.

Re: George

That saddens me that some people would ignore what could be a completely legitimate crash report because a user has a particular piece of third party software installed. Wonder what kinds of other third party software is ignored.

Its interesting that you mention talk about developers not understanding APE and telling users to turn it off because its the source of bugs. For some time now I have been testing code - some of it Apples and have received that message (sometimes from Apple) and I knew that what they were saying didn't make any sense. Thanks for pointing that out.

Its a sad state pf affairs when developers won't investigate bug reports but will instead quickly try to blame the issue on someone else.

"Doctor, it hurts when i do this"

"Don't do that"

"Hey, it stopped hurting"

"One hundred dollars please"

in troubleshooting, you find the simplest solution that fixes the most critical problem

APE (modules) can be a convenience, but that is all they are. A convenience. Most of their functionality is in the OS already, but without a zoomie cool name.

If you have a mission critical application that won't run with APE (Modules) and you aren't the programmer of that application, you take the simplest solution...kill APE (Modules) dead, and get on with work. Not many support people have the time to spend verifying, replicating, and dealing with bugs that can be fixed with an uninstall of a non-critical application.

john

"That saddens me that some people would ignore what could be a completely legitimate crash report because a user has a particular piece of third party software installed. Wonder what kinds of other third party software is ignored."

Sure its a legitimate crash report, that could possibly lead to no where. A crash report that doesn't have APE associated with it is going to be a true crash report 10/10 times.

Give them a break, they have thousands of issues to deal with a day, I'm sure they would rather no worrying about debugging issues that you have caused. Doesn't it say something when 2 Apple developers and a scad or 3rd party developers complain?

Two million postings, about three quarters of them are nothing but rants, in one flavor or another. You know, it boils down to two things, if you like the software, use it; otherwise, don't. Stop wasting all of this time writing the same things fifty different ways and be productive. Sheesh, the amount of wasted time rehashing the same stuff all these different ways could have found a cure for something. Heck someone might have even built a better mousetrap, but instead, whining, complaining, etc.

People's minds are already made up and this forum after about the fifty posts became one of slams, accusations, and very little content, but rather strong emotions. Why not spend the time finding solutions to these problems rather than rehashing the same things? That is what resourceful people do. They see issues like these and they find solutions for them, not whine and complain like babies. I guess I expected more out of Mac users than this. Maybe like common sense, common courtesy is just not so common any more, but I have to hope it is.

Bottom line to everyone in this room, actions speak louder than words.

**Let the flames begin**

Re: Rosyna

I am very grateful that you take pride in fixing potential issues. I bet 9 out of 10 crashes, though, are actually caused by a non-Haxie thread, and I bet you have been helping others to fix that quite often as you learn the innards of OS X. Keep up with good works!

Re: John

"Unsanity caused all these issues?" No, Unsanity simply exposed a lot of hidden bugs in other apps. Haxies can expose what's already there, so why is that a problem?

Firestone tire analogy: Yes, if all users didn't get into accidents, there is no reason for them to recall the tires. What's wrong with that?

FTP server example: What's so great about a machine running nothing but FTP server? I run various programs, and in order to be productive I need WindowShadeX, FruitMenu, and ShapeShifter. I think ShapeShifter is a productivity tool in a way because it allows me to redesign the whole UI so I have a set of better looking and more functional buttons.

I don't use the default Dock anymore because it's a bad joke. Script Menu? It still can't override the Apple Menu under OS X. When I get a new computer, the first thing I do is to redesign the OS so it would work well. Quite frankly, I can design the OS MUCH better than Apple to satisfy MY NEEDS. Here is how I do it:

- FruitMenu to make Apple Menu customizable
- WindowShadeX for much better window minimizing behavior
- ShapeShifter to redefine the entire UI so I don't have to deal with Aqua
- Menu Master to redefine menu shortcut keys for added efficiency
- Default Folder X to add much better Open/Save dialog (I don't know how anyone can even be efficient not using it)
- Path Finder to completely replace Finder (Apple Finder is utterly unusable)
- Desktop Manager to expand my work space.
- Konfabulator to monitor my system constantly without having to run multiple apps

My machine is rock-solid stable. I usually have 6~7 crashes a day at application level, but my system never goes down. Those apps are known for buggy anyway (Photoshop, Illustrator, TextEdit and Safari being the most typical), and it is a matter of simply relaunching crashed app. I am always back to work in less than 10 seconds even if an app crashes. I also shut down my machine when I am done for the day and restart in the morning, so that clears up the RAM.

John, you never mentioned that the CEO has actually had any issues with his Haxie. It's working! That tells me something about FUD....

BTW, Path Finder, etc. still run with the rest of the system while doing all the cross-application integration stuff, and they haven't caused any issues, so what's your problem?

Jason, the irony is that this *is* the process to solve the problem. We must discuss this and get to the core of the issue, or we won't even know what to solve or who to blame.

"I bet 9 out of 10 crashes, though, are actually caused by a non-Haxie thread"

Why do you say that? Is it because you have a real reason to suspect so, or because you view everything through an Unsanity-colored filter?

I mean, come on. Do you really have any idea of what "haxies" do? The very name "haxie" is a cutesification of the far more descriptive "hack", which really ought to have a "disgusting" or "gross" adjective tacked on in front. Injecting foreign code into an application is just not good software practice, no matter how much you try to spin it or make it sound cute. You obviously like the functions Unsanity's gross hacks give you, but that doesn't make them less gross.

[Unsanity caused all these issues?" No, Unsanity simply exposed a lot of hidden bugs in other apps. Haxies can expose what's already there, so why is that a problem?]

But the bug isn't there unless the application's process space is violated. Unsanity creates the conditions that allow the bug to show. If those conditions aren't there, the bug cannot be seen. Ergo, Unsanity is a prime contributory cause of the bug.

[Firestone tire analogy: Yes, if all users didn't get into accidents, there is no reason for them to recall the tires. What's wrong with that?]

The tires are still defective. Is it okay to make defective tires and hope nothing bad happens?

[FTP server example: What's so great about a machine running nothing but FTP server? ]

It's a computer performing it's assigned task in an efficient and stable fashion. What other purpose does a computer have?

[I run various programs, and in order to be productive I need WindowShadeX, FruitMenu, and ShapeShifter. I think ShapeShifter is a productivity tool in a way because it allows me to redesign the whole UI so I have a set of better looking and more functional buttons.]

How is a button MORE functional because you customize it? It's a button. You click it, you don't click it. It performs an action when you click it. I'm glad you now have a prettier button, but it's still a button and no amount of specious logic changes a button to anything else.

[I don't use the default Dock anymore because it's a bad joke. Script Menu? It still can't override the Apple Menu under OS X. ]

It doesn't have to. It gives me additional functionality. I don't have to worry about conflicts. I can fully customize it to my needs. Seems to me you're unwilling to think in any way other than OS 9. Maybe you should..."Think Different". You're trapped in the past. enjoy it.

[When I get a new computer, the first thing I do is to redesign the OS so it would work well. Quite frankly, I can design the OS MUCH better than Apple to satisfy MY NEEDS. Here is how I do it:]

Let's understand something. You aren't redesigning a damned thing. You can think that in your wonderful fantasy land, but you aren't redesigning anything. You're laying new siding on, and you're putting a bright fascia on it. But you haven't redesigned anything. Your failure to understand what you're actually doing shows how little you really know about this.

[- FruitMenu to make Apple Menu customizable]

The OS Gives me two customizable menus.

[- WindowShadeX for much better window minimizing behavior]

Opinion. I always found random title bars distracting. The native OS behavior removes them out of my way so they aren't obscuring more currently needed data.

[- ShapeShifter to redefine the entire UI so I don't have to deal with Aqua]

because spending all that time to get a different version of the same thing will give you back all that time. until you need phone support.

[- Menu Master to redefine menu shortcut keys for added efficiency]

The OS will do this without haxies.

[- Default Folder X to add much better Open/Save dialog (I don't know how anyone can even be efficient not using it)]

I find that judicious use of the favorites gives me the same efficiencies as a haxie. I find that people who "can't imagine" this have never actually tried to use the native OS.

[- Path Finder to completely replace Finder (Apple Finder is utterly unusable)
- Desktop Manager to expand my work space.
- Konfabulator to monitor my system constantly without having to run multiple apps

My machine is rock-solid stable. I usually have 6~7 crashes a day at application level, but my system never goes down. Those apps are known for buggy anyway (Photoshop, Illustrator, TextEdit and Safari being the most typical), and it is a matter of simply relaunching crashed app. I am always back to work in less than 10 seconds even if an app crashes. I also shut down my machine when I am done for the day and restart in the morning, so that clears up the RAM.

John, you never mentioned that the CEO has actually had any issues with his Haxie. It's working! That tells me something about FUD....

BTW, Path Finder, etc. still run with the rest of the system while doing all the cross-application integration stuff, and they haven't caused any issues, so what's your problem?

(sorry about earlier partial post...it's late)

[Unsanity caused all these issues?" No, Unsanity simply exposed a lot of hidden bugs in other apps. Haxies can expose what's already there, so why is that a problem?]

But the bug isn't there unless the application's process space is violated. Unsanity creates the conditions that allow the bug to show. If those conditions aren't there, the bug cannot be seen. Ergo, Unsanity is a prime contributory cause of the bug.

[Firestone tire analogy: Yes, if all users didn't get into accidents, there is no reason for them to recall the tires. What's wrong with that?]

The tires are still defective. Is it okay to make defective tires and hope nothing bad happens?

[FTP server example: What's so great about a machine running nothing but FTP server? ]

It's a computer performing it's assigned task in an efficient and stable fashion. What other purpose does a computer have?

[I run various programs, and in order to be productive I need WindowShadeX, FruitMenu, and ShapeShifter. I think ShapeShifter is a productivity tool in a way because it allows me to redesign the whole UI so I have a set of better looking and more functional buttons.]

How is a button MORE functional because you customize it? It's a button. You click it, you don't click it. It performs an action when you click it. I'm glad you now have a prettier button, but it's still a button and no amount of specious logic changes a button to anything else.

[I don't use the default Dock anymore because it's a bad joke. Script Menu? It still can't override the Apple Menu under OS X. ]

It doesn't have to. It gives me additional functionality. I don't have to worry about conflicts. I can fully customize it to my needs. Seems to me you're unwilling to think in any way other than OS 9. Maybe you should..."Think Different". You're trapped in the past. enjoy it.

[When I get a new computer, the first thing I do is to redesign the OS so it would work well. Quite frankly, I can design the OS MUCH better than Apple to satisfy MY NEEDS. Here is how I do it:]

Let's understand something. You aren't redesigning a damned thing. You can think that in your wonderful fantasy land, but you aren't redesigning anything. You're laying new siding on, and you're putting a bright fascia on it. But you haven't redesigned anything. Your failure to understand what you're actually doing shows how little you really know about this.

[- FruitMenu to make Apple Menu customizable]

The OS Gives me two customizable menus.

[- WindowShadeX for much better window minimizing behavior]

Opinion. I always found random title bars distracting. The native OS behavior removes them out of my way so they aren't obscuring more currently needed data.

[- ShapeShifter to redefine the entire UI so I don't have to deal with Aqua]

because spending all that time to get a different version of the same thing will give you back all that time. until you need phone support.

[- Menu Master to redefine menu shortcut keys for added efficiency]

The OS will do this without haxies.

[- Default Folder X to add much better Open/Save dialog (I don't know how anyone can even be efficient not using it)]

I find that judicious use of the favorites gives me the same efficiencies as a haxie. I find that people who "can't imagine" this have never actually tried to use the native OS.

[- Path Finder to completely replace Finder (Apple Finder is utterly unusable) ]

Troll

[- Desktop Manager to expand my work space.]

Multiple monitors and Expose.

[- Konfabulator to monitor my system constantly without having to run multiple apps]

Do you even have any CPU for actual work? How long does it take you to actually start working.

[My machine is rock-solid stable. I usually have 6~7 crashes a day at application level, but my system never goes down.]

If you are having 6-7 application crashes a day, it's not stable. I'm glad you can talk yourself into it, but crashes != stabilty.

[Those apps are known for buggy anyway (Photoshop, Illustrator, TextEdit and Safari being the most typical), and it is a matter of simply relaunching crashed app.]

that's funny, I run all of those for days at a time, and they never crash on me. Hmm...and I have no haxies....and I have no application crashes.

[ I am always back to work in less than 10 seconds even if an app crashes. I also shut down my machine when I am done for the day and restart in the morning, so that clears up the RAM.]

Gee...I have none of those crashes, and I go days between restarts. So I don't lose any of the time you do every day. Which means that my true effciency and uptime is far and away better than yours, because, your efficiency is zero when you're restarting applications and rebooting.

[John, you never mentioned that the CEO has actually had any issues with his Haxie. It's working! That tells me something about FUD....]

It shows that you have no clue about statistical sample validity. I'm not saying that APE (Modules) are unstable in all circumstances. But they do induce instabilities, and your "6-7 application crashes a day" (your words) show that I'm right.

[BTW, Path Finder, etc. still run with the rest of the system while doing all the cross-application integration stuff, and they haven't caused any issues, so what's your problem?]

You have 6-7 application crashes a day, where I don't. 6-7 application crashes a day are unacceptable. that shows an unstable system, when an application is unable to perform its required tasks without constantly crashing.

You have enthusiasm, but your logic is, shall we say, suspect. And, just a minor point...I'm posting my name and contact info...why aren't you doing the same?

"...But 'Advise your customers...' is not a solution. At least, not advising them in a way more obtrusive than a ReadMe file, which would be even more annoying I think."

It's Unsanity's fault you sell software to people who can't read?

[Sorry, just couldn't resist. (-:]

"I also purchased ShapeShifter, and have found that it slows my system down noticeably. (I have a Sawtooth with a 1.4GHz G4 upgrade and 1 GB of RAM, and I'm running 10.3.4) The problem is compounded when I am using WindowShade X at the same time. As such, I no longer use either of them and feel that my money was wasted on these products."

Do you happen to shut down or sleep your Mac at night, Paul? If so, the regularly scheduled *nix underpinnings' CRON maintenance scripts won't be able to run - old caches, log files, etc. accumulate - and that may cause some things to bog down after awhile. (If that's the case, you could do the maintenance stuff manually with Cache Out X, Cocktail, or another like utility periodically.)

YMMV, of course, but I'm wondering about the above because ShapeShifter, WindowShade X, and several other haxies are rolling here, and they cause no noticeable app slow-downs nor other issues on my li'l eMacster - and it's only a 1 GHz w/640 MB of memory.

(I do run all of Cocktail's Pilot options, except the prebinding, nightly, with it set to shut down automatically. Maybe that keeps everything "tuned up" and problems don't occur?)

I had to uninstall an ape cursor module due to it jumping my cursor around randomly, and I've put many apps on the exclude list. Ape does make me wary, but some modules are desired so i've stuck with it (in a limited way). I'd say modules need better testing,

And i really do think unsanity should go the way of an "include list" rather, or a "exclude all but.."

I Agree Apple should include better plugin support, but then Unsanity's ape would be out of buisness...

Re: John

>

See, that's been the whole point: People just *believe* it's Unsanity's fault when it really isn't, and after the lengthy explanation of APE Framework people still believe in the same thing.

>

My question is whether APE Framework is defective. It isn't, and I am sure Firestone didn't make defective tires intentionally. So it's unfair to blame either one of them for something they didn't do.

>

I might as well use Linux under CLI if performing functions is all there is to the matter of personal computing.

>

Check out Resexcellence.com, follow the "Snapshot" link and see what people are doing with a bunch of gorgeous desktops. It makes a big difference in how you feel about your personal computer. Most of them use Unsanity's ShapeShifter, and they look very functional. And I am sure those people aren't having all the problems that you are telling me about.

>

You know, I think you are trapped in the narrow-minded thinking of "lean and mean." You must be enjoying a very boring and plain flat personal computing with no sense of personality.

>

Please don't be so defensive! I know a lot about these things, and I don't have to prove that to you.

>

Wrong, unless you are willing to go deep into application package and modify text strings in there using Interface Builder.

>

Use of the favorites? What are you talking about?

>

What? Do you really believe that Apple Finder is usable? My Finder crashes, and it's slow. Path Finder has extra features like terminal window attached to its file browser, which allows me to conveniently jump to a certain folder via GUI and type some commands from there. "Drop Stack" feature is the absolute must-have for moving multiple files, which Finder doesn't let me do as quickly as Path Finder does. Path Finder also supports burning disks.

>

Oh yes. I have about 80% CPU time left with all these utilities, and 20% isn't a huge deal considering my machine is somewhat obsolete (PowerMac G4 QuickSilver).

>

You must be either lying about it or just refusing to admit that you ignore just a few crashes, calling it "insignificant hick-up." And what's wrong with shutting off the machine at night? I wouldn't be using it, and it is wasteful to leave it on.

Nobody has claimed that OS X can't have application crashes. Application crashes don't count as long as the SYSTEM is stable, and my system is quite stable, free of crashes and not much slow-down. So my system is indeed rock-solid stable, and a simple relaunching always fix the application crash, so it shouldn't be a huge deal.

BTW, I don't put my name and contact info because spammers are out there picking up those. Common sense that you don't seem to have.

Re: John

"Unsanity creates the conditions that allow the bug to show."

See, that's been the whole point: People just *believe* it's Unsanity's fault when it really isn't, and after the lengthy explanation of APE Framework people still believe in the same thing.

"Is it okay to make defective tires and hope nothing bad happens?"

My question is whether APE Framework is defective. It isn't, and I am sure Firestone didn't make defective tires intentionally. So it's unfair to blame either one of them for something they didn't do.

"It's a computer performing it's assigned task in an efficient and stable fashion. What other purpose does a computer have?"

I might as well use Linux under CLI if performing functions is all there is to the matter of personal computing.

"How is a button MORE functional because you customize it?"

Check out Resexcellence.com, follow the "Snapshot" link and see what people are doing with a bunch of gorgeous desktops. It makes a big difference in how you feel about your personal computer. Most of them use Unsanity's ShapeShifter, and they look very functional. And I am sure those people aren't having all the problems that you are telling me about.

"Seems to me you're unwilling to think in any way other than OS 9. Maybe you should..."Think Different". You're trapped in the past. enjoy it."

You know, I think you are trapped in the narrow-minded thinking of "lean and mean." You must be enjoying a very boring and plain flat personal computing with no sense of personality.

"Your failure to understand what you're actually doing shows how little you really know about this."

Please don't be so defensive! I know a lot about these things, and I don't have to prove that to you.

"The OS will do this without haxies."

Wrong, unless you are willing to go deep into application package and modify text strings in there using Interface Builder.

"I find that people who "can't imagine" this have never actually tried to use the native OS."

Use of the favorites? What are you talking about?

"Troll"

What? Do you really believe that Apple Finder is usable? My Finder crashes, and it's slow. Path Finder has extra features like terminal window attached to its file browser, which allows me to conveniently jump to a certain folder via GUI and type some commands from there. "Drop Stack" feature is the absolute must-have for moving multiple files, which Finder doesn't let me do as quickly as Path Finder does. Path Finder also supports burning disks.

"Do you even have any CPU for actual work? How long does it take you to actually start working."

Oh yes. I have about 80% CPU time left with all these utilities, and 20% isn't a huge deal considering my machine is somewhat obsolete (PowerMac G4 QuickSilver).

"Which means that my true effciency and uptime is far and away better than yours, because, your efficiency is zero when you're restarting applications and rebooting."

You must be either lying about it or just refusing to admit that you ignore just a few crashes, calling it "insignificant hick-up." And what's wrong with shutting off the machine at night? I wouldn't be using it, and it is wasteful to leave it on.

Nobody has claimed that OS X can't have application crashes. Application crashes don't count as long as the SYSTEM is stable, and my system is quite stable, free of crashes and not much slow-down. So my system is indeed rock-solid stable, and a simple relaunching always fix the application crash, so it shouldn't be a huge deal.

BTW, I don't put my name and contact info because spammers are out there picking up those. Common sense that you don't seem to have.

["Unsanity creates the conditions that allow the bug to show."

See, that's been the whole point: People just *believe* it's Unsanity's fault when it really isn't, and after the lengthy explanation of APE Framework people still believe in the same thing.]

You can explain APE all you want. But if you have a stable system with no crashes, and you install APE (Modules) and you then have crashes, then APE created the conditions that cause the crashes due to its interaction with whatever is crashing. The specific bug may or may not be in Unsanity's code, but they expose the conditions that cause the crash. To use your (rather poor) logic on the tire issue, if the only reason that crash happens is because of how APE (Modules) are interacting with the item that's crashing, then why should the non - unsanity developer change their code?

["Is it okay to make defective tires and hope nothing bad happens?"

My question is whether APE Framework is defective. It isn't, and I am sure Firestone didn't make defective tires intentionally. So it's unfair to blame either one of them for something they didn't do.]

Actually, there was considerable evidence that FIrestone knew the tires had issues. they just took your tack, and hoped nothing bad would happen. You're missing a point. The fact that APE (Modules) interact with applications at a low level and causes unpredictable issues doesn't mean that APE (Modules) are defective. It means that they are diddling applications at a low level, where crashes are likely to happen, and Unsanity needs to be more bloody careful, and get off this attitude of "It's never our fault".

["It's a computer performing it's assigned task in an efficient and stable fashion. What other purpose does a computer have?"

I might as well use Linux under CLI if performing functions is all there is to the matter of personal computing.]

That's ALL there is to computing. You have a task that needs doing, the task gets done. Stop anthropomorphizing your computer, it clouds your judgment. The computer doesn't care. It's just a thing. really.

["How is a button MORE functional because you customize it?"

Check out Resexcellence.com, follow the "Snapshot" link and see what people are doing with a bunch of gorgeous desktops. It makes a big difference in how you feel about your personal computer. Most of them use Unsanity's ShapeShifter, and they look very functional. And I am sure those people aren't having all the problems that you are telling me about.]

How I FEEL about my computer is that i want the OS to be invisible. I don't want to deal with it. I use applications. The OS is just an enabler. I don't want to like or dislike my computer. I save human emotions for humans. The BEST feeling that my computer can ever engender in me is to be stable, and problem free enough that I cannot remember my last crash or reboot. If I have a server that I forget is there, it's a perfect server. I don't want, nor require machines to ask my how my day was, blow me kisses and buy me dinner. Just do the friggin' task quickly and efficiently.

["Seems to me you're unwilling to think in any way other than OS 9. Maybe you should..."Think Different". You're trapped in the past. enjoy it."

You know, I think you are trapped in the narrow-minded thinking of "lean and mean." You must be enjoying a very boring and plain flat personal computing with no sense of personality.]

God I hope so. I cannot stand goobers who can't get through the day without their friggin' machines cooing at them. Jesus, why not port Bonzi Buddies over to Mac OS X so you can have half-naked women swinging from your Finder windows. The work I do, and the things I create using the TOOL is the personality. I don't need the tool to be anything more than a tool. I want simple, elegant, efficient design that allows me to do my thing. spending hours pimping up my system so I can then set it up to do work is none of that.

["The OS will do this without haxies."

Wrong, unless you are willing to go deep into application package and modify text strings in there using Interface Builder.]

Seems to me you're being the narrow - minded one here, and refusing to see that haxies are just toys to make you feel like your mac actually cares about you.

["I find that people who "can't imagine" this have never actually tried to use the native OS."

Use of the favorites? What are you talking about?]

You don't even know how to use Favorites in the Finder Sidebar or the Dock? Yet you lecture on how to use the GUI efficiently? You don't even know how the thing you're changing works, so how can you tell if you're more efficient?

[What? Do you really believe that Apple Finder is usable? My Finder crashes, and it's slow.]

And the fact that you're patching half a dozen basic UI behaviors couldn't have ANYTHING to do with that....no not at all. Must be you, because my finder's solid as a rock, and damned zippy too. but then, I know the Finder and it's features intimately. Which is why I don't need to tart it up with haxies. Did i mention that my finder never crashes?

[Path Finder has extra features like terminal window attached to its file browser, which allows me to conveniently jump to a certain folder via GUI and type some commands from there.]

Shift-cmd-G in the Finder lets me jump to any folder I want. Launching terminal (a one time 3 -second penalty, which is about what the initial launch of pathfinder takes) and doing a D&D into the window works fine for pathing things out. Did I mention that my Finder and applications don't crash?

["Drop Stack" feature is the absolute must-have for moving multiple files, which Finder doesn't let me do as quickly as Path Finder does. Path Finder also supports burning disks.]

I just use the terminal for that, or a script I wrote years ago. quite simple really, and no haxies to worry about. Just using the native capabilities in an innovative fashion. Did I mention my Finder and applications never crash? And I've yet to have a problem with using the Finder or Disk Utility for burning disks, so a feature that duplicates an existing feature is not a reason for me to waste CPU cycles. And my Finder never crashes.

["Do you even have any CPU for actual work? How long does it take you to actually start working."

Oh yes. I have about 80% CPU time left with all these utilities, and 20% isn't a huge deal considering my machine is somewhat obsolete (PowerMac G4 QuickSilver).]

Yeesh! I only lose that much when I'm actually doing work. I've got 8 applications, including Word/Entourge 2004 and Indesign CS running, and I only use 20% of the CPU during a mail check or when the applications are actually doing work. You really lose 20% of the CPU to just sit there? that's nasty. Yet another reason to not use Haxies.

Oh yeah, and my applications don't crash.

["Which means that my true effciency and uptime is far and away better than yours, because, your efficiency is zero when you're restarting applications and rebooting."

You must be either lying about it or just refusing to admit that you ignore just a few crashes, calling it "insignificant hick-up." And what's wrong with shutting off the machine at night? I wouldn't be using it, and it is wasteful to leave it on.]

No. a crash is a crash. They are unacceptable. If I have an application that is crashing, something's wrong, and I work to fix it. 6-7 application crashes a day would really suck. How can you get work done? you must have to save constantly. As well, I use the night time for things that would otherwise bog down my network, such as backups, and other maintenance. all my machines are doing something useful 24x7. See, when you aren't crashing constantly, you can leave applications up and running.

[Nobody has claimed that OS X can't have application crashes. Application crashes don't count as long as the SYSTEM is stable, ]

Um...how do you work with a crashed application? You don't. An OS sitting there and doing nothing is a useless waste of money and energy. My macs have a much more advanced purpose than running haxies.

[and my system is quite stable, free of crashes and not much slow-down. So my system is indeed rock-solid stable, and a simple relaunching always fix the application crash, so it shouldn't be a huge deal.]

But you cannot get any work done from the point when the application crashes until it's back up and your document is open. As well, depending on the application and its save behavior, you then have to redo all the unsaved work you did prior to the crash. Assuming you don't have document corruption. Man...6-7 times a day...you have a funny definition of stability.

[BTW, I don't put my name and contact info because spammers are out there picking up those. Common sense that you don't seem to have.]

I avail myself of the many fine anti-spam tools out there, and therefore have no problems. As well, you do realize you can put your name up without putting your email address out there as well.

But then, you do seem to have issues with native functionality. Maybe Unsanity should make a PHP haxie that winks at you, and THEN you could enter your name.

john

Re: John

"You can explain APE all you want. But if you have a stable system with no crashes, and you install APE (Modules) and you then have crashes, then APE created the conditions that cause the crashes due to its interaction with whatever is crashing."

Well, I guess we will have to go over the basic of how Haxie works and why I firmly believe that my crashes (though not a huge deal as I've been telling) are not caused by Unsanity's APE by looking at the quote from MacNN forum:

------------------------------
quote:
'APE breaks through memory protection from application to application'

No, it doesn't. I understand that this is a simplification that folks are using, but its not true except in the grossest terms and its been repeated so often that people have forgotten the real explanation of this.

Memory protection isn't "broken" by APE, it never existed in the absolute sense that folks seem to believe. A system that didn't allow processes to share memory would be useless. They could never communicate. You couldn't interact with them because they would have no way to receive events from the hardware.

There are documented, well-defined ways to pass or share memory between processes in MacOS X. One example is mach ports, and the various structures built on them (NSConnection, Distributed Objects, etc.). These are a feature of the OS and they are used pervasively throughout the system.

All too often in the recent rash of APE discussions people claim that these mechanisms are for debuggers only, but that's simply untrue. Everytime you change a hardware setting, everytime an keystroke event from your keyboard leaves the kernel, mach ports made that happen.

APE uses that same mach port mechanism to load code into other applications. You can argue that using that mechanism to patch code is potentially risky and I would agree (so long as you said "potentially"). However, memory protection wasn't violated any more than the kernel passing keyboard events violates memory protection. Both required different processes to share memory.

What's more, there are several other ways besides APE that applications can get inside other processes. APE is simply the most visible because its popular with developers. Ironically its popular becuase in fact is _safer_ than a lot of the other alternatives. Mach inject does the same thing, but its much harder to use, and developers have to be much smarter and more careful when using it.
------------------------------

So, because of this basic technicality of the matter, it is most likely something other than Haxie causing a few crashes, and I think it's the buggy codes in some of my apps (i.e. Adobe apps, etc.) It is clear that APE module uses nothing more than all the standard methods of injecting codes. See, APE isn't the only one doing it. Desktop Manager works globally. Font utilities patches the system to add extra font management capability, and Apple recommends using them. I use Norton Utilities and it patches the system to constantly monitor my computer's health. I often defrag my hard drive. OS X can't do that by default. Default OS is for beginners. You need third-parties adding features if you want a serious OS.

As far as I am concerned, bug is bug no matter how it's hidden. Developers should fix it without complaining.

"Actually, there was considerable evidence that Firestone knew the tires had issues. they just took your tack, and hoped nothing bad would happen."

Everything has risks, and there is no such thing called "Perfect product." I don't think Firestone is an exception to the rule. Thousands of Ford owners using Firestone tires are driving just fine. We don't need to overstate things.

"That's ALL there is to computing. You have a task that needs doing, the task gets done. Stop anthropomorphizing your computer, it clouds your judgment. The computer doesn't care. It's just a thing. really."

So are you saying that customizing your car with a custom racing kit, racing wheels, a high performance exhaust and a supercharger is totally meaningless? It's all about performance and drivability. In the similar manner I add Haxies to add values and productivity enhancements so my computer would perform better for my needs.

"The BEST feeling that my computer can ever engender in me is to be stable, and problem free enough that I cannot remember my last crash or reboot."

So you are saying CrashReporter is useless hack? BTW, that thing is working with all apps globally to detect what's going on. How is that technically different from Haxies?

"spending hours pimping up my system so I can then set it up to do work is none of that."

I don't spend hours pimping up my system. When I first installed it I may have spent maybe about an hour configuring the way I wanted. After that everything has been just a smooth sailing for the most part.

"You don't even know how to use Favorites in the Finder Sidebar or the Dock?"

Oh *that* Favorites feature......

The problem is that there is only one Favorites folder, and it tends to get crowded. Sidebar can't hold any more than 20 items or it will be very clumsy. FruitMenu, on the other hand, gives me a quick access to many shortcuts neatly organized by categories. And FruitMenu lets me access them via contextual menu, which OS X Favorites folder can't do. If you want contextual menu access, you need FruitMenu.

"I know the Finder and it's features intimately. Which is why I don't need to tart it up with haxies. Did i mention that my finder never crashes?"

Well, it's hard to believe anyone's Finder not crashing at least once a day, but that aside, why steep learning curve to learn Finder features when I can just go download Haxies and Path Finder and be done with the whole thing?

"Shift-cmd-G in the Finder lets me jump to any folder I want. Launching terminal (a one time 3 -second penalty, which is about what the initial launch of pathfinder takes) and doing a D&D into the window works fine for pathing things out. Did I mention that my Finder and applications don't crash?"

Terminal, by the way, is another app that crashes A LOT on my machine. Path Finder's terminal is better. Apple needs to fix this.

"And I've yet to have a problem with using the Finder or Disk Utility for burning disks, so a feature that duplicates an existing feature is not a reason for me to waste CPU cycles. And my Finder never crashes."

The problem with Finder disk burning is that it has to create a disk image of the whole CD content first, which takes too much time. And I've run into many stalls and crashes during the copying phase.

"Yeesh! I only lose that much when I'm actually doing work. I've got 8 applications, including Word/Entourge 2004 and Indesign CS running, and I only use 20% of the CPU during a mail check or when the applications are actually doing work. You really lose 20% of the CPU to just sit there? that's nasty. Yet another reason to not use Haxies."

You should check the fact using Konfabulator CPU monitor before accusing me of false statement. Mine always floats around 20~30% CPU, and I think it's similar to a car idling at the stop light. Engine never stops moving, but that doesn't mean it's broken.

"No. a crash is a crash. They are unacceptable."

That's an impossible expectation. Apps crash. It's just a part of the game. APE is one of a few things on my machine that never caused any crashes.

"But you cannot get any work done from the point when the application crashes until it's back up and your document is open."

But most applications relaunch within 7~8 bounces, which is a few seconds. What's so big of a deal?

Just kicking some (hopefully) unoffensive opinions from my own experience.

There are creative minded, right-brained, people who do use Macs simply because we used OS 9 that allowed us to customize our workspace. As for me, I have made the switch to OS X and love it especially for it's stability. I like my computer to be functional as well as pleasing to use.

I use my Mac for music sequencing, composition, and arranging, video production, and web design. I am a very right-brained person. I LIKE my Mac to look different than everyone elses AND I want my Mac to be a stable tool on which I can depend. I have both. I feel John, that you may be reacting a little too harshly to those in the Mac community who don't like Aqua and want to change it. I do not anthropomorphize my Mac. That's just silly. True, customizing the interface does not change the function, but for me, it's like having to work with a Casio keyboard vs. a Steinway grand piano. Both can give pitch and allow me to do my work, but I prefer to work with the Steinway. Please don't read too much into this example - it just is a more enjoyable experience for me.

I have no problems with those who desire their Macs to be no frills, bare to the bones workstations. It does what it's supposed to do and that's that. I use haxies and am prepared for the possible consequences. By the by, my Mac is ROCK solid. I haven't had an OS crash since 10.0 and VERY rarely have I had an application crash. Before I am jumped on for even having an app crash, let me say that I use the very same app on a very similar machine with no haxies installed and it still crashes occasionally.

The haxies provide me with functionality that may be reproducible using scripts and commands. But hey, I don't have the time or the desire to learn them. I want my time to be productive from the get go.

Haxies installed:
FruitMenu
WindowShadeX
MightyMouse
ShapeShifter
ClearDock
Xounds
USBCam
ParanoidAndroid

Last crash - can't recall. It's been months if not years.

I will not post my email here but if you really want to contact me, respond and I will send you my email for further discussion.

MaestroJAL's comments even reinforce my view that Haxies really are good to use. John, I think you have a long way to prove that you are right......

"So, because of this basic technicality of the matter, it is most likely something other than Haxie causing a few crashes, and I think it's the buggy codes in some of my apps (i.e. Adobe apps, etc.)"

Well goodness... I wrote the quote you refer to, and I don't agree with this assumption.

Haxies have risks. Period. They are a potential source of crashes in applications. You should not assume that all bugs are the fault of Adobe and other developers. Of course, you should also not assume all bugs are the fault of the haxies. APE provides an exclusion list, and its a good place to start when you have an application crashing.

The quote you posted was in response to an assertion that plugins were "invited in" and therefore fundamentally different than APE. The discussion revolved around memory protection as an absolute thing that only APE got around ("broke") by using some dark secret API. The point was that in fact the mechanism used is not secret, and memory protection is not absolute. It doesn't speak at all to whether you application crashes are the result of haxies or not.

[So, because of this basic technicality of the matter, it is most likely something other than Haxie causing a few crashes, and I think it's the buggy codes in some of my apps (i.e. Adobe apps, etc.)]

I don't have problems with Adobe apps crashing. Certainly not in the magnitude of 6 to 7 times a do as you have. You are a example why Haxies cost developers time (in providing additional support to their customers), reputation, and money.

Re: A fan

6 or 7 crashes isn't good. At all. I've got let's see... 12 APEs currently active. Some third party. I try to run every APE someone makes for at least a month to make sure no issues arise. Anywho, if I crash once in a week I get angry.

I did have this weird problem with Photoshop CS crashing on every single launch. Couldn't track it down. Created a new user and tried to launch Adobe CS. No problem. Thought it might be an APE Module. Disabled them all in my user account. Still crashed. Did the same with Fonts. Still crashed. Tried deleting the preferences. Still crashed. Removed entire library folder. Crashes stopped. Put it back. Crashed. I got fed up with all this "Move this and see if it crashes" lameness so I just modified one of my APEs to log every single call to open() (it opens files). I noticed that .GlobalPreferences.plist kept getting listed whereas nothing else but APE preferences were listed in the log. So I deleted .GlobalPreferences.plist. Problem fixed. Crashes gone.

So here is a case where an APE helped me track down a very obscure crash. All because PS CS was choking on .GlobalPreferences.plist

Re: John

No, OS X does NOT allow you to do what menu master does. Just try assigning a key to a Safari menu item (like a bookmark), Most of the menus in safari have them disable. And for OS X's method you must type in the menu name. Which for CJK users may be *very* painful, time consuming, and prone to error.

Re: person that said ShapeShifter was slowing down the OS.

Technically, ShapeShifter can actually make UI element display faster. How? OS X in all of its "keep carbon and cocoa separate for the GUI" mentality is EXTREMELY slow when doing some theme operations. And I do mean EXTREMELY slow.. To combat this it caches almost everything. It helps to some degree, but not much.

here's my list of haxies
running on a 1ghz PB 1G ram
No problems at all running them all for a very long time now without a hitch. there are those few apps that I do add to the excluded list since they seen to have oddities mainly with metallifizer and I do mean oddball obscure apps that are either beta or rather poorly coded. but simply adding them to the excluded list takes care of that... I have never once had a kernel panic. yet I have had a kernel panic on a machine without a single haxie.

ClearDock
DesktopSweeper
FruitMenu
Metallifizer
Mighty Mouse
Paranoid Andriod
ShapeShifter
WindowShade X

PS I use adobe, macromedia office and a whole slew of other apps without a single issue so blame some other problem haxies are not hurting my work on my machine

All bow to John, he's obviously the most smart OS X user out there... he'll kill the GUI and make us all efficient.

Oh wait, I forgot. Macs ORIGINATED GUI-based tasks and environments.

Why not pull your head out of your ass and realize 90%+ of Mac OS X users aren't going to know how to use Terminal, much less shell scripts to automate processes. Yay for you, you're an uber-geek. Kiss off for the rest of the users, you obviously don't respect them or their opinions. Glad I'd never buy software from you.

Wow.

Isn't it the developer's job to continually improve their application? Wouldn't compatability with a widely-used haxie be an improvement?

If I bought a car and wanted to plug my iPod into the cigarette lighter, and it didn't fit, I would have a severe problem with it. Since the iPod would actually be siphoning power from something designed to heat up a coil and light a cigarette, the iPod would be unsupported by the car company.

By your - ALL OF YOUR - logic, the car company would have no responsibility to make a power port that would work. And they don't _have_ to. Nor do you have a responsibility to write more code that would provide compatability with any APE modules. But it would be an improvement, right? And it's your damn job to improve your software, right?

This conversation will never end, because all of you are too far up on your pedestal to accept that you _could_ _help_ to solve the problem. But it is much easier to say it's someone else's job and just sit on your ass, isn't it?

You've spent enough time on here arguing. Spend some of that time working on your software, and maybe this won't be such an issue.

"Haxies have risks. Period. They are a potential source of crashes in applications."

Just out of curiousity, just how much of a risk do I have using Haxies anyway? I don't think just having potential means it is a frequent cause of crash. I am sure that's what you meant. There is a potential for being run over by a car if you go out. There is a potential for being killed by a mugger if I go out to a local mall. But in reality that's just all fantacy.

I've always lived with 6~7 crashes a day ever since I installed OS X. The system itself has never gone down, but a wide variety of apps have gone down (Unexpectedly quit) so I figured they were all just buggy like that because OS X is still in its early stage of its lifespan.

Ah, let the flames begin....

I never said I hate GUIs. in fact, I've found a properly designed UI can be just as efficient as a command line for most tasks. Not all. I guarantee that on a slow connection, SSH is a hell of a lot faster than Timbuktu or ARD.

I also don't hate hacks. But please, don't tell me you cannot work without them. I like TypeIt4Me. But i can live without it. It saves me a bit of time when I'm doing stuff not in Word, since Word has this feature anyway. But it's kinda nice. If it caused me problems, it's gone.

The supercharge analogy is hilarious, when you consider that as you add things like blowers, nitrous units and the rest, the time you spend rebuilding your engine goes WAY up. High performance cars are quite maintenance intensive, whereas a stock Civic can go for decades without ever needing an engine rebuild.

I also am quite aware of the complexities of IPC and moving data between application spaces. However, using an apple event to transfer data between say, Photoshop and InDesign cannot be related to what a haxie does. Those channels are defined and maintaned by the application developer. They are aware of the ramifications of their use.

you cannot "upgrade" an application to be compatible with APE, because the number of things that APE modules can do to modify an application's behavior approaches infinity rather rapidly. How is Adobe or MS supposed to account for a near infinite number of ways that the UI, Open/Save, IPC behaviors of their applications MAY be modified without buying Unsanity so they can get access to the source? They can't.

You can't even begin to compare AppleScript or Actions to this.

The problem is, Unsanity's attitude is clearly "Unless you can prove it's a bug in our code, it's your fault" with your being the user or n number of Mac OS X application developers.

Roysna, your "APEs help track bugs" example is silly. how many users are going to get the source to a module and successfully recode it to track file system calls, then be able to successfully read that output?

Are you or Unsanity planning on releasing this modified module as a tech support tool?

As well, no, not all carbon and cocoa UI ops are separate. Menus and Printing are part of Carbon, regardless of what environment your application uses, at least according to Apple. If you have proof that that is incorrect, I welcome it.

Maybe if Unsanity stops trying to spin APE as being a hack framework, a debugging tool, and never at fault for any reason barring specific source code examples, then people would have fewer problems with it. They also really need to lose the "We don't provide tech docs because users can't possibly understand them " attitude.

Maybe that .plist corrpution wouldn't have happened in the first place if there weren't any haxies at all... Something to think about. ;-)

[Unsanity's attitude is clearly "Unless you can prove it's a bug in our code, it's your fault" with your being the user or n number of Mac OS X application developers.]

You keep saying that, but I haven't found that to be the case. Every bug I've ever sent Unsanity has been investigated and eventually isolated, regardless of where it ended up being (i.e. "whose fault"). As I posted earlier: As far as I can tell, the vast majority of Unsanity's development time is spent modifying their code so that their software works with the other applications that their customers have installed. That's kind of their whole business, in fact.

I'm not sure why you're so convinced that Unsanity is willing to do nothing but immediately blame another app, but that hasn't been my experience at all. Repeated claims to the contrary (without even anecdotal evidence) haven't convinced me otherwise.

Re: John

Modification isn't a bad thing. Those blowers for Civic, for example, are specifically designed to nicely mount on a stock engine. As a matter of fact I happen to have one of those on my Prelude, and it works well. Fast and Furious.

As I mentioned earlier, look how all those font utilities patch the system to do what they do: Activate fonts without using default Fonts folders. How is that different from APE working globally? I guess now you go out and start accusing Extensis of selling Suitcase because it patches the OS X font mechanism?

You say there is a near infinite number of ways that the UI, Open/Save, IPC behaviors of their applications MAY be modified. But you fail to mention that those are happening all within the APE thread inside each application. So there is nothing other developers need to account for, and it is their responsibility to account for other non-APE related bugs exposed by Haxies.

Haxies can expose other people's bugs because it uses the same API Apple's debugger uses. It's a good thing.

John...when I see a company that makes hacks saying "Well, application developers should make sure their applications run correctly with our hacks", that's an example.

When I see the fact that APE (Modules) mess with an application is unpredictable ways being promulgated as a good thing because it helps you to identify bugs, that's an example.

One of the problems is that things like APE artificially amplify a bug that no one might ever see in normal, (read, non-diddled) use to where a dev has to assign resources from a bug that IS affecting far more people, because the volume level is louder.

When I get told that giving people a list of default file locations for the APE install is "too hard" or "Too much work" and that "They wouldn't understand it anyway", that bespeaks of an utter arrogance that would be bad in a much larger company making mission - critical applications, and is astounding in a company of this size.

There's no decent technical documentation on APE, which, as someone running a network and doing user support is a very bad sign. (and I hammer Apple for this kind of crap too, although they at least are getting somewhat better...slowly.) APE diddles applications in what are, quite literally, unpredictable ways. Decent tech docs would help people in my line of work see what is going on, and let us make informed decisions. The single best defense against FUD is always the same. Real information. Long blog posts about how "We aren't doing anything wrong" or "If APE (Modules) crash your app, you probably had a bug anyway and should thank us" are not real info. Telling me that "Well, you couldn't understand this kind of stuff anyway" does nothing to counter FUD. In fact, it exacerbates it.

You would think that anyone watching what similar behavior by Apple is doing to them, and how it is causing them far more problems than it is solving would maybe realize that "Trust me" is NOT the way to go here.

I don't really care if I 'convince' you of anything or not. but so far, Unsanity's attitude has done nothing to 'convince' me that they are a company I want on any machine under my control. Most Mac network administrators share my opinion here. You'd think that Unsanity might want to do something about that.

john

John (Siracusa),

"As far as I can tell, the vast majority of Unsanity's development time is spent modifying their code so that their software works with the other applications that their customers have installed. That's kind of their whole business, in fact."

Don't you think that's indicative of a problem with their approach--if they have to spend the vast majority of their time making sure their software plays well with other applications? Or am I misunderstanding you?

[Haxies can expose other people's bugs because it uses the same API Apple's debugger uses. It's a good thing.]

Err. No.

Without getting into too much detail here (I'll save that for a future article), I would like to point out a few things:

John C. Welch - I am not entirely sure what you are asking us to do. "decent technical documentation"? What specifically would you like? There is an SDK for APE, this post, a fairly comprehensive Read Me, and our team. These sources amount to a fair chunk of available documentation. We will answer what we are asked and try to help where we can. You of course understand that providing the details of what each product does and how it does it is impossible. That is the result of a lot of hard work on our end and is our valued IP. But, we're completely willing to help within reason. Shoot me an email with whatever specifics you are curious about.

I think you're misunderstanding our attitude also. (possibly with good reason) But let me set the record straight. We do not try to shift the blame to others and claim APE or APE modules are perfect. They are not. They have, do, and will cause some problems. But, what we do want to refute is then tendency for people to see APE listed in a crashlog and immediately blame us. Whatever the reason for your belief of what we try to do, let me state that Unsanity as a group does not adhere to the attitudes and methods you've labeled us with.

Buzz (and others) - I think one thing that people sometimes miss is that we are unable to accomplish much of what we do without using the code injection techniques in APE. Is that grounds for discontinuing our work? Some may say yes, but we are not of that opinion. There is a cry for products and features we provide and we deliver in the best way we can. (and of course we'll always try to look for better ways)

Summary: We are doing the best we can to please everyone. But as I'm sure you all know, that is impossible. We are not trying to blame other developers and make them fit our requirements. Quite the opposite is generally what happens. Unsanity is not perfect, APE is not perfect, they're both a work in progress. :)

Having demands for a certain feature doesn't always mean it's the right thing to do. Many people want complexity while what people *really* need is simplicity. Democracy has never proven to always symbolize what people truly needs objectively speaking. What people think they need makes them cry for it, not necessarily what people *really* need.

So there is a point in keeping a certain level of limitation for the sake of a bigger picture.

[Don't you think that's indicative of a problem with their approach--if they have to spend the vast majority of their time making sure their software plays well with other applications? Or am I misunderstanding you?]

I think you're misunderstanding the products Unsanity sells :) The objective of most of them is to (successfully!) change a behavior across the entire system--every application that runs. Windowshade, for example, is intended to allow windowshade-style minimization on any window in any app.

Writing software like this is an exercise in working well with other apps. FontCard is another example, and is even more difficult to get working correctly, given the huge diversity of font handling in applications.

Imagine that FontCard 1.0 has been tested with a bunch of apps that handle fonts the "standard" way, and it is released. Then someone discovers that FontCard 1.0 doesn't work correctly with Quark Xpress. Does Unsanity say, "It's Quark's fault! They need to fix their app! We are revealing bugs in their app!" No, they figure out why it isn't working and release FontCard 1.1. Then FontCard 1.1 works in Quark, but maybe someone discovers that it doesn't work in the new Illustrator CS. Again, does Unsanity do nothing and blame Adobe? No! It tries to figure out what the problem is, changes its code, and releases FontCard 1.2.

And so on and so forth for each product they sell. This is simply the business they're in. It's in their best interest to track down these bugs and make sure their software works with the applications that their customer's use. A Haxie in isolation is pointless. It's whole purpose is to work well with every possible app.

[John C. Welch - I am not entirely sure what you are asking us to do. "decent technical documentation"? What specifically would you like? There is an SDK for APE, this post, a fairly comprehensive Read Me, and our team.]

This post is a defense. It's a "Just because we're all over your backtrace doesn't mean we had anything to do with it." It's basically technical PR. The SDK isn't easily available. I have to apply to get it. Sorry, but as someone who has to support stuff, i don't have time to ask permission to see relevant technical details.

Your "fairly comprehensive read me" is not. If it were, i wouldn't have had to spend 30- minutes with Find to figure out where you install files on MY SYSTEM. And, as IIRC, your justification for not including such things was "the users can't comprehend such things anyway" So no, there is no easily available tech docs. If the SDK is so easy, why not just post a link to it.

If you need NDAs of some sort, why not just make a fillable PDF that I can fill out on my Powerbook, digitally sign and email to you? Faxing is, for me, a trip into the mainframe room, which is the only fax machine in the building, or i have to edit the damned PDF. Furthermore, i don't want it for a product, so there's nothing in the SDK application that applies to me. I want to look at it so i can make an informed decision as to how APE works, since that is the only way I can get that info without the PR spin.

But there's nothing about a hack that makes the hoops I have to jump through worth it.

[These sources amount to a fair chunk of available documentation. We will answer what we are asked and try to help where we can. You of course understand that providing the details of what each product does and how it does it is impossible. That is the result of a lot of hard work on our end and is our valued IP. But, we're completely willing to help within reason. Shoot me an email with whatever specifics you are curious about.]

Oh please. Thousands of companies from Microsoft and IBM on down manage to create non-NDA'd technical documentation for support people and programmers without "losing IP". Gimme a break here. If you just don't want to talk to anyone who won't sign an NDA and isn't developing a module just say so, but don't give me the "we must protect our IP" dodge. There's too many companies that prove that tactic wrong every day.

[But, what we do want to refute is then tendency for people to see APE listed in a crashlog and immediately blame us. Whatever the reason for your belief of what we try to do, let me state that Unsanity as a group does not adhere to the attitudes and methods you've labeled us with.]

Well, I haven't see a lot of evidence. Even when people talk about how uninstalling APE (Modules) made the crashing stop, what i see is furious spin that "well, that doesn't mean it was APE's fault." You even tried to show how APE (Modules) are some kind of debugging tool in an example that no one outside of Unsanity or a module developer could have any chance of using. Again...drop the spin. The fact is, it's impossible for any ISV to predict what an APE Module is going to do to their application, because the options are nearly infinite, especially with multiple modules running. To imply that they should test for Haxi compatibility is nuts.

It's this spin-meistering that is causing you more problems than anything else.

"A Haxie in isolation is pointless. It's whole purpose is to work well with every possible app."

Then why did I keep getting this same old "Add to the Exclusion list" and "I can't replicate the problem here. Everything is working fine. It must be something with your system" excuses from Unsanity tech support when I had haxies?? Is that what you guys spend all day doing, making a bunch of excuses and blaming customers for their problems while making money making clever hacks? Must be nice.

JCW - I'm just going to correct a few points and move along. I get the feeling that you're not so much interested in whether or not we change for the better, rather it seems you've made up your mind that we're just here to "spin" the world for a loop. :(

APE SDK - it's always been available for public download. The only hoop you have to jump through is clicking on the "Download" link.

http://unsanity.com/haxies/ape/sdk/

You only need sign a license agreement if you intend to publish a product using it. Even then, a simple email explaining that a fax is not feasible for you and we'd handle it digitally. (we've done so several times)

As for documentation, we'll work on improving it. Rather we will improve it. There is no try, only do...something like that anyway.

I have used APE and other haxies for quite a while. Love em - I have had slight issues with the dock detox - but that was resloved with an update.

If you dont like it, don't use it. I am soo glad there is a choice - and that is what is important here.

[JCW - I'm just going to correct a few points and move along. I get the feeling that you're not so much interested in whether or not we change for the better, rather it seems you've made up your mind that we're just here to "spin" the world for a loop. :(]

I'm just going by what I see here and in emails. When I see evidence of change, i'll be quite happy.

[APE SDK - it's always been available for public download. The only hoop you have to jump through is clicking on the "Download" link.]

Gah...read the page, missed the link. Sorry 'bout dat. Maybe a second link at the bottom of the page?

[You only need sign a license agreement if you intend to publish a product using it. Even then, a simple email explaining that a fax is not feasible for you and we'd handle it digitally. (we've done so several times)]

Why not just do that by default and make faxing the option?

[As for documentation, we'll work on improving it. Rather we will improve it. There is no try, only do...something like that anyway.]

And why not just say that much earlier? It's amazing how that would have worked. Really.

APE is not bad. However it does get on my nerves when it causes problems and I have to work with it for hours trying to figure out what the problem is.

However, I think some of the people posting have turned the tides unfairly against Unsanity.

I still believe they should work hard to coexist with applications, however for some of you to slam them and say "Don't make your product," you are wrong. They can make whatever they want, as far as I care. And if it messes with my application, I will work my best to adjust if I know how. I just don't like them saying they have no blame. Brian has stated that that was not the point (as many of the poster's thought) so I don't see the point in fussing over it.

Let's see how Unsanity does now. I actually will keep watch on issues and such. It would be nice to see a status page on the unsanity site that has current problems and how they are coming along at fixing them.

Unsanity, the more communication between you and your customers and other developers the better.

I still don't use the android, I just disable the disks protocol, because the disk mounter is the problem, not safari. But it does do the job.

John Siricusa:

"I think you're misunderstanding the products Unsanity sells :) The objective of most of them is to (successfully!) change a behavior across the entire system--every application that runs."

No, I understand that, and that's exactly my point: Unsanity's products have the ability to influence the operation of nearly every other application on the system, and that's why many here who develop software are concerned.

My personal attitude toward this (my opinion and mine alone, of course) is pretty well explained in a post (http://www.scifihifi.com/weblog/mac/ZeldmanPanther.html) I made to my weblog about a month ago (and incidentally, I'm referring to a mach_inject app there, not an Unsanity haxie). Basically, my conclusion is twofold:

1. Becoming the kind of user who "mods" his OS is a lot like becoming the kind of user who mods his car: it demands more of an awareness about what you’re doing to the machine, a more active involvement in its maintenance, a certain tolerance for potential downtime, and an understanding that Honda (or Apple, or other developers, as it were) is not necessarily to be blamed if something goes wrong.

2. Haxie authors have a much greater obligation to ensure their users’ well-being than developers of conventional software.

As long as both haxie users and developers are on board with this, I think haxies can be harmless fun. The problem is, that's not always the case.

Wow, just stumbled on this thread. Finally I don't feel like I'm alone. Over the past couple of years I've been outspoken on my concerns around haxies and unsanity and it's good to see that it looks like some of them will be addressed.

However, I still find Unsanity's position on all of this unethical. I don't think APE or haxies should even exist. Then again, I think I should win the lottery and I guess that's not going to happen either eh?

I don't have a problem with Unsanity or haxies.

But reading the APE SDK, outside of needing root access, there's effectively no limits on what a module can do to your applications or system. It can pretty much patch any and ever call it can get access to.

To quote Stan Lee and Steve Ditko, "WIth great power comes great responsibility." It is APE and it's SDK that gives the power to modify applications without needing any access to the other application's code, using uncommon and non-standard methods in a way that the application coder cannot allow for. (How anticipate ANYTHING and EVERYTHING?)

Since Unsanity has chosen to do this, and they have that right, then they have the responsibility to go further in preventing problems. It's simply not good karma to sit there and say that other application developers should allow for this, especially since it's impossible for them to do so. If an application simply cannot handle being diddled by APE, then APE needs to be modified to automatically exclude that version of that application. It's unfair, but so is life.

john

This is an excellent posting which I think all developers can take and learn something from. Congrats =)

I've been using Unsanity products since OS X 10.2 and I've never had a single problem that I know of. Massive kudos to rosyna for being so thorough and teaching us all some very useful information.

I believe people who would heft extra responsibility onto haxie developers are misguided. It seems perfectly clear to me that responsibility falls on individual computer users, and users who are ignorant enough to damage their system by continuing to use a haxie that doesn't work on their system properly will have problems no matter what haxie or system mod they apply. It's like having a label on a hair dryer telling you not to microwave it. If you're dumb enough to microwave a hair dryer, then they can forget the label because you're going to be microwaving something dumb either way. So as long as a reasonable amount of information is provided on the site about what a haxie is and does, I think the responsibility for it's use is on the end user. If an enormous amount of people have too much of a problem using the products having been given the information about them, THEN we can point the finger at the APE mods. Which probably wouldn't matter at that point anyway since Unsanity wouldn't be able to make money and would have to stop. So far, I've not seen such a body of disgruntled users and Unsanity has been straightforward with the bugs in their mods and addresses them in the updates.

I'm not saying only idiots will have problems, I'm saying people who apply a system mod having no knowledge of how it works shouldn't complain about a mod that has no guarantee of working in every situation. At the most, they should get their money back if a reasonable person in their situation could've expected better results.

If nothing else this thread -- in the form of "A fan" -- has reaffirmed my belief that wallowing in the OS 9 past was adversely affecting my work. I, too, recall thinking "hey a few crashes per day isn't a big deal if the system stays up." Compared to OS 9 this is indeed a luxury.

But then I had to reinstall my system because I'd accidentally deleted a crucial OS X system file while booted into OS 9. I decided then and there that it was high time I learned to use OS X as it is and I haven't looked back since. No more crashes, no more instability, no more lost work (or having to save every few minutes "just in case").

This is the true beauty of OS X for me. It looks slick, it runs slick, it is extremely low maintenance. Unless you invite in haxies it is indeed a dream OS for people who need and require 99.9% uptime and zero lost work due to application crashes. Panther drops into the backround and all there is is me and my work. That's how I like it.

I don't wish to sound overly hostile, but what kind of work could you possibly be doing that allows you to blithely ignore the certainty of 6-7 crashes EVERY day?

And your Finder crashes? I have literally never had my Finder crash, nor does it run slow. Nor does Photoshop or Dreamweaver crash, or any of my other apps. If I sound a bit credulous here please forgive me. It's patently obvious to anyone who runs a "clean" system that the root of your problems is not OS X.

It just is not the normal state of the Finder or the various applications you've listed. Why it is you put up with it, I don't know. Whether you wish to address the issue or continue to ignore it is entirely up to.

Also, I have no axe to grind with Unsanity. I'm glad their haxies work for some people and this is the first and last post I'll ever make relating to their products. I wish them all the best. Just not on my computer. ; )