Glorified Typist

Rich, I respect your position, but as a user I think you’re on the wrong side of this (ugly) debate.

I don’t see how DB’s statement is incorrect. If there’s a bug in BBEdit that’s triggered ten times as often when a haxie is installed, it’s still a bug, and it would still never get fixed until it manifested itself in some other way. (If it’s the haxie’s bug, sure, it’s Unsanity’s problem all the way. But let’s assume that it isn’t. There’s a bug in your code that’s causing a customer grief.)

Sure, it saves your support staff some time because they never have to hear from that customer. And maybe he’ll contact Unsanity, and they’ll hard-code a workaround to your bug in their product. I’ll even agree that until the bug no longer exists in your program, it’s their responsibility to do so. But that’s not really the point. The real problem is that the whole situation is pretty hostile to the user.

You write that “the first thing we’re going to ask you to do is to make sure that the problem still occurs after uninstalling all of your third-party system extensions.” Well, you shouldn’t have to do this, since you presumably detected the extension and told the user to not bother calling you until they had removed it, but let’s say the user had the gall to call you anyway.

Maybe telling them again shouldn’t be the first thing you do. Maybe it should be the second thing you do, after trying to verify the bug. And then, if uninstalling some extension solves the problem, maybe you should write back, “We can’t reproduce the bug here, and we think the problem may be with Extension X. We’re going to follow up with X software and get back to you with more information.” Do whatever you want behind the scenes, but do something other than leave that user on his own. Seems to me that that would be the best way to help your mutual customers.

When that dialog of yours stops a user cold, or when “the first thing” you do does the same thing, you haven’t really done him much of a service at all. You’ve given him a quick primer on dealing with interactions between software and sent him on his way. You certainly haven’t enabled him to “get back to work” any faster. All you’ve done is told him, in no uncertain terms, that it’s simply not your problem. Instead of “getting back to work,” he’s sitting there with two pieces of software that he likes, but that won’t work together.

Maybe I’ve misunderstood your position, and I hope I have, but honestly, it just comes across as, well, mean.

Bravo Rich.

I have nothing against APE but in my day job (running a Mac Service Provider) and in my evening job (running free support forums for my Mac User Group), APE is implicated in application and system crashes. Some of the Unsanity guys have hotly denied this but the facts remain.

We ASK that the end users stop using APE-based products for the period of diagnosis of the ACTUAL problem.

This isn't Rich being mean or uncharitable, this is an attempt to find the problem and NOT just apportion blame in one direction or another.

I've had this argument before with a friend who believes that because *I* do not use Haxies, I don't "approve" of them. I don't use them because I need to have a default system. I install the apps I need and it's vital to my diagnostic process that I can say - my system is almost vanilla...and see whether I can replicate it.

Rich didn't say it wasn't his problem at all. He's simply asking for responsible procedures for the diagnosis of a bug.

I have to say that I have always found that particular BBEdit dialog to be distasteful. As a customer it feels like Bare Bones is accusing me of doing something wrong. (Also annoying is that there's no way to shut off that warning, which comes whenever BBEdit quits unexpectedly, even if there's been a system crash elsewhere.)

Even though I understand the reasons for having that dialog, I think it sends the wrong message to users: that Bare Bones would rather not be bothered with calls for help unless you've verified that the bug isn't your fault for installing a haxie. And even if your haxies are causing BBEdit to crash, don't come crying to us, because it's the fault of Haxie developers and they should fix it.

I'm not saying that all of that isn't true -- I'm saying that customers don't want to be talked to that way, especially by cold, unfeeling dialog boxes that can't get across the humanity and warmth that Rich has in person. :-)

Speaking as the engineer to whom Cocoa developer support incidents were assigned for over a year, I think that what BBEdit does is about as much as any app should do to deal with the instability that APE causes. In fact, I would probably recommend that an app do a start-up integrity check, and immediately exit if APE is found.

Let me be as clear on this as I possibly can be: altering the behavior of sytem frameworks the way that APE does is not supported. It never was supported, and if I know the Cocoa frameworks team (which I do), it never will be supported by Apple.

If an app works without APE, and crashes with APE, then it's APE's fault, QED. If you like UI abortions like windowshade, then use them if you must, but realize that you do so at your own risk. Don't even waste your time submitting a bug report to Apple or anybody other than Unsanity, if you haven't confirmed that the bug persists when APE is removed.

-jcr

