Brief Tutorial on Reverse Engineering Mac OS X
rjw57 writes "There is an article on OSNews I wrote about how the guy behind Desktop Manager goes about reverse engineering APIs from Mac OS X with a brand new example not revealed anywhere else. From the article: 'I am often asked in email how I uncovered the API calls I use in Desktop Manager which are, unfortunately, undocumented. This article aims to give a little insight into the techniques I use to reverse engineer Mac OS X in order to provide extra functionality to users and extra information to third-party developers. In this article all the utilities I use are a standard part of Mac OS X's developer tools which are freely available.'"
So jobs invented capitalism and anything you have to buy is evil?
Do you live on a commune and make your own clothes too?
Did you buy your car, TV or make those?
The if it isnt free, its root of all evil" crowd is tiresome with the dogma.
Ah - right. So when a company has undocumented APIs then it is because they are not documenting them for altruistic reasons.
Unless the company is Microsoft - then it becomes evil.
The slight problem with this slightly simplistic argument is that the APIs are not undocumented. They are documented, otherwise the Apple developers would not be able to use them (and, after all, the article is about disassembling an Apple application to find out how they worked).
The APIs are just not documented publically - Secret APIs in other words.
Of course this is no doubt still a case of Apple's Secret APIs: Good vs Microsoft's Secret APIs: Evil, but it's late, and I'm not up to the mental gymnastics that will be required to make the leap. No doubt an Appleista will be along in due course to make clear the path to enlightenment.
don't write a commercial product that depends on what you discover by this kind of spelunking, unless you are fully prepared to deal with the consequences of it breaking at any software update.
Don't write a commercial product at all unless you're prepared to deal with the consequences of it breaking at any software update. Don't write any software at all unless you're prepared to deal with it breaking at any software update. Don't even USE software unless you're prepared to deal with it breaking at any software update.