Slashdot Mirror
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.'"
It's an undocumented API.
That's one of the many reasons why some APIs are left undocumented: because they are expected to be unstable.
Can't really blame Apple on this one. They didn't publish the API, and changed it in Tiger to a more flexible three-part solution. Eventually they may decide the design's a good one and publish the API.
Until then, use it at your own risk.
In this example, Apple broke undocumented APIs. Anyone writing or using an application that takes advantage of undocumented APIs should be prepared to discover that they've been changed, moved, or deleted entirely.
The APIs that DesktopManager uses were probably left undocumented precisely because Apple knew they were going to be subject to change.
Apple is good, and we are going to talk to talk about it.
This space intentionally left blank.
I myself have found that by really learning how to manage windows the "apple way" I don't really feel the need to use virtual desktops much (I used to use DesktopManager).
For me, this means using Hide (Command-H), Swich app (Alt-Tab), Focus on window (active) or next window (a custom key binding like Alt-Tab), and Expose.
But that doesn't mean there isn't a place for virtual desktops.
One thing that expose relies on is that the conceptual groupings of "All app windows" and "All of this apps windows" are all you need. The problem is if you have a large number of similar looking windows from different applications it can be difficult to manage even with Expose.
Virtual desktops can give you custom Expose groups - which can narrow the search for a particular window. This can be useful if you are working on several complex tasks that use multiple windows from multiple apps (each task can get its own desktop), and also have a bunch of side apps - like your calendar, email, instant messenger etc.
So Expose solves the window management problem to an extent, but it can be combined with virtual desktops when things become even more complex.
I personally don't use multiple desktops, even in Linux, but would never, ever consider taking away that functionality (if I had the power to do so), knowing how useful it is to so many other people. For that reason, I think it'd be a great idea for Apple to add this feature to OSX.
We apologize for the inconvenience.
They have done great, exception for the multiple times they break their own HID/HIG. iTunes, for example, and the whole brushed metal is basicly an excuse for making cool-looking apps. I like brushed metal, but apple has changed the HIG to morph around what they think looks best. There really should only be 1 window gui, aqua.
Mail, in OS X, is even a third window gui(?), it isn't quite Aqua, and has noticable differences unlike any other application on OS X. Why? Who knows.
Apple has done great, but they have clearly ignored their own UI rules for the sake of eye candy at times.
Expose is for switching between windows.
Virtual desktops are for logically grouping/partitioning windows (more typically, whole applications). Virtual desktops are, basically, a poor man's multi monitor setup.
The two solve different problems.
No doubt an Appleista will be along in due course to make clear the path to enlightenment.
You called?
The answer to your difficulty is obvious: follow the money. What strategic advantage does Apple gain by not publicly documenting these APIs? A corner on the windows management market? I'm sure is worth a whole lot because you can see how much Apple charges for it at the Apple Store. Oh, wait, you can't, cause there is no such separate competing product that Apple profits by leveraging their OS.
vs. Windows, where, let's see, they made a substantial amount of their $50 Billion on by selling Office--which required that they kill their competition in Office applications.
"But what of IE?", I hear you plaintively cry. "Doesn't Microsoft give that away for free?" Certainly. But their clear strategy was to use the product to own the web, and IE was the platform to do it.
When Apple sells a virtual desktop management tool, besides the OS, and doesn't document the APIs, you'd have an argument. For example, I imagine QT has access to things that WMP doesn't, but proving that is an exercise for the reader. As it is, you're just trolling. Speaking of simplistic arguments.
--
$tar -xvf
Although I can't find a reference to the source, I believe Apple already explained the reason there are documented and undocumented APIs ( these are also known as public and private APIs) The reasoning is that any private APIs are not yet set in stone, so if you do use them you should not be surprised that your application breaks with the next point release. These APIs are undocumented, but not hidden. If you wish to create programs that are stable between releases, then you should only use public APIs. The choice is yours.
Remember there is a difference between hidden APIs and undocumented APIs. Are all the APIs in Linux documented?
Jumpstart the tartan drive.