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."
When FORCE QUIT doesn't work, 120V A/C to the processor does the trick every time.
Universal Binaries, The Dynamic Linker, Using otool? pah!
Never underestimate the power of stupid people in large groups.
Do you mean big "O" tool?
With extreme prejudice?
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.
Oh dear, does Linux practice this awful act as well? I'm an opponent of capital punishment, so it's now clear to me that I can't, in all conscience, use a Mac or Linux. No application, however detestable a crime it may be accused of, should ever face what is no more than state-sanctioned murder!
My question to Slashdot, therefore, is what operating system should I choose?
I've heard good things about FreeBSD's jails, which are apparently very secure without being inhumane. But on the other hand, Windows also has some advantages - I understand it opposes the death penalty so strongly that that it's been known to commit suicide in protest when a user attempts to execute too many applications?
Bastards.
And wormii! Don't forget wormii.
One of the lessons of history is that nothing is often a good thing to do and always a clever thing to say. - Will Duran
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.
A lot of that has to do not only with Mach, but simply with the fact that up until recently, a lot of OSX applications (specifically, those built on Carbon) were not multithreaded. In other words, if one bit of the application hangs or times out, the application and everything that depends on it goes to hell.
This is why BeOS appeared to be lightning fast on even slow machines. Even the smallest tasks were executed independently, and bottlenecks were hardly noticiable.
Apple's doing a good job making everything work, and Cocoa is definitely a step in the right direction, but apple really needs to kill all of the single-threaded applications they've got now. The Finder is the most prolific and outrageous example of this, and anybody who's ever lost a network connection while a network share was mounted knows what I'm talking about (the system virtually hangs for 45 seconds until the connection times out. awful. simply awful)
Otherwise, I love OSX.
-- If you try to fail and succeed, which have you done? - Uli's moose
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!
I didn't know it was a big secret.
Kiteboarding Gear Mention slashdot and get 10% off!
No, the post you were responding to phrased it poorly.
What is inherent in a MacOS X version (say, 10.4.5) already covers most of what an application might need, including Apple's "equivalent" of gtk. Go browse the Apple Developer docs sometime, and you'll see a much richer set of libraries that come with the OS by default. Thus, if an application wants an "obscure" library and decides to bundle it, the cost to the system is minimal even if another app has the same one. The MacOS bundle is not at all the equivalent of statically linking against gtk and other "fundamental" libraries in Linux.
On the Mac you have scour the web deciding Free or Paid, [...] Once you've downloaded it, things are pretty sweet, but finding the download can be a PITA.
Have you ever heard of versiontracker?
On the linux box (I am going to choose Debian as I'm familiar with it). Fire up synaptic from the gnome menu. Search for barcode. Two results returned. Both of these programs I know to be free of trojans, compatable with my system & configured for it. To install, I double click.
Which can bring in new versions of a library, which in turn brings in new versions of another application, which may be broken in some way (like any app can be). In other words, installing one app in Linux can effectively break another one. You pay for the isolation available to MacOS X apps in the form of disk space and RAM, both of which can be relatively cheap depending on what you're doing with your computer.
The architecture does support Universal Binaries, which have code for both PPC and intel processors. This isn't really anything new or magical, the OS is just smart enough to know which code to execute. The same thing existed in the classic MacOS to support both PPC and 680x0 systems with FAT binaries.
As with the classic MacOS, there's also an emulator involved, so the newer architecture can run (most) binaries compiled on the older architecture.
However, compile something just for the Intel processors, and it won't run on your PPC hardware. If I understand your question correctly, if things worked the way you were assuming, Mach-O itself would guarantee any Mach-O binary would run on either system.
Don't blame me; I'm never given mod points.
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?
Hopefully you won't need to wait too much longer. As reported on Mac Rumors , as of at least Jan. 26, Apple has been seeking a "Finder Software Engineer". Hopefully we can see a better Finder out in Leopard.
The job requirements were listed as
I don't believe you!