Slashdot Mirror
How OS X Executes Applications
MacHore writes "0xFE has an excellent tutorial on Mach-O, which is the file format used by OS X executable files and libraries. It goes into great detail about how Mach-O works, and explains what OS X actually does when it loads and runs an application. Subtopics include Universal Binaries, The Dynamic Linker, Using otool, and other goodies."
Am I the only one to notice that the supposed binary representation of 0xFE on the blogger's page is actually that of 0x7E (ie, it's missing a one)?
Same reason 3com.com, 37signals.com, and 23.com exist: the RFC was a Request For Comments, and some people commented "no."
For more information, click here.
I have an old 600MHz iBook with 640MB and it is slow to launch stuff. A 600MHz iMac is a much faster machine with the same amount of RAM but those are the compromises of a cheap portable machine. The 2.5" drive is slow too - it's not necessarily Mach's fault. You should have seen OSX 10.0 - launching without all the fancy prebinding that came later was really really slow even on 'fast' machines. I still hope for further optimisations on Mach but it's all about design compromises so I don't hold my breath.
Got a client's 2.1GHz Macbook Pro here and it's really quick to launch everything - Aperture just opens in one bounce and Safari is close to instant. The relative 'slowness' of mach will become irrelevant in the future for sure.
spoonerize "magic trackpad"
When I try and install something on OS X that doesn't have the required dependencies, it simply fails to work and gives no user-friendly clues why.
.app directory which contains all dependencies with the sole exception of frameworks that are present on any version of Mac OS X that the app is capable of running on. In other words, a properly packaged Mac OS X app has no external dependencies - everything it needs to run is either in the .app directory, or comes standard with Mac OS X.
.app directory (aka the app bundle) is broken, since users can and will relocate apps to removable media for use on other machines.
We're talking about applications here. On Mac OS X, a properly packaged application lives in a
Any application packaging that assumes that users will not relocate an application is broken on Mac OS X. This means that any having dependencies not contained inside the
Now, some misguided *nix hackers will cobble together an application to run on Mac OS X that scatters little *nix file turds all over various directories, or will hard code installation directories so the application is not relocatable. These are both wrong on Mac OS X (though common practice on *nix) because Mac users have been relocating applications since the mid 1980s, and will continue to do so.
"I forgive you stupid people" -Neurotically Yours
I wouldn't consider the mad hatter mad. Just reality impaired. He sure can make a mean cup of tea.
Confused? Not as much as me.
You are not alone. This is not normal. None of this is normal.
Just as importantly, even if you can install it to any user specified directory, can you move it elsewhere after installation and still have it work? Can you move it to a CD, pop that CD in any other Linux user's machine and have the app run off the CD? Properly packaged Mac OS X apps do all these things.
My god! That will use up megabytes of disk space!
I also find it totally hilarious how Linux users are now advocating a completely centralized model of software distribution. Freedom of choice! As long as you only ever choose things approved by your distro maker!
My god! That will use up megabytes of disk space!
*sighs* - OS X provides a core set of libraries, linux provides a choice of which core set you want to use.
Both operating systems (unlike you) understand the importance of using dynamic libraries to save disk space.
If every file on your mac was statically compiled, we would be talking gigabytes, not megabytes.
I also find it totally hilarious how Linux users are now advocating a completely centralized model of software distribution. Freedom of choice! As long as you only ever choose things approved by your distro maker!
You only find it totally hilarious because you fail to understand the difference between making it convenient for users to use software from a central source and forcing users to use software from a central source.
My pics.
Screw the disk space. It uses up much more RAM than a shared-library solution.
My blog. Good stuff (when I remember to update it). Read it.
And lets not forget having to upgrade every application when there's a bug or vulnerability in the library they all duplicate.
How bloated must that be?
Seriously, how many copies of a library does that leave you having installed?
Generally? One.
Remember, this isn't a Linux distro, where the user has all the choices in the world except the one that matters most: the choice to have all of their apps look and behave in a consistent manner. 99.99999% of all apps targeting OS X link against the standard system Carbon or Cocoa frameworks. The odd app might have a really large third party library linked in and included in the app bundle, but that tends to be the exception rather than the rule, as the bundled libraries tend to be of the small, utility type that only run a few K. How bloated is it? Not very at all.
Now compare that with the situation on your average Linux distro: Instead of one version of one or two frameworks, every third app is written against a different toolkit. Want GIMP? Install GTK. KDevelop? Need QT too. Your text editor links against the athena toolkit, your system management utilities against Tk, your games against SDL, your audio editor against WxWidgets, your file manager against GNOME, something else against FLTK, FOX, Lesstif, Xaw...your shared libraries folder reads like an explosion at the acronym factory. Repeat ad naseum for your XML parsing libraries, your regex libraries, your sound libraries, etc, etc.
And it doesn't end there. Binary compatibility between library releases is the exception rather than the rule. Every third GTK app requires that a different point revision of the GTK libraries be installed. XMMS requires that you install libraries that are several major revisions out of date. You've got 6 different versions of three different XML parsing libraries installed, 2 regex engines, 3 copies of your JPEG, PNG, etc libraries, 3 or 4 different audio libraries with a couple different versions installed. Multiple versions of multiple libraries; an endless proliferation of crap that all does the same job with only the most miniscule of differences. All for the sake of an illusion of "choice" foisted on the end user by a fractious developer base with a raging case of Not Invented Here Syndrome and a belief that their convenience is more important than a consistent experience for the end user.
Now, how bloated must that be?
Despite all the boring back-and-forth between the supporters and detractors of defining a new plural word meaning computer virii (as opposed to biological viruses) you have just made the first intelligent comment that wasn't annoyingly longwinded pedantry.
And furthermore.... oh, shit!
I don't believe you!
the system virtually hangs for 45 seconds until the connection times out
You mean Finder.app hangs.
You can continue surfing, typing or doing any number of other things you might have going in other apps while waiting for the Finder to come back.
Or why not just relaunch the Finder? Simple, painless, no hang, back in 5-7 seconds. Yes, it's an issue that needs to be fixed, but it's not that big a deal.