Being a developer and user myself, I understand completely BareBones' position on this matter. If you haven't dealt with user support while trying to make a living on your software, you have no idea how much time can be spent on finding a bug that isn't in your code. And this time will not be spent on fixing real bugs or better yet, adding features.

Then again, some developers dismiss a problem too easily when you say you have APE installed.

But, if you value your purchased software (you have, haven't you?): taking some of your time to reproduce the problem without APE is money well spent. Unless you're willing to pay a lot more money for support...

Annard

Now we're back to the olden days of System 7, Conflict Catcher, misbehaving system extensions, and rebooting with the shift key down to stop all 3rd party extensions from loading.

This is exactly what MacOS X was intended to eliminate, and why APE is such a bad idea.

"This is exactly what MacOS X was intended to eliminate, and why APE is such a bad idea."

How else can one reasonably modify the OS behavior to match the user's desires, then? I run APE for one reason alone: to run Classic Window Management, because damn it all, when I click on the desktop then all the Finder windows should pop to the foreground. When I click on a BBEdit window, all BBEdit windows should come to the foreground. You know, the way they did in Classic but don't in OS X.

So I run APE to get that behavior. How else could/would/should I enable it, if not through APE?

(And please, nobody bother with the "you shouldn't want that behavior in the first place" trope. I'll refrain from pointing out the idiocy of other people's desires if they forgo pointing out the idiocy of mine.)

DragThing can enforce that all-windows-to-the-front business when you switch applications (regardless of whether you switch using DragThing). All hail DragThing.

I've read that ASM (vercruesse.de) does the same thing, but I don't use it and I don't know if it uses APE.

Bravo on explaining the situation, Rich. I agree that it must be a nightmare to have to deal with an influx of queries/reports/irate customers that are all asking you to fix things that aren't part of your codebase.

However, this issue I've always had with BBEdit's "force quit" detector is that it reminds me too much of the old "You failed to shutdown Windows properly, you bad user!" message in its wording - specifically, it doesn't seem to check if it was "force quit" by the user, or if it just died.

There are lots of reasons for force-quitting an app. I'll admit I've moved from using BBEdit as my primary editor to another app, but I still use BBEdit for heavy lifting in search and replace, among other things.

However, a whole load of my files still have BBEdit associations, and if I double click on them BBEdit will start up, which isn't what I want. I'll often find myself force quitting BBEdit before it starts, and promptly forgetting I've done so. When I kick BBEdit into use a couple of days later for whatever reason, I get the "APE bitchslap" dialogue, which seriously needs rewording.

I'm not a developer of offline apps, so I'm not even sure if this is possible, but would a better place for this dialogue not be at the point where OS X says "Application so-and-so has unexpectedly quit"?

As I said, I agree with your position, but I also thing that your way of dealing with it from a user's point of view is too heavy handed. There must be a way of conveying that third party extensions are bad without this sort of 'every time' mentality.

Maybe a dialogue the first time a user starts up after APE is installed saying "This isn't supported, and if you have any issues with BBEdit, we recommend that you uninstall APE before contacting tech support"?

I agree with Rich's point and don't see or feel any negative tones in his article here. The dialog has a similar shortcoming to emails: since you can't see the person's face or hear their tone of voice, misunderstanding is easy. The writer of the dialog had no negative intensions when (s)he wrote it, so was completely unaware of how it might be taken. I don't think it is heavy-handed, just that it could be misinerpretted by the reader.

Perhaps it could be rewritten to avoid all this.
"To aid in troubleshooting, before contacting for assistance please eliminate the potential role of third party software in this issue by removing all third-party system additions and trying to repeat the issue"

Eric said:

How else can one reasonably modify the OS behavior to match the user's desires, then? I run APE for one reason alone: to run Classic Window Management, because damn it all, when I click on the desktop then all the Finder windows should pop to the foreground.

(And please, nobody bother with the "you shouldn't want that behavior in the first place" trope. I'll refrain from pointing out the idiocy of other people's desires if they forgo pointing out the idiocy of mine.)

So do the ends justify the means? "I want it" is totally reasonable, "I'm going to hack my system in unsupported ways and then expect support" is not. If someone screws with a page with greasemonkey and they break the layout, is that your problem?

Eric Meyer: The basic functionality of Classic Window Manager is three lines of code, no APE required. I'd be glad to send you sample source code.

I think the message might benefit from slight rewording to imply that it might or might not be Unsanity's fault.

Something akin to (heck, I'm just goofin' around here):

This application just crashed or was force quit.

This application just crashed or was force quit. Unsanity's Application Enhancer is currently installed on your system, and may have caused the crash, as it operates by running its own code inside of [product name] and other applications. We would be happy to assist you in attempting to determine the cause of your crash, but we need you to, as a first step, see if you can reproduce the problem after removing all preference panes and applications using the Application Enhancer framework. (Refer to these programs' respective websites for uninstallation instructions.) If you are still able to reproduce the problem after these uninstallations, please then contact us at .

To me, this seems more user-friendly. It conveys openness to the possibility that the error is not a haxie-related problem (which the original language does not), yet, importantly, it still indicates that the uninstallation of haxies is a required first step before Bare Bones will offer technical suport.

If you are installing hack tools, (and that's what APE is, a hack tool), then you are hacking your system. Period. If you are going to hack your system, then you now bear the "first responder" role for when that hack turns out badly, or when things act weird.

Not Bare Bones, not Apple. You, the hacker, it's now your job.

APE doesn't introduce a well-defined number of clearly documented behavior modifications along specific vectors.

APE introduces a near-infinite range of possible modifications to an application space, yet they continually expect that application developers will be able to account for this.

This is just ridiculous.

It's not just application developers that get hit with this. It's also IT support people. Trust me, it sucks just as bad for us too.

Both "sides" have good points.

As a user, I have seval haxies installed because, frankly, they make my day to day use of my computer much more efficient and enjoyable. For me, the user, WindowShade behavior is BETTER then having windows minimized to the dock. Having a hierarchical and customizeable Apple menu is BETTER then Apple's lame OS X default Apple menu.

But, as someone who does software QA for a living, I am also quite aware that Haxies introduce an unaccounted for variable and Bare Bones' dialog is an acceptable way to handle the situation and try to eliminate a variable for their customers and support people. There's nothing wrong with asking users to turn off "add-ons" like APE when troubleshooting.

To summarize, it is OK to run Haxies if they improve your Mac experience, and it is also OK for support and engineering to insist that any bugs be reproduced with the Haxies turned off, as a standard troubleshooting step.

Fair?

It would seem clever for a company, to make sure that the program doesn't crash with the most popular haxies. As there are going to be more happy customers and more revenue. Of course programmers just can't deal with this concept, because it means they have to do more work.

sounds like why i use OSX and not linux. they are called 'haxies' for a reason. sure they can deliver a desired result, but they can also do naughty stuff with your OS.

as for the 'do more work' part, since obviously only someone who is an active participant in coding not only closed source but open source programs, i am sure everyone will take your comment with a full and open heart. [/sarcasm]

I've installed and uninstalled APE a few times over 10.1, 10.2 and 10.3. My computer works when APE is not installed. My computer doesn't work when APE is installed. Since I've boycotted all APE products, I have not had a major (production stopping) bug. Normally I have twelve to twenty-five applications open at the same time (office and web development).

APE is the bane of the Mac world and Rich is quite right not to support it.

It's a pity that so many developers bought into the APE hype (one ring to rule them all) and have crippled their applications.

If you are going to tinker with low-level stuff, much better to go in with kid gloves and change the minimum than the APE approach of taking the entire low level calls hostage.

For Eric - there is a lovely control tab switcher with some nice additional functions called LiteSwitch X from Proteron which gives you lots of options on Window layering when switching applications.I bought a 3 seat license and have a free seat available. Email me Eric if you'd like my last seat - it's the least I could do for the wonderful tutorials you have offered us.

In terms of enhancing the OS 9 under OS X experience, I heartily recommend XMenu from Devon Technology. It's free. The finder menu is back.

I've been using Macintosh computers since I got my first Plus in 1988 (I've never used any other computer, so telling me that OS X is better than Windoze so I shouldn't complain doesn't go anywhere for me). Since 1994 I've made my living doing Mac support, have set up, dismantled, repaired hundreds of Macs, from System 6 through OS X 10.4.x.

I waited to move to OS X until 10.2 came out, and then until Unsanity's FruitMenu appeared, so I could bring along the Apple menu I'd constructed, fine-tuned and relied on for nearly a decade (since it became configurable in System 7) -- and for which the Dock is nowhere near a sufficient substitute. So I've had APE in my System since my first OS X install, and currently use it for FruitMenu, ClearDock (the default Dock is ugly to my eye), FontCard (the Type palette is lame), MenuMaster (since I can no longer use ResEdit to make menu mods), WindowShade (well, I haven't explored it yet, it was on sale), ICeCoffEE (just installed, mostly because it moves Services to to the contextual menu, much more convenient), and FullScreenSafari (a haxie which appeared shortly after Safari first came out, has since disappeared, but which I'd hate to live without -- it makes new Safari windows stack instead of "cascade" -- i.e. scatter at random all over the screen).

As it happens, I've experienced very few System or application crashes. So far as I can tell, neither APE nor its children have caused any problems in four years of heavy use. I have had problems, but testing by removing APE and other haxies (or rebooting in the clean second user -- I install all haxies at the user level only) has never solved them. So while I will agree that Bare Bones is perfectly within its "rights" to post this message -- though they might give some thought to whether being within your rights is the same as maintaining friendly relations with your customers -- I tend to be skeptical of those whose first response to any mentioned problem is "You must be running APE, you sniveling idiot. Get rid of it and all your problems will be solved."

Sure, I could live without any of these haxies -- but then, I could, if necessary, live without OS X, or the Macintosh, or any computer at all (as I did for over 40 years). The people who tell me to love it or leave it miss the point (not to mention reminding me of those who told me the same when I objected to being conscripted for The War in the 60s). The point of the Mac from the beginning was that it was to be a pleasure for non-geeks to use -- remember "the rest of us"?

I don't consider System hacks to be ideal solutions; I'd much rather run a "clean" System. I use "haxies" only to provide functionality that Apple refuses to give me. Any of the mods for which I use APE modules -- or the other non-APE hacks I've installed -- could be made available by Apple within OS X out of the box. Many of them are choices and ways of working that were available in the classic Mac OS, and that millions of us had become accustomed to and relied on for years -- until Apple took them away from us, without so much as a "by your leave." The original OS X wasn't even going to have an Apple menu at all -- and, as I recall, the "Finder" was going to be all column-view -- until a storm of complaint forced Apple to make OS X at least somewhat similar to what it was replacing.

The real question is why is Apple so hostile to its own user base? Anyone who comes to love the Macintosh must do so in spite of Apple's consistently contemptuous treatment. This really is a mystery to me. I can't see how a friendly, open, helpful relationship with Mac users could really require so much more energy than the "no comment," "take what we give you and shut up" firewall Apple presently maintains.

One reason has occured to me: It's become plain that the folks now designing and building the Mac, from Steve down, actually never used it much (or at all) before OS X (I recently read that Steve pointedly installed a NeXTStation in his office when he returned to Apple). They don't know what we long-time Mac users are complaining about, because they literally don't have our experience with the Mac. That lack, combined with the adolescent know-it-all arrogance that seems so sadly prevalent in the computer world, has led to a really odd situation. I love the Mac, in many respects I love OS X, but sometimes it drives me nuts. Five years now, and something as simple as the green button in Finder windows still doesn't work right (as it did in the classic Mac OS since it was introduced -- in System 7 I believe). Why not? If somebody writes a haxie to fix that, I'll install it.

Just as a minor note, I've seen this message from BBEdit several times, and every time it's because something else made the system crash. Memory problems on my G5, a battery problem on the PowerBook, some other application freezing. And, yes, it's a little grating to have BBEdit chirp up with, "I didn't exit properly last time and you have APE installed on your system!" Regardless of how well-founded your worries of APE may be, this is... well, kind of patronizing.

I suppose I'm just tossing a question up into the air: is there a solution which doesn't involve a startup message warning me, in effect, that Unsanity products may have broken my notebook's battery latch?

is there a solution which doesn't involve a startup message warning me, in effect, that Unsanity products may have broken my notebook's battery latch?

The standard solution to this sort of thing is to have a checkbox in that dialog with text like "Don't show me this again".

Just to add another one to the list for Eric Meyer, Peter Li's X-Assist is an app that brings back pre-Mac OS X windowing behavior (and/or lets you toggle between the two when the other is useful) and adds back the old application menu.

I'd prefer to run a hack-less system, but there are certain apps and hidden setting tweaks that make Mac OS X more useable for me. I try to find the ones that seem to work in the most un-obtrusive ways, but I recognize that some day they may break or be untenable, and I've discontinued use of several for that reason. As a member of the support team for a small but moderately-popular Mac open source project, I've seen all sorts of wierd and random crashes that only occur when haxies are installed, and I respect any developer's right to ask a user to remove any hacks and reproduce the bug hack-free first, at the very least.

In a perfect world, Apple would provide a few more "classic options" or even a supported and safe framework for extending things, and all app developers would have the resources to be able to test all sorts of haxie interactions, but this is not a perfect world and I'm sure the vast majority of Mac developers don't have such resources available to them. Bug and support triage is a fact of life, as disappointing and cruel to the users as that may be....

I think it's interesting that, Rich, you don't address at all drunkenbatman's point. In his case, a bug wasn't reproducable without a haxie installed, but the bug was with the application's code, not the haxie.

Whenever I get that message, I just consider it an annoyance and move on. BBEdit has tons of UI annoyances. I'm not going to stop everything I'm doing, uninstall all my haxies and then go and try to reproduce the problem. I value my time a bit too much to go to the trouble. And to be honest, 99% of the time it's because something else went wonky, like my battery drained, or a kernel panic or whatever, like Watts said.... I'm pretty sure the haxie didn't make me forget to bring my power adapter.

Eventually, I'll might move to a non-BareBones application that doesn't annoy me as much. Time will tell.

I think it's interesting that, Rich, you don't address at all drunkenbatman's point.

I can't speak to Michael Bell's experiences with other developers' products. I do know that he never claimed to have experienced any bugs in our products. I also know that we've never had a bug reported that was caused or exacerbated by the presence of APE or haxies that turned out to be a bug in our code.

>I also know that we've never had a bug reported that was caused or exacerbated
>by the presence of APE or haxies that turned out to be a bug in our code.

And this is a key reason why DB is mostly wrong in my opinion. He is giving out the impression that many bugs from APE and haxies are actually in the application's code rather than in the haxie. That just doesn't ring true especially on an application as venerable as BBEdit for example. It just doesn't seem likely that anything other than a small percentage of problems caused via APE will have anything to do with bugs in the application. To imply otherwise is just disingenuous.

Rich,

I also know that we've never had a bug reported that was caused or exacerbated by the presence of APE or haxies that turned out to be a bug in our code.

With utmost of respect, Rich, I'm not entirely sure you're correct on that one.

8/18/04 ...

Me: "If I understand the terminology you were using correctly, are you saying you believe that Mailsmith is attempting to run these scripts at the same time that it is attempting to run a filter action script, and both scripts attempting to run at the same time is causing a crash?"

You: "According to the OSA engineers with whom I've discussed the subject, OSA in 10.3 is preemptive-thread-safe, but the standard additions are not."

Rosyna's response: "Actually, you know what...It appears AppleScript isn't thread safe *at all*."

2.1.3 release notes: "Mailsmith now serializes script execution, so that only one script can be running at a time, regardless of how it was invoked (e.g. Script menu, filter action, notification script, or other). This should prevent crashes resulting from AppleScript's shortfall in this respect."

Wasn't this such a case?

Mike

Mike,

You probably don't recall the resolution of this problem, which is summarized here. To sum up, AppleScript is thread-safe, but not re-entrant. That wasn't specifically a bug in Mailsmith, however.

And even if your haxies are causing BBEdit to crash, don't come crying to us, because it's the fault of Haxie developers and they should fix it.

Excuse me? If the Haxies are causing the problem then it is certainly not BBSW's responsibility to fix it. I would prefer they spend time improving their product so I can throw cash at them than wasing resources fixing someone else's problems.

APE is bad. End of story. Whether it works or not, it is BAD. It is bad for the OS, it is bad for any apps you run, it is a bad idea.

So I come to this thread as a researcher and someone who recently had an uninstall of APE (presumably) fix a serious system instability issue.

I'm wondering: is there something (guidelines, added features, hooks, QA testing, etc.) that companies such as Unsanity that market deep-level hacks could do to help to alleviate this?

Lewis, you took my comments completely out of context. I'm not making the case that Haxies are good or that it's Bare Bones' responsibility to fix it. I'm saying that the dialog box that appears is not the right tone to take, especially with paying customers. It's far more accusatory than I think it should be.

This isn't about crashes being the fault of Haxies. This is about having good customer service, which means sometimes treating your customers with better service than they perhaps deserve. That means softening the text in the dialog box (at least of non-free products!) and not publicly coming across as shrugging and saying, "Hey, it's not my problem that you're running software other than mine." That attitude got Ben Parker killed. ;-)