Of unintended interactions
The other day Jason posted a sample of some of the stuff he's been working on behind the scenes to extend ShapeShifter's reach, or rather what a themer can do via ShapeShifter. There are a few things in the coming tech I really want to see in some themes, because it is becoming harder and harder to use an OS without borders on its windows...
Unfortunately, that functionality is a bit out in the future, and mostly I mention it because it brought to mind one of the more amusing things that happened at EAA after the talk at the bar. There was Wi-Fi, and people were setting up laptops and such and showing different things, and Jason was showing some people some of the test-bed stuff, and at some point he had Microsoft Office fired up all enlarged and green and such.
As it turned out, there was a guy from the Microsoft Mac Business Unit who'd flown in, and after buying me several drinks and a shot, or perhaps that was after, wandered over and saw his toolbars being violated, and started freaking out: "Dude, you can't... that's going to break x... OMG you can't do that..." I'm told watching him tweak made Jason's night, and was glad to get the following a day or two later...
hey db, this is **** from mbu,well - i hope you had a good time last night, it was definitely good to meet all of you guys. it'd be great to do this again sometime, but i'll let you recover for a minute before pushing that idea to hard.
also, uh, that girl from the taco shop, not cute. no more democratic surveys on hotness from a bunch of drunken technofiles... after you left i took another look at her, and i think an organ nearly gave out. i'm not even sure if she was a she at that point, and she had a serious limp... anyway, sorry i didnt just give you guys a lift back to the hotel, cause i left right after you guys did (yes, alone)... i hope you made it there alright.
so.... keep in touch man, its always good to meet cool people with common interests. take care, and thanks for getting this whole thing together.
-****
While I don't remember a lot about that part of the evening, I remember us bailing out of the taco shop -- and him saying he was staying -- and us trying to warn him of the horror he'd be faced with the next morning. Minus a picture, let's just say I'm glad he went home with the above story, as opposed to the memory he could have had.
He actually was a really cool guy -- considering some of the questions I saw people throwing at him when they found out he was at the Mac BU, an aptitude for patience must be required on the psychological profile.
I could just see his body language change when he was interacting with someone expecting him to be a representative of all things Microsoft-on-Mac, and I was reminded again of what a weird dichotomy these guys often have to deal with when it comes to the Mac base. They're generally at the Mac BU because they love the platform and work their asses off, yet Mac users have a habit of glorifying their products with one hand when its a convenient point against another platform, while viciously resenting the platforms dependence upon them with the other.
Rather than politely informing the umpteenth person that the Mac BU isn't responsible for the Mac version of Windows Media Player, I'd probably have gotten snarky. I was so impressed, I wonder if they're given a crash course on what to do if cornered by an angry Mac user.
Awhile back, in Of GyazMail and Sway, I mentioned that something in 10.4 seemed to be exacerbating some speed issues in GyazMail. This was my bad, and I need to own up to it -- I thought I'd tested it on a stock install but apparently I was wrong, as I found out while looking into something else near before Evening at Adler. Some interaction with ShapeShifter was causing certain views to have a massive slowdown, which didn't make sense, as ShapeShifter shouldn't be doing that.
For the most part, ShapeShifter just swaps graphics with no slowdown (sometimes feels faster), however if something is a custom view (like the labels field in the Finders contextual menu) there can be a miniscule hit -- as in imperceptible unless you counting milliseconds while profiling. It just shouldn't have been happening, so it was weird, so I was curious.
I contacted the author, which didn't go well at first once he heard APE was involved, but a few samples later and a bug was found in the date formatting code. This bug wasn't a huge deal on its own, but ShapeShifter was exacerbating it to the point where it was extremely noticeable. The author passed on version 1.3.3b5, which fixed the issue, and I'm going to assume that version 1.3.3 which is online now has the fix in for it.
Lessons:
- My memory is fallible, although like some of the below this is something I learned long ago.
- Many devs, when they hear APE is involved, have a tendency to shut down because they consider it something interacting with their software that's out of their control. This is exacerbated by many devs not spending much time in looking into APE and such.
I.E., the first email back was "Sorry, nothing I can do, APE affects Cocoa below my program.", but it's worth not giving up on, unless the company is an extreme example like BareBones (who throws up an alert saying they see APE is installed, and to uninstall it before calling support), which I always thought was exceedingly lame for just this reason. Basically, if this had been a BareBones product, they'd probably still have that bug in there. There's an implied arrogance behind that error message I can't get behind.
- If someone had asked me whether or not ShapeShifter was causing this, and I'd have been forced to guess, I would drawn on what I knew ShapeShifter does, and I would have guessed wrong.
Software interactions are a bitch, and the improbable should be checked, because it's still possible.
- I keep forgetting what a barrier language can be, especially when you're like me, and known to make up words.
- The ability for a user to be able to take a sample of a program instead of just saying "It went wonky doing this" or "It seems slow doing this" is extremely helpful to devs, and something more users should probably be aware of. In this case, if I hadn't been able to send off samples of it running with and without ShapeShifter, it probably would have been a taller task to get listened to.
In the interest of fairness:
- There was a bug in Panther which made the situation quite a bit different when it came to anything using APE or mach_inject, and it caused some serious headaches. Basically, crash reports and samples and such had their symbols stripped, because the kernel wasn't going far enough down the tree, IIRC. This made debugging a crash report much harder than it would otherwise be, and really annoyed a lot of devs. Luckily, this was reported quite a bit to Apple, and was finally fixed in Tiger.
- Developers don't like debugging other's code, and are often going to be sensitive when it comes to dealing with other's software and how it may be interacting with their own. Many devs go in with the assumption that the other guy's stuff is screwing up theirs, because it often is, just not intentionally.
To give you an idea, there's a company known for putting out camera drivers for the Mac that have a habit of assuming they're the only thing running, and unintentionally break other's software -- and they're then forced to debug wtf the other guys are doing, then tell them and hope it gets fixed, but since it's on the CD that comes with the camera and most people will never update, they really just have to figure out a workaround.
Dealing with interactions can get tiring after awhile, but the best devs seem to just want their software to work as well as possible, and it's sorta their job and why you're paying them for their software -- and I'm glad the author of GyazMail fell into that camp.
Posted by drunkenbatmanNovember 18, 2005, at 05:11 AM
Comments (46)
Posted by: jacob at November 18, 2005 06:02 AM
"because it is becoming harder and harder to use an OS without borders on its windows..."
What does this even mean? Do you prefer the windowing behaviour of linux or windows, and why? I find that OS X makes having multiple windows nicer than any of the alternatives, and the lack of borders doesn't really bother me.
Posted by: drunkenbatman at November 18, 2005 06:14 AM
What does this even mean? Do you prefer the windowing behaviour of linux or windows, and why? I find that OS X makes having multiple windows nicer than any of the alternatives, and the lack of borders doesn't really bother me.
It means exactly what it says, I can't see a way to make it clearer, as its something I've talked about before. There are no borders on OS X windows, just shadows, which often sucks for different types of content.
Posted by: Tobias at November 18, 2005 06:31 AM
@jacob let's take two TextEdit windows full of...text, and have them overlap. Now try to read the front one: on the left side of the window your eyes will jump to the one behind it, as there are just a few pixels between the two texts. On the right side you have a visual border (scrollbar) to prevent that.
Posted by: squirm at November 18, 2005 07:00 AM
This post is titled 'on unintended interactions'. What makes an interaction intended or unintended? Simple: applications do not do everything that is technically possible (e.g., use Apple-private API), rather they adhere to a contract. That contract is in the documented behavior of the operating system.
Haxies exist to break those contracts. Since they're the ones doing the hacking, it's the hack author's responsibility to make sure that they don't break anything. Even if they're just exposing a 'bug' in someone else's stuff that is only revealed by the presence of the haxie, _that's_still_the_haxie_author's_fault_.
I don't want to put words in his mouth, but I doubt Jason would disagree. This is the kind of extra responsibility you sign up for when you author a hack. A developer dismissing a crash report because unsanity is in the log is unreasonable - all that means is that APE is installed. But passing the buck to a haxie author because a crash can ONLY can occur in its presence is just sensible.
And a user who installs a hack also needs to understand what's going on - go ahead and do whatever you want to your machine, but it's no one's fault but your own if stuff doesn't work as well as it used to. You cannot expect people to support you when what you're doing is.. unsupported.
So BBEdit's response seems perfectly reasonable, and I doubt it has anything to do with arrogance. Think of Brent's support burden. Now think of Brent's support burden if he was willing to debug anything that happened to inject itself into his address space. They're not asking you not to use APE, they just want to make sure that any problem you have is reproducible without APE installed.
Posted by: Rosyna at November 18, 2005 07:45 AM
squirm, indeed all bugs in an applications are the haxie's authors fault. Even if no haxie is installed, it's still their damn fault. Those haxie authoring bastards, making your computer crash with their MINDS!
Posted by: Isaac Grant at November 18, 2005 09:42 AM
Aaron, it is indeed a dialog that BBEdit throws up when it relaunches after a crash, and you have any haxie's installed. But I have to agree with squirm - its not an unreasonable thing to say - basically, disable your haxies and see if its still broken before blaming us for the crash - it's something you should probably do as a good user anyone (see db point about programmers debugging others code).
Posted by: Isaac Grant at November 18, 2005 09:48 AM
Rosyna,
Can't speak for squirm, but I'm certainly not blaming the haxies outright - but it just makes sense to test the system without them running. Sure they may not be doing much, and shouldn't cause most crashes.
I realize you're a unsanity developer, and while your stuff is not my cup of tea, I acknowledge its some pretty cool shit, and does not cause the mass instabilities that some developers claim.
But I don't think that lessens the legitimacy of testing with and without.
Posted by: robert at November 18, 2005 11:03 AM
If you flash your ECM on your car so that it goes to "eleven" and you fry the transmission is that the fault of the car manufacturer? According to haxie logic, it is, simply because it exposed a "weakness" in the transmission.
Uh, no. It was never designed to do that. That is the difference. That's why its a hack and that's why developers get pissed.
Posted by: oliver at November 18, 2005 11:48 AM
I have to disagree when you say that for the most part Shapeshifter doesn't cause any slowdowns. On my powerbook (867mhz - not the fastest, but no slouch either) opening Safari from RAM with no other processes running takes no more than 1 bounce of the dock icon. If i turn SS on i find it takes closer to 2 bounces. That's a clear performance hit. I wish it wasn't so, because I'm really so sick of brushed metal. Ok, so there aren't too many themes i like better, but there are a few.
Speaking of which, I am absolutely in love with that shot of the bastardised Somatic theme. But i bet it'll hurt my powerbook's performance in a serious way :-(
Posted by: at November 18, 2005 11:53 AM
If Apple would build theme support into the fucking OS already, they'd eliminate half the haxie market right there.
Posted by: Rosyna at November 18, 2005 11:59 AM
Yes, we all are aware that the number of bounces an application makes in the dock is the perfect performance test and really tests the speed of the entire system.
Posted by: oliver at November 18, 2005 12:14 PM
Rosyna, did i say it's a perfect performance test? It is a very clear indication though. Opening applications is something i do on a daily basis, perhaps you don't. If my apps are launching slower i notice it and it's annoying.
But it makes better business sense to try and discredit any arguments against your app than actually make it perform better, right?
Posted by: Rosyna at November 18, 2005 12:21 PM
No, because every single one of the arguments have been made to death. It gets annoying repeating the same thing over and over again. Especially when you consider things like application bounces. Yes it's going to take longer to launch an application. We've never denied that. The APEs have to load their preferences and set up everything, after all. Each APE adds about 200 milliseconds to the launch of an application. That might be enough to add an "extra bounce". Yes, we've timed them all.
Posted by: squirm at November 18, 2005 12:21 PM
Rosyna -
Did you read what I said? This is explicitly a case where the haxie did cause the problem. Are you saying that this is not the hack author's responsibility?
Posted by: JHM at November 18, 2005 12:34 PM
Did you read what I said? This is explicitly a case where the haxie did cause the problem. Are you saying that this is not the hack author's responsibility?
No, this is a case where there is a bug in the application, but APE exposes it. How could the haxie maker correct it if the bug is not in their haxie? db did not explain this well, but in many cases these are bugs the user WILL see they will only see them once in 50 tries, but the haxies make it more likely.
You DO take on a responsibility when running a non-standard install, and if a haxie CAUSES the bug it is their fault and should be fixed, but it should not absolve application authors from ignoring their own bugs exposed by a haxie. BareBones will not give you support if a haxie is installed, whether it is their bug or not. THAT is the issue.
Posted by: oliver at November 18, 2005 12:36 PM
Well I'm not responsible for what has been or will be said by others. DB said there was almost no performance hit, and this, in my experience and imho, is incorrect. I was just pointing that out.
You could have responded by saying something like "unfortunately, yes it's going to take longer to launch an application. We've never denied that. The APEs have to load their preferences and set up everything, after all. Each APE adds about 200 milliseconds to the launch of an application. That might be enough to add an "extra bounce". Yes, we've timed them all.". That, in all fairness, is a very good point. But you didn't, you decided it was best to make a sarcastic comment about my post.
Might I suggest you save that comment somewhere and use it as a standard reply whenever people (like me) complain about the SS performance hit. It puts your company in much better light than sarcasm does.
imho.
Posted by: drunkenbatman at November 18, 2005 12:39 PM
Well I'm not responsible for what has been or will be said by others. DB said there was almost no performance hit, and this, in my experience and imho, is incorrect. I was just pointing that out.
I swear to god, Siracusa killed my fucking comments. All of you have got to chill out, because I'm tired of threatening violence, because I'll eventually have to follow through so its not an empty threat.
FYI, I meant for this particular bug -- which was seeing an order of magnitude increase in doing certain things. IE, click search, and it would take 12 seconds for the view to show instead of 1 or 2.
Posted by: squirm at November 18, 2005 12:47 PM
By the way, Rosyna: I've agreed with your postings concerning APE prior to this article. APE doesn't mean a crash report is invalid, actually talk to a hack author if you think there's a problem related to them, etc.
I thought you'd agree with what I said.
But if you seriously think that when there's a haxie-app interaction that's causing a problem that it's the app author's responsibility to debug it, then I'm very very scared.
Posted by: oliver at November 18, 2005 12:52 PM
dude, I'm perfectly chilled man. I'm sitting here on the couch after a long week at the office and i'm in a great mood. I just wanted to add my 2 cents, and i thought it a bit uncalled for that someone would try to discredit my opinion with sarcasm.
but whatever, just please don't threaten violence because it's really not very becoming.
>> "Walter, you can't do that. These guys are like me, they're pacificists."
Posted by: squirm at November 18, 2005 01:09 PM
JFM said:
---
No, this is a case where there is a bug in the application, but APE exposes it.
---
I'm not sure if I believe that that constitutes a bug in the application.
JFM said:
---
How could the haxie maker correct it if the bug is not in their haxie?
---
That's slightly different from what I meant - it may be that changing the code of the app is the final solution. But I don't think that the app author has the responsibility of debugging the issue and tracking it down, and if the 'bug' is going to be difficult to fix.. it's hard for me to think that a dev should give a high priority to make something work just for APE users.
Posted by: Rosyna at November 18, 2005 01:39 PM
Might I suggest you save that comment somewhere and use it as a standard reply whenever people (like me) complain about the SS performance hit. It puts your company in much better light than sarcasm does.
Hence my sarcasm and lack of wanting to repeat myself over and over again. It is a standard response. In fact, it's the very first item on the FAQ.
Posted by: slava at November 18, 2005 01:59 PM
I gotta add my 2 cents (or 2 roubles, whatever).
I'm not sure if I believe that that constitutes a bug in the application.
From our experience (more on that below) most of the times there is a clear bug in the application code (such as releasing an object twice, or attempting to use a NULL object). Yes, the bug is exposed faster when one of the APE modules are loaded in the code, simply because the memory space of the application contains more code in it. No, it doesn't means the bug will not come out if user has no APE modules installed. Lots of things load more code into applications - let alone scripting additions, QuickTime components, whatever. This means the bug will show up on users with no APE installed eventually anyhow.
We've declared our stance on the matter many times. We do take the responsibility. We debug every single case reported to us. If the problem is reproduced, we usually are able to track it down to a particular spot in the affected application code, find a bug (by disassembling and debugging the product without any kind of source code available), and tell the author of the product where we think the problem is. Sometimes we are able to provide a solution to the bug, so the author can fix it right away. You can ask around, we did this for plenty of developers on the Mac scene.
This being said, we will continue doing so. What is beyond me is the hostility we get from some developers, even after we helped them fix the bugs in their products. But I leave that to themselves. Other developers' attitude towards our stuff will not prevent us from examining each case with great patience and attention. =)
it's hard for me to think that a dev should give a high priority to make something work just for APE users.
I don't think that valuing your customers as a second class citizens because they use APE related products is the way to go for any serious developer.
Posted by: John C. Welch at November 18, 2005 03:31 PM
it's like OS 9 and extensions. If you installed some spiffy extension that made an application you needed crash, whose fault was it?
Same thing, different OS. If the application works reliably and predictably on a clean install of OS X, no APE or haxies, but crashes when a haxie diddles with it, it's not the application dev's fault.
It's nice if they do fix that code, but if a haxie is causing problems, then the haxie developer bears primary responsiblity. Asking an application dev to anticipate every conceivable way that a haxie can use APE or some similar framework to modify their application's characteristics is ridiculous. That approaches anticipating infinity. "Anticipate and fix any bugs that might be caused be a third party hack framework being used to diddle your application. No, you have to anticipate every possibility. No, there's no way to list them."
That is a bit arrogant too, and in the end, it's far more of the job of the haxie writer, and the haxie framework developer to "do no harm" than it is of the application writer to "keep harm from being done to it".
Posted by: sundoggy at November 18, 2005 03:41 PM
Oliver, you might want to check out uno (http://gui.interacto.net/). It provides almost system wide "unified" theme, similar to the latest Mail ap. I have seen no performance hit or ill-effects. I can't remember out it works, but it is a different kind of hack implementation than ss/ape. But you only get the one look, but it's a lot better than the many looks currently in OSX.
Posted by: Jason Harris at November 18, 2005 05:55 PM
Wow, I just saw this thread. :)
For the record, here's my stance on this: If I write a haxie, I'm changing the operating system environment into something that the original application developer did not expect. Therefore, any ill effects that result are my fault and my fault alone. It doesn't matter whether it's a bug in the original application's code, or whether it'd also show up using an Input Manager, or whatever. If adding my haxie makes it crash, it's my problem, period, end of story.
Also, ShapeShifter _does_ add time to application launches. It's a trade-off. App launches with ShapeShifter installed take longer, but the result is an extremely minimal performance hit once the app is actually up and running. Once the app is running, ShapeShifter's impact should be unmeasurably small. There's one exception to this, however, and that is menu rendering. Changes in Tiger slowed down ShapeShifter's menu rendering a bit and it's not yet back up to par.
Posted by: Matt at November 19, 2005 03:28 PM
The ability for a user to be able to take a sample of a program instead of just saying "It went wonky doing this" or "It seems slow doing this" is extremely helpful to devs, and something more users should probably be aware of.
For a normal who is restricted to saying, "I don't know - it just crashed," what would you, DB and others, recommend as a starting point or good resource to be able to properly report bugs to a dev? I know that I should learn to actually *program*, which will have to wait until seminary is finished, but anything to help a brother out would be greatly appreciated.
Posted by: Dale at November 20, 2005 07:40 PM
Developers should be very wary of APE (like BB are) because it makes it much easier for certain individuals to pirate software, and to pass on programs that do so.
Also, isn't it an open door for hackers to undermine Cocoa and use it to propagate virii, etc?
Posted by: Rosyna at November 21, 2005 03:47 AM
Dale, you do realize that APE doesn't even have a method to do anything to cocoa, correct? And I'm not sure where you get this pirating idea from. Are you thinking of SIMBL or something?
Posted by: at November 21, 2005 10:59 AM
"I don't think that valuing your customers as a second class citizens because they use APE related products is the way to go for any serious developer."
I think there's a simple solution: The APE user, or unsanity, can pay for the time required to implement the fix.
Posted by: Peter da Silva at November 21, 2005 02:07 PM
The obvious solution if you're one of those guys even more retro than me who thinks black windows are cooler than white ones is to hack the windows shadows so they're also in "negative"... a kind of white "fog" around the window...
Posted by: Abhi Beckert at November 21, 2005 04:48 PM
Rosnya, we're not talking about a 200ms performance hit... In my tests over the years (on several different macs, not just my ones), SS often adds a few seconds to application launches, and sometimes it's even worse. Not that this makes SS a bad product, taking a little longer to open doesn't bother most people.
As for bugs... in my opinion both the haxie author and the app author should be working together, it's effecting customers of both developers, and it could be a bug in either developer's code. Unfortunately if the developer of the app doesn't know how APE works (because he's inexperienced), or even if he simply doesn't have a license for the haxie, this can be difficult (of course, the last one goes both ways).
Slava, I didn't know you went that far to help your customers, wow. If ever you find a bug in one of my apps doing that (never had any issues with haxies so far), I'll owe you big time. Keep it up!
Posted by: Brad at November 21, 2005 08:58 PM
Rosyna, are you claiming that APE isn't used for pirating? If so, you're wrong. There is a system that uses it for dynamic cracking. I found it awhile back when looking for serials and cracks to block in my apps. If you guys aren't aware of it, I'll send you the info off list.
Posted by: Cameron Hayne at November 22, 2005 12:21 AM
I tend to believe the Unsanity guys that most problems "caused" by APE are actually due to bugs in the applications, not in APE or the haxies.
Nevertheless, I understand and support the position of application developers who don't want to hear about these sorts of bugs.
It comes down to what the definition of a bug is.
In a perfect world, we would all be writing programs that are provably correct and such programs likely would not have many bad interactions with haxies, etc.
However, in the real-world we do the best we can towards writing a "correct" program - and then we test, test, test.
From the idealistic point of view, a programming error (e.g. a double release) is a bug even if it hasn't been detected "in the wild". But in the real-world, time constraints lead us to fix only those bugs that we detect in our testing.
And we want to minimize the number of platforms and configurations on which we test. That is where the antipathy towards haxies arises - application developers don't want to have to install APE and various haxies in order to test their apps.
Hence the real-world definition of a bug: a defect that arises when the application is used on one of the supported platforms.
It is the clash between these two definitions of 'bug' that accounts for a lot of the perceived antagonism.
An analogous situation exists with hardware. An app might have a race condition that only causes trouble when running on overclocked hardware. Sure it's a bug (in the sense of the program not being correct), but most application developers faced with a crash report would justifiably say - sorry, but that's not supported hardware.
Posted by: Chucky at November 22, 2005 11:37 AM
Slava,
"What is beyond me is the hostility we get from some developers"
Well, perhaps taking to heart the repeated suggestions from developers to add the ability for apps to request that APE doesn't load in their particular space would end that hostility.
Posted by: Chucky at November 22, 2005 11:40 AM
Rosyna,
"And I'm not sure where you get this pirating idea from."
I find it difficult to believe that you are unaware of the widespread APE based pirating going on. It's one thing to make the claim that it isn't your responsibility, but it's completely another thing to feign ignorance.
Posted by: Peter da Silva at November 22, 2005 01:08 PM
I can see that people would find APE a convenient way to get started on writing a backdoor into an application, but the techniques APE use are already well documented and widely known. All APE does is provide a safer and more convenient way to use them. If it didn't exist people would use mach_inject and mach_override, or use Services or contextual menu plugins, or just patch the frameworks directly. If Unsanity implemented the mechanism you're asking for, it wouldn't hurt the black hats one bit.
Mac OS X is an operating system with an open source and open systems background, and the APIs and interfaces are, at the bottom, relatively simple and easy to interface with. You've got to come to terms with that one way or another, hopefully accepting that it's impossible to lock down your app completely rather than disabling one after another the features of OSX that make it worth its weight in silicon.
Posted by: nate at November 22, 2005 02:55 PM
I just wanted to point out to Rosyna that this is not the Unsanity site, and expecting everyone here to have read your FAQ is unrealistic. Please save your sarcasm for your own site.
Posted by: John C. Randolph at November 23, 2005 01:27 AM
Repeating what I just posed over on Rich Siegel's blog:
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
PS: Rosyna, I wish I could have sent you all the bug reports I saw with your code in the backtrace. APE is a dangerous, unsupported hack. If I ever ship a shrinkwrapped app again, I'll check for APE, and immediately exit if I detect it.
Posted by: Peter da Silva at November 23, 2005 04:20 PM
Well, I'm a user of APE-based applets, including Metallifizer, and I'll continue to use APE no matter what Apple says until such time as Apple quits trying to micromanage the "user experience" for the sake of "branding" and lets me disable Metal directly.
If an application came up and said I had to disable APE to run it, that application would go right back where it came from. If the vendor doesn't take it back and tries to make me eat the cost, they better be able to point to some place on the box or on the website where I can't miss it that says it won't run alongside APE.
And this holds for Shapeshifter and any other program I happen to use to fix Apple's user-interface cockups. My computer, my wallet, my rules.
Posted by: Jon H at November 23, 2005 06:47 PM
"My computer, my wallet, my rules."
So if you decide to write random bytes over your executable files, vendors are responsible for making their applications run correctly in such a hostile environment?
Posted by: Peter da Silva at November 23, 2005 08:01 PM
I'm not talking about software that crashes when APE is installed. I'm talking about software that refuses to run when APE is installed whether APE would have cause it to crash or not.
If I needed to patch your application to fix a user interface problem (whether you or Apple or anyone else considers it a problem is irrelevant), and your software checksums itself and refuses to run if I have patched the executable files, and you had not clearly disclosed ahead of time that it would do so and given me a chance to decline to purchase the product... yes, I'd demand my money back on that too.
If I patch it and that patch makes your program crash, that's my problem. If one of my haxies makes your program crash, and I need to run your program anyway, that's my problem and I'll turn that haxie off for your program.
But if you preemptively prevent me from patching or running extensions in your program, that's your problem and it stays out of my computer.
Posted by: John C. Randolph at November 23, 2005 10:12 PM
Peter,
Apple has no interest in how you damage your OS X installation. Apple's only concern in this is whether they will support your system after you damage it. They won't, and it isn't reasonable to expect them to do so. Same with third-party developers.
BBEdit went the extra mile already, by putting up that dialog box. I'd probably just exit.
-jcr
Posted by: John C. Randolph at November 23, 2005 10:18 PM
Oh, and BTW:
"If an application came up and said I had to disable APE to run it, that application would go right back where it came from."
Good! Because frankly, it's not worth the cost to try to support a user who inists on damaging a product. I can't tell you how many times I got a tech support incident that amounted to: "Dear Apple DTS. If I stick my thumb in my eye, it hurts. It shouldn't hurt. This is an Apple Bug, in my uninformed opinion. So, my question is: How do I make it not hurt?" (and then the punchline:) "PS, not sticking my thumb in my eye is not an option!"
-jcr
Posted by: Peter da Silva at November 28, 2005 01:52 PM
John, I'm not talking about your supporting your application after it's run into a problem with Haxies, I'm talking about deliberatly breaking your program to keep it from working with Haxies. And I suppose that if you gave me my money back when your application turns out to be deliberately broken then I guess I would have no further complaint about you.
But checking for and refusing to run if it detects third party software in my system whether or not that software is actually causing problems is deliberately breaking your software, and that's that what "If I ever ship a shrinkwrapped app again, I'll check for APE, and immediately exit if I detect it." sounds like to me.
As for Apple support... I'm probably more capable of diagnosing and fixing any problems I create in the OS better than most of the people working support at Apple. I've been working on UNIX since before the Mac came out, and I was one of the 386BSD patchkit maintainers when Jobs was still selling black cubes. I'm more likely to dig up a problem in the Darwin sources and send Apple a patch than demand Apple support my own tweaks.
And "damage the installation"? It's actually pretty hard to "damage" OS X short of going Ghengis-Khan in /System (you know, like that 'writing random bytes over executable files' crack). You don't have to coddle a UNIX-based system the way you have to with Windows.
I guess you'd approve of the approach I take on Windows. I have one active application at a time. I don't use any third-party enhancements. I even disable or defang the services and applications that Microsoft provides that decrease Windows reliability... like Internet Explorer and the DNS Client Service. I've reluctantly come to accept the necessity of antiviral software, but if you're going to check for ANY software that might "damage your system" that's the place to start.
But OS X is made of tougher stuff, even if it could be better (I was so hopeful when I heard they'd upgraded UFS in Panther that they'd actually support UFS properly so I could give HFS the boot). Running an application that patches apps at runtime, that I can disable selectively for applications when I have a problem with them, is not going to "damage the installation".
Is there a screenshot of this BareBones "error message", or is this what they tell you when you email for support?