I've been reading posts about Application Enhancer (henceforth referred to as "APE Framework") and Application Enhancer Modules (henceforth referred to as "APE Modules") in various forums and update sites and I must say I am absolutely appalled by the amount of fear, uncertainty, and doubt (FUD). It has spread all over the internet like a plague and over time it has gotten worse and worse.
What is the APE Framework? What is an APE Module?
First, I need to make clear the difference between the APE Framework and the APE Modules it loads.
The APE Framework is a framework. It is installed in /Library/Frameworks/ like a good framework should be. The APE Framework on its own does very little. It provides a mechanism to load APE Modules into your applications, and a convenient API to help distribute messages to the modules. It uses a background program, also called a daemon, known as aped to load APE Modules and pass messages. This API/daemon structure is similar to many other frameworks built into Mac OS X: DiskArbitration/diskarbitrationd, Printing/cupsd, and CoreServices/coreservicesd. Without any APE Modules modules installed, the APE Framework is entirely dormant.
The APE Framework loads APE Modules from various locations such as ~/Library/Application Enhancers/ (in the user's folder) and /Library/Application Enhancers/ (in the root of the boot drive). APE Modules are plugins loaded by the APE Framework. They are much like Internet Plugins, Contextual Menu Plugins, and QuickTime components -- when an APE Module is called to do something in an application, the APE Module does all the work.
Now that this distinction has been made, I will address the misinformation and FUD directly.
"APE is a hack using unsupported and undocumented methods to get into applications."
The APE Framework 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.
"APE brings us back to the days of Mac OS 9 Extensions."
Mac OS 9 Extensions (INITs) patched the core operating system calls in an unstructured method which would be most similar to patching kernel calls in OS X. If an extension were to fail, it would bring down the entire computer and require a reboot -- or if it corrupted memory in such a way that it didn't crash, all applications would suffer.
In contrast, APE Modules are loaded only into applications. They do not break down the barriers of protected memory. If for some reason an APE Module causes a crash, only that one application will be affected. The rest of the system will be unaffected and there will be no reason to reboot because of it. It is impossible for the APE Framework or any APE Module to cause a kernel panic on Mac OS X.
In Mac OS 9 (meaning any version of the Mac OS before Mac OS X), it was possible for two extensions to patch the same function calls and cause a conflict. However, this problem was generally caused by using incompatible patching methods. The APE Framework provides a unified (and free for non-commercial use) function modifying method which is designed to make modifying a function's behaviour a lot safer and more consistent than on Mac OS 9.
"APE caused my applications to crash."
Not the APE Framework itself. An APE Module can cause an application to crash, but the APE Framework itself has been generally bug-free during its existence. We have had only one confirmed bug in the APE Framework, which was itself caused by a bug in Mac OS X 10.1.5 that Apple fixed in 10.2. You can blame individual APE Modules all you want, but it's very unlikely to be APE Framework itself.
"But my crash log clearly implicates APE as the cause of the crash."
There's a good chance you are reading the crash log incorrectly. This part really saddens me since it often comes from developers who can't make the distinction and figure out the true cause of their crash which makes it much harder for them to fix bugs in their own code.
Here is a very basic explanation of the crash log format (abbreviated) as of Mac OS X 10.3.2:
Date/Time: 2004-05-25 11:26:25 -0700
OS Version: 10.3.3 (Build 7F44)
Report Version: 2
Command: BombApp
Path: /Volumes/Heterodoxy/Developer/Applications/Extras/BombApp.app/Contents/MacOS/BombApp
Version: 1.0 (1.0)
PID: 9101
Basic information about the process that crashed.
Thread: 0
Current thread the application is executing.
Exception: EXC_BAD_ACCESS (0x0001)
Why it crashed. This is a really vague reason, which is usually not very useful in pinpointing the cause of the crash. Could be a call to abort() or dereferencing a NULL pointer. This one means it could not access the memory at the given address. A list of these exceptions and their meanings can be found in /usr/include/mach/exception_types.h.
Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x00000000
See above. This does NOT mean a kernel panic occurred. This one means that the memory is valid, but was accessed incorrectly (usually by attempting to write to read-only memory). A list of these codes and their meanings can be found in /usr/include/mach/kern_return.h if you have the developer tools installed.
Thread 0 Crashed:Notice the word crashed at the top of this thread listing. VERY important. If you do not see the word crashed on a thread, it generally means that nothing in the thread's back trace has anything to do with the crash. A typical application will have several threads, but only one of them can be the one that caused the crash.
0 com.apple.BombApp 0x00004398 0x1000 + 0x3398
1 com.apple.CoreFoundation 0x90191a08 __CFRunLoopRun + 0x5c8
2 com.apple.CoreFoundation 0x90195f1c CFRunLoopRunSpecific + 0x148
3 com.apple.HIToolbox 0x927d62d8 RunCurrentEventLoopInMode + 0xac
4 com.apple.HIToolbox 0x927dca40 ReceiveNextEventCommon + 0x17c
5 com.apple.HIToolbox 0x927fe618 AcquireNextEventInMode + 0x48
6 com.apple.HIToolbox 0x927fbae8 RunApplicationEventLoop + 0x88
7 com.apple.BombApp 0x00004950 0x1000 + 0x3950
8 com.apple.BombApp 0x00004128 0x1000 + 0x3128
9 com.apple.BombApp 0x00003fa8 0x1000 + 0x2fa8
This includes a backtrace. This is where it actually crashed. The call graph goes from bottom to top (bottom being oldest, top being more recent basically). The numbers of the left is the call depth. Then to the right you have the bundle identifier of the code image that contains the address on the right of it. For example com.apple.HIToolbox contains the address 0x927fbae8 and the function RunApplicationEventLoop is at or near that address. The bundle identifier com.apple.HIToolbox happens to be of the HIToolbox framework at /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/.
Thread 1:
0 libSystem.B.dylib 0x900074c8 mach_msg_trap + 0x8
1 libSystem.B.dylib 0x90007018 mach_msg + 0x38
2 com.unsanity.ape 0xc000a954 __ape_internal + 0x90b4
3 com.unsanity.ape 0xc0001330 __ape_agent + 0x40
4 libSystem.B.dylib 0x900246e8 _pthread_body + 0x28
This is the APE Framework thread. Notice the lack of the word crashed? It means it was NOT the cause of the crash. It had nothing to do with it. If 90% of your users experience a bug and happen to have the APE Framework installed it does not mean the APE Framework was related to the crash. It just means that a lot of mac users have the APE Framework installed and a developer should not ignore the bug just because of that. Especially if 10% of the rest do not have the APE Framework install and experience the exact same crash which happens more often than not.
This thread is the APE Framework workloop thread. It sits here waiting for APE-specific messages (for example, sent when you change settings in the APE Manager preference pane). When it receives a message, it sends them to any loaded APE Modules for processing, and the modules use this thread to process the messages. This thread does NOTHING when a message is not being processed. If the backtrace looks like this, it probably had nothing to do with crashing the application.
The backtrace contains the word "ape" intentionally, to make it clear what the thread is. We could have easily hidden it, but it was left in so that developers would be able to easily identify it in the extremely rare cases when an APE Modules causes a crash on this thread. However, since so many developers and users are confused by this thread's existence, we might remove any trace of the APE Framework from it to clarify crash logs.
Binary Images Description:
0x1000 - 0x4fff com.apple.BombApp 1.0 /Volumes/Sanctified/Developer/Applications/Extras/BombApp.app/Contents/MacOS/BombApp
0x2e7000 - 0x2effff com.unsanity.xounds.cocoa Xounds Cocoa Bits version 2.1 (2.1) /Volumes/Consecrated/rosyna/Library/Application Enhancers/Xounds.ape/Contents/PlugIns/Xounds Cocoa Bits.ape/Contents/MacOS/Xounds Cocoa Bits
0x729000 - 0x731fff com.unsanity.xounds Xounds version 2.1 (2.1) /Volumes/Consecrated/rosyna/Library/Application Enhancers/Xounds.ape/Contents/MacOS/Xounds
0x73f000 - 0x742fff com.rt.cwm ??? (1.1) /Volumes/Consecrated/rosyna/Library/Application Enhancers/CWM.ape/Contents/MacOS/CWM
0x759000 - 0x765fff net.sabi.ICeCoffEE ??? (1.4) /Volumes/Consecrated/rosyna/Library/Application Enhancers/ICeCoffEE.ape/Contents/MacOS/ICeCoffEE
0x776000 - 0x77cfff alex_lagutin.audio_hijack.server 1.2.4 /Volumes/Consecrated/rosyna/Library/Application Enhancers/Audio Hijack Server.ape/Contents/MacOS/Audio Hijack Server
0x793000 - 0x79bfff com.geekspiff.paranoidandroid Paranoid Android Version 1.1 (1.1) /Volumes/Consecrated/rosyna/Library/Application Enhancers/Paranoid Android.ape/Contents/MacOS/Paranoid Android
0x7c6000 - 0x7dffff com.unsanity.shapeshifter ShapeShifter Version 1.2 (1.2) /Volumes/Consecrated/rosyna/Library/Application Enhancers/ShapeShifter.ape/Contents/MacOS/ShapeShifter
0x101b000 - 0x1029fff com.unsanity.shapeshifter ShapeShifter Version 1.2 (1.2) /Volumes/Consecrated/rosyna/Library/Application Enhancers/ShapeShifter.ape/Contents/PlugIns/CocoaStuff.plugIn/Contents/MacOS/CocoaStuff
0x11c5000 - 0x12a5fff com.divxnetworks.DivXCodec 5.1b /Library/QuickTime/DivX Pro 5.component/Contents/MacOS/DivX Pro 5
0x16e0000 - 0x16e5fff com.apple.iokit.IOQTComponents 1.3 /System/Library/Components/IOQTComponents.component/Contents/MacOS/IOQTComponents
0x16f1000 - 0x16f6fff com.apple.GeForceGA 1.3.18 (3.1.8) /System/Library/Extensions/GeForceGA.plugin/Contents/MacOS/GeForceGA
0x54a8000 - 0x5569fff com.apple.Kotoeri 4.0.0 /System/Library/Components/Kotoeri.component/Contents/MacOS/Kotoeri
0x88eb0000 - 0x88ebcfff com.apple.agl 2.5 (AGL-2.5) /System/Library/Frameworks/AGL.framework/Versions/A/AGL
0x8b0c0000 - 0x8b728fff com.apple.QuickTimeComponents.component 6.5.1 /System/Library/QuickTime/QuickTimeComponents.component/Contents/MacOS/QuickTimeComponents
0x8c390000 - 0x8c3d1fff com.apple.QuickTimeFirewireDV.component 6.5.1 /System/Library/QuickTime/QuickTimeFirewireDV.component/Contents/MacOS/QuickTimeFirewireDV
0x8df60000 - 0x8df76fff libJapaneseConverter.dylib /System/Library/CoreServices/Encodings/libJapaneseConverter.dylib
0x8e990000 - 0x8ea21fff com.apple.QuickTimeMPEG4.component 6.5.1 /System/Library/QuickTime/QuickTimeMPEG4.component/Contents/MacOS/QuickTimeMPEG4
0x8fe00000 - 0x8fe4ffff dyld /usr/lib/dyld
0x90000000 - 0x90122fff libSystem.B.dylib /usr/lib/libSystem.B.dylib
0xc0000000 - 0xc000efff com.unsanity.ape 1.4.2 /Library/Frameworks/ApplicationEnhancer.framework/Versions/A/ApplicationEnhancer
These are all the various loaded code images and their locations. A code image does not have to be doing anything to be loaded. It just means all the functions it exports are available to the host. You'll notice in this one that the APE Framework along with lots of APE Modules and other system and third party modules are loaded. Xounds, Silk, ShapeShifter, CWM, Audio Hijack Server, Kotoeri (Apple's Japanese input method), DivX 5, and others are loaded. This does NOT mean they caused or had anything to do with the crash.
What does a real APE crash look like?
So that was a non-APE related crash log. Let's now examine one that is clearly caused by an APE Module.
Exception: EXC_BAD_ACCESS (0x0001)
Codes: KERN_INVALID_ADDRESS (0x0001) at 0xffffffff
Thread 0 Crashed:
0 com.unsanity.fontcard 0x06935224 FC_MenuView::Initialize(TCarbonEvent&) + 0x4ac (LabelItemView.cp:475)
1 com.unsanity.fontcard 0x069388f0 TObject::ObjectEventHandler(OpaqueEventHandlerCallRef*, OpaqueEventRef*, void*) + 0x194 (TObject.cp:182)
2 <<00000000>> 0x927d24e4 0 + 0x927d24e4
3 <<00000000>> 0x927d2758 0 + 0x927d2758
4 <<00000000>> 0x927d6bc0 0 + 0x927d6bc0
5 <<00000000>> 0x927eed7c 0 + 0x927eed7c
6 <<00000000>> 0x927f368c 0 + 0x927f368c
7 com.unsanity.fontcard 0x06934c38 FC_MenuView::Create(unsigned long, OpaqueMenuRef*, unsigned short, OpaqueControlRef*, OpaqueControlRef**) + 0x16c (LabelItemView.cp:308)
8 com.unsanity.fontcard 0x069346fc FC_MenuViewCreate + 0x4c (LabelItemView.cp:217)
9 com.unsanity.fontcard 0x069158f0 FC_CollectionMenu + 0xaa0 (APEMain.c:3996)
10 com.unsanity.fontcard 0x06918120 FC_CompiledMenu + 0x214 (APEMain.c:4844)
11 com.unsanity.fontcard 0x0691a5d4 FC_DoNothing + 0x8c8 (APEMain.c:5639)
12 <<00000000>> 0x927d24e4 0 + 0x927d24e4
13 <<00000000>> 0x927d2758 0 + 0x927d2758
14 <<00000000>> 0x927d6bc0 0 + 0x927d6bc0
15 <<00000000>> 0x9282c2dc 0 + 0x9282c2dc
16 <<00000000>> 0x9284c120 0 + 0x9284c120
17 <<00000000>> 0x928a98fc 0 + 0x928a98fc
18 <<00000000>> 0x92818754 0 + 0x92818754
19 <<00000000>> 0x9285dce8 0 + 0x9285dce8
20 <<00000000>> 0x92884194 0 + 0x92884194
21 com.unsanity.fontcard 0x06916df0 FC_MenuSelect + 0x3c (APEMain.c:4511)
22 MCPZ.stb 0x00609ad4 0x5c59d0 + 0x44104
23 <<00000000>> 0x927d24e4 0 + 0x927d24e4
24 <<00000000>> 0x927d2758 0 + 0x927d2758
25 <<00000000>> 0x927e4be8 0 + 0x927e4be8
26 <<00000000>> 0x927e8c98 0 + 0x927e8c98
27 <<00000000>> 0x927e3188 0 + 0x927e3188
28 <<00000000>> 0x927d25a0 0 + 0x927d25a0
29 <<00000000>> 0x927d2758 0 + 0x927d2758
30 <<00000000>> 0x927e4be8 0 + 0x927e4be8
31 MCPZ.stb 0x005fb270 0x5c59d0 + 0x358a0
32 Microsoft Word 0x020d9de0 0x2008000 + 0xd1de0
33 Microsoft Word 0x0201d1e0 0x2008000 + 0x151e0
34 Microsoft_Office_2001Z 0x01021954 0x1008000 + 0x19954
35 Microsoft Word 0x0201cc28 0x2008000 + 0x14c28
Notice all the references to com.unsanity.fontcard at the top of this crash log? Also notice the word "crashed" in "Thread 0 Crashed:" ? This means that FontCard (an APE Module) was clearly the cause of this crash. There are no ifs, ands, or buts about it. FontCard was intentionally modified to cause this crash; it does not represent a bug in any shipping version.
"But disabling the APE Framework stops the crashes."
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. It is much like your computer will not crash if it is not turned on and your car will not make that funny noise it always makes when you shift into fifth gear if the engine isn't running.
Another possibility may be that neither the APE Framework nor the APE Modules you are using are directly causing the crash. In at least three confirmed (by the application's developer) cases the application had a memory bug in it. In these cases the developer freed memory they shouldn't have freed and it was reused as if it was not free. The loading of APE Modules caused new information to be assigned to the free memory space (as it is supposed to be) and when the application reused the free memory it wouldn't give them the data they expected, causing a crash. In other words, APE can actually expose a pre-existing bug in an application.
"The APE Framework and APE Modules are spyware."
I am not sure what reasons people have for believing this. 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?
Neither the APE Framework nor any APE Module is spyware. In fact, one of the reasons we require a license for any APE Module is so that spyware/malware/adware is NOT created. If Unsanity finds out about an APE Module being used to create spyware or any malicious software, we will revoke the license for that author.
For what it's worth, it seems that this rumor started in a forum designed for pirating software and spreading serial numbers. Some people claimed we must be phoning home because all their silly cracks and hacks never worked even when the other pirates swore they should. But do you really think you should take the word of a frustrated 13-year-old script kiddie? Test it yourself. the APE Framework and APE Modules do not send any information back to Unsanity or anyone else. We have no desire to do that, and we never will - we think spyware sucks.
Quick Conclusion
In summary, there are two very distinct parts of APE, the APE Framework and APE Modules and they should not be confused. The APE Framework has had one bug in its entire commercial life-span which was fixed almost two years ago and it has not been the cause of a crash or misbehaviour since then. It is kernel extensions, not the APE Framework, that resemble Mac OS 9 extensions. The APE Framework thread is not the cause of the crashes in the crash logs. And finally, nothing Unsanity produces or has ever produced is spyware. If you want to criticize APE Modules or the APE Framework, it's fine by us, but please make sure to check your facts to see if what you are saying is even possible.
I find myself in the market for a powerbook case for my soon to be arriving new powerbook.
Alas, my Titanium 667 suffered some fairly major bumps and bruises which resulted in two white vertical lines through the screen and a cracked case. ( I wonder what it will fetch in that condition on ebay... )
So even though it was serving my needs well, I have a shiny new Aluminum powerbook on the way to serve me even better! ;)
The question I'd like to ask is what cases can you recommend? I am looking for something that is fairly small. I'm not looking for the type of case that your powerbook just so happens to fit into. I would prefer a case designed specifically for the Apple Powerbooks - one that is both durable and stylish. I use my case mainly for packing the laptop to and from the office, but I also need it to hold a paperback, couple of snacks, and a PDA for plane rides.
Yeah - so my requirements are pretty much what everyone else is looking for I suppose. So what case(s) can anyone recommend?
Update: I'm looking for a case for a 15" Powerbook.
(a few places I've looked a bit)
Booq
Crumpler
Timbuk2
Tom Bihn
Brenthaven
Acme
An updated and slightly less Paranoid Android is available.
Since the version changes are few, here they are in their entirety:
Version 1.1 (May 22, 2004)
- Protected applications now appear in the APE Manager preference pane under Enhanced Applications.
- Added support for Jaguar.
- Added more permitted URL schemes. The permitted schemes are 'http', 'https', 'ftp', 'mailto', 'itms', 'addressbook', 'rtsp', 'pnm', 'ical', 'webcal', 'sherlock', 'guikit', and 'file'.
Apple's just released a Security Update that resolves the security vulnerability with Help Viewer. Unfortunately, that's all it resolves. The exploit I wrote that freaked me out enough to write Paranoid Android is still wide-open.
So unfortunately, at this time, I still recommend using Paranoid Android, and I hope that Apple fixes the remaining holes quickly and cleanly.
I've also written a whitepaper that explains the issues more fully and includes my benign test exploit.
Been a nasty week for security…
Saw this on a Russian site and thought it is pretty funny. Picture below is a poster ad in the Moscow metro, advertising Microsoft and it's new "Now I Know" campaign they are running there.
The printed text on the banner says: "Before I wasn't thinking about this. Now I know." Somebody added another line with a ballpen, and it makes the whole ad look quite different. Oh the Microsoft, WinXP network activation, and the joys of being a legal user. ;)
A new security vulnerability in Apple's Mac OS X is pretty nasty and has had lots of people worried about surfing the net. So, we've whipped out a quick, free haxie that'll give you some protection until Apple comes up with the real-deal fix.
The vulnerability involves the use of URL "schemes". These are the part of a web address that specifies what program should be used to handle the address. The vulnerability is nasty because potentially, a malware author could write an exploit that would delete your home directory, and it could be triggered simply by surfing to the wrong web page. Hence, people's concern.
Paranoid Android to the rescue! Paranoid Android can protect you from this potential vulnerability until Apple makes an official fix available. It does this by watching the URL schemes that are requested and delaying them until you've had a chance to say whether you'd like to proceed or not. If you know that the url that's being loaded is legit, go ahead, but if it looks suspicious, Paranoid Android gives you an opportunity to cancel it.
Paranoid Android is free! Enjoy, and surf safely!
Just to add on to Jason's post - Paranoid Android is designed to shield you from a different approach than described in the recent Wired article and other sources, so this is not about recent help:// vulnerability (although it will shield you from that one as well). =)
In a move that I've been expecting for quite some time, Apple has publicly gone on record saying that they'll slow down the pace of Mac OS X updates.
Frankly, I've been impressed that they were able to deliver so much so quickly up until this point. Overall I think they did exactly what they had to. Mac OS X 10.0 went out the door with a lot of rough edges, but it came at a time when showing something rather than nothing was critical for Apple.
They then hit us with rapid updates to address the problems and add features. (kudos to the developers!) I think we're sitting at a pretty solid point in the OS evolution right now. I love Panther. It is by far my favorite revision of the OS to date. Sure this is expected, but I do know a fair number of users who have opted, for one reason or another, to stick to Jaguar. (and if you're still running 10.1...well, we need to talk.)
So the question is, why the slower pace? Is Apple trying to give their developers a bit of a break? Has the OS really grown beyond their ability to maintain that pace? Combination of the two? Or yet another reason?
I feel that they are probably just ending up with too many loose ends. That sort of thing can happen in the development process. Features are added at a breakneck pace and some of the polish is left for later. Later comes and rather than add that polish and tie up loose ends, the developer is hit with a request for additional features and deadlines. Cycle begins again. :)
So the speculation of the hour is what will happen with Tiger? Will it be the last of the line of yearly updates? Or will it be the first to be on a new schedule? I am predicting the latter. I expect a preview to be given at WWDC, but I don't envision developers walking out with a pack of CD's to install. (side-note: what's up with the Panic boys being the poster children all over ADC? I seem to find them in another collage every week or two... there is some kind of conspiracy here, I just can't put a finger on it!)
So let's hear the votes, CD's in hand at WWDC or not?
So now that Menu Master 1.1.1 is ready for release (it is a download link, that it is) and will be released sometime next week As promised, work on the massively massive FontCard update will now commence. What do y'all want? The sky is the limit. Screenshots or mockups of what you would like are much appreciated. Email those to my name at unsanity.com (my name is rosyna, the at is an @ and there are no spaces). Of course, those that are first to ask for a feature that does get implemented will get a free license so it is recommended you give a valid email address so you can get what's coming to you.
Now, here is another question. First, the set up: some features can only be implemented on Panther and later. Now, the punch line: should the next FC be 10.3 only or should it work on 10.2 as well? There are no major problems with supporting 10.2 still but testing FC under 10.2 is very difficult so we'd need a lot of people still running 10.2.8 to play with it.