How OS X Executes Applications 315
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."
How I execute applications :) (Score:5, Funny)
Re:How I execute applications :) (Score:2)
Re:How I execute applications :) (Score:2)
Re:How I execute applications :) (Score:2, Funny)
Re:How I execute applications :) (Score:2)
>
> A/C is amps per coulomb. Since an amp is a coulomb per second, the parent is clearly refering to the frequency.
>
Does anyone remember "Running Scared" with Billy Crystal and What's His Name? " It's not the volts. It's the amps."
Re:How I execute applications :) (Score:2)
In high school I asked my physics teacher to explain how you can get more amps running through your body, assuming you're not changing your resistance, without increasing the voltage. Ah, the cognitive dissonance created by realizing that either you don't know what the formula you're asking your students to memorize actually means, or that some quote you heard from somewhere might not be scientifically rigorous.
Re: (Score:3, Insightful)
Re:How I execute applications :) (Score:2)
How it launches? (Score:3, Funny)
Universal Binaries, The Dynamic Linker, Using otool? pah!
Re:How it launches? (Score:2, Insightful)
"Using otool" (Score:5, Funny)
Re:"Using otool" (Score:2)
Ooh, I know this one! (Score:5, Funny)
"0xFE - 1111110b - 0376" (Score:2, Insightful)
Re:"0xFE - 1111110b - 0376" (Score:2)
Decent article (Score:3, Interesting)
I'm fairly new to OS X, and don't know much of the internals and I have no clue on developing via Xcode or a lick about Objective-C.
The otool command is new to me. Its handy because I too was getting "No such file or directory" with trying to use ldd. One thing this article does not mention is weather OS X calls mmap() on an executable and/or libraries? It probably does. I believe all modern OSes do this now, but I could be wrong.
Re:Decent article (Score:2)
-matthew
If you like otool (Score:2)
are osx binaries cross-architecture? (Score:3, Interesting)
I have a friend who just got a new intel mac laptop. There are a lot of programs which won't run correctly because they don't fully support the intel architecture. However, I know from my linux experience that if I compile something for ppc, and then something for x86, neither executable will even LOAD on the other architecture, let alone execute with any functionality. When I download things for this new mac, I never select anything that is intel specific, and programs like oggdrop and vlc seem to work just fine.
Is this some magic that the program is doing? Or is it on the system level? Or am I missing something obvious about macs?
Re:are osx binaries cross-architecture? (Score:2)
As a previous poster mentioned, PPC executables run through an emulation layer called "Rosetta". However, Mac OS X binaries are stored in the Mach-O format. A Mach-O file can be divided into multiple segments, each of which can contain machine code for a different architecture. So, Universal applications really do include equivalent code for both PPC and x86. It's not really magic so much as it is that the loader knows to look for non-native code in a binary and run it through Rosetta if no x86 code exi
Re:are osx binaries cross-architecture? (Score:3, Informative)
Re:are osx binaries cross-architecture? (Score:5, Informative)
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.
Re:boo! (Score:2)
I think thats what Ubuntu is.. or kubuntu or edubuntu or something like that.
Re:boo! (Score:2)
thats what ubuntu is
Re:Obligitory... (Score:2, Informative)
That said, I seem to remember (and personal experience seems to bear this out) that OS X is really slow executing a fork() system call relative to Linux. I'm not sure if this is has to do with using a microkernel, or
Re:Obligitory... (Score:3, Interesting)
Re:Obligitory... (Score:2)
It's you and anyone else who has a 800Mhz PPC. (I've got a flowerpod iMac myself and it is a dog)
If I you happen to have a Intel or a 2ghz G5 then its not as much as a problem.
Even my PPC 1.5Ghz mini isn't as bad as the earlier systems.
Re:Obligitory... (Score:2)
Turn off swapping! (OT) (Score:2, Offtopic)
This might not be so important in your (and possible, in most) case[s]. The server's I run I admin remotely. A runaway script can eat through the swap, slowing things to such a halt that logging in, finding the process, and killing it,
Re:Turn off swapping! (OT) (Score:2)
Re:Turn off swapping! (OT) (Score:2)
Re:Turn off swapping! (OT) (Score:2)
Re:Obligitory... (Score:2)
Re:Obligitory... (Score:2)
-matthew
Re:Obligitory... (Score:2)
Re:Obligitory... (Score:2)
Re:Obligitory... (Score:2)
I refuse to run any X11 applications under OS X unless I absolutely have to. It kinda ruins who whole OS X experience. And OO.o in particular is a bloated pig. I won't run it on Linux either.
-matthew
Re:Obligitory... (Score:2)
"that it does in the background isn't helping me check my email, instant message or ssh to remote boxes."
Call me crazy, but I dont think everything linux does is helping you do those things either:
[4294669.546000] Checking for popad bug... OK.
POPAD BUG? WTF THAT IS NOT EMAIL/BROWSING/IM/SSH!!!! STOP WASTING MY MEGAHURTSZ!!!
Re:Obligitory... (Score:2)
At least the GP has used the operating system he's talking about....
Re:Obligitory... (Score:2)
YOU CANT DO THAT ON TELEVISION!!!!
Re:Obligitory... (Score:2)
Big deal - you can install KDE on OS X [finkproject.org] - but I wouldn't point out something in KDE as a problem with OS X as it's not the primary UI.
Re:Obligitory flamebait (Score:2)
not the primary, KDE it's the ONLY UI!
Re:Obligitory... (Score:2, Insightful)
Go
Re:Obligitory... (Score:2)
Unless you're using it as a moderately trafficked server
Re:Obligitory... (Score:2)
Re:Obligitory... (Score:2)
-matthew
Re:Obligitory... (Score:5, Interesting)
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.
Re:Obligitory... (Score:2)
Other than fixing problems with hangs due to network drives, like you mention, one thing I would really like to see in a new Finder is better Spotlight integration. I'd like to be able to view, edit, and organize by metadata. From what I've read, it seems like Windows Vista will do most of the things I'd like to see from Finder in this regard. Since OS X 10.4 alread
Re:Obligitory... (Score:4, Interesting)
Hopefully you won't need to wait too much longer. As reported on Mac Rumors [macrumors.com], 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
Re:Obligitory... (Score:2)
I think Apple intends it as a learning tool for programmers who think that multi-threading is some sort of panacea. "Look, developer! If you choose what to run in a separate thread really badly, you'll end up with a crappy application like this one!"
I don't see it being fixed any time soon. NeXTStep had the same sort of problems 15 years
Re:Obligitory... (Score:2)
Camino launches in 4 bounces (13 the first time after a reboot). Neither takes more than a couple of seconds.
It might be worth giving your Mac a good old house clean (delete caches, repair permissions, check the disks - all the usual stuff).
And no, your comment isn't flamebait, as far as I can see.
Re:Obligitory... (Score:2)
But for him, I'm guessing his iBook doesn't have a good enough graphics chip, so his CPU is doing all that compositing... which would really slow things down during an app launch.
Interesting point!
Re:Obligitory... (Score:2)
And also, just so no one is confused, I love my iBook, and OS X *is* my second favorite Desktop OS, but there's just a huge gap in speed on my setup. Still, I am foaming at the mouth (well maybe not really, but...) at the prospect of a new Intel iBook, and have already spec'd out a local store where I can trade in my old 800Mhz (along
Re:Obligitory... (Score:2)
Re:0xFE (Score:3, Insightful)
Re:0xFE (Score:4, Funny)
Re:0xFE (Score:2)
According to RFC 1034:
Please read what is written a few lines above: "The following syntax will result in fewer problems with many applications that use domain names (e.g., mail, TELNET)."
I have some code to fix if "someone@0xfe.blogspot.com" could be a valid address...
Time to fix some code then ;-)
Re:0xFE (Score:2, Informative)
Actually, the full grammar in the RFC is
Re:0xFE (Score:2, Interesting)
In old-school records management, 3Com is filed under "T", and 3M is filed under "M" (The name of the company is "Minnesota Mining and Minerals".
Re:Kinda OT.. yet relevant to this thread (Score:2)
Re:Kinda OT.. yet relevant to this thread (Score:2)
Re:Kinda OT.. yet relevant to this thread (Score:2)
apt-get update if you have installed the Fink [sourceforge.net] package management system.
For normal Mac apps, either an installer will do the upgrade, or simpler, a drag and drop of a new version to the location of the old version to replace the old one.
Re:Kinda OT.. yet relevant to this thread (Score:2)
Google for DarwinPorts for more info.
Re:Kinda OT.. yet relevant to this thread (Score:2)
You're preaching to the choir here. I think the package management apps on Linux and OS X have a piece of the puzzle. It would be great to see Linux distros standardize on a GNUStep or OpenStep implementation that integrates with any number of custom software repositories and includes the ability to do updates. It would be great to have a single package for Linux and OS X for those of us who realize our executables only take up about 2% of our disk space. Drag and drop on Linux would be great. Nicely consol
Re:Kinda OT.. yet relevant to this thread (Score:2)
Anychance this would make it's way to mainstream distros like Ubuntu?
Re:Kinda OT.. yet relevant to this thread (Score:2, Informative)
Re:Kinda OT.. yet relevant to this thread (Score:3, Interesting)
Mac OS has let you move apps anywhere before the concept of an "Applications Folder" even existed. (I don't think Apple added one in until Mac OS 7... or maybe even 8.) Used to be you'd put your common applications on the root level of the drive and then make a Utilities folder for the other stuff. At least I did. But really, the whole filesystem was a playground and you could put stuff where you want.
Now OS X lets you put application
Re:Kinda OT.. yet relevant to this thread (Score:5, Insightful)
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.
Re:Kinda OT.. yet relevant to this thread (Score:3, Informative)
So - you install a version of the gimp - you get a copy of gtk, install eog - you get a copy of gtk, install.... well I think you get my point.
While the Apple way of handli
Re:Kinda OT.. yet relevant to this thread (Score:3, Insightful)
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!
Re:Kinda OT.. yet relevant to this thread (Score:2)
Re:Kinda OT.. yet relevant to this thread (Score:3, Insightful)
*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
Re:Kinda OT.. yet relevant to this thread (Score:3, Insightful)
Re:Kinda OT.. yet relevant to this thread (Score:2)
So - you install a version of the gimp - you get a copy of gtk, install eog - you get a copy of gtk, install.... well I think you get my point.
Even worse. A security vulnerability is found in gtk. How many different apps do you have to upgrade? Bonus points for realizing that Apple won't let any 3rd party software use Software Update.
Re:Kinda OT.. yet relevant to this thread (Score:5, Informative)
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.
Re:Kinda OT.. yet relevant to this thread (Score:2)
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.
Even though the post I was responding to was phrased poorly, I understood - I was talking about wanting to use something not in the OS X core libraries.
Have you ever heard of versiontracker?
*puts small business owner hat on*
No.
Which can bring in new versions of a library, which in turn brings in new versions of
Re:Kinda OT.. yet relevant to this thread (Score:5, Insightful)
I don't believe you!
Re:Kinda OT.. yet relevant to this thread (Score:2)
Right. If you want to install the exact same apps on Mac OS X as you want to do on your Linux boxen, you can choose between the Debian apt-get package management system Fink [sourceforge.net] or the FreeBSD Port [opendarwin.org] package management system. They even have GUI frontends if you choose in .app directories that you can move wherever you want on the filesystem. Pretty simple, eh? ;-)
OS X Frameworks too. (Score:2)
I only wish that Apple and 3rd party developers were as logical when they put stuff in ~/Library. There's folders for Application Support, Caches, and P
Re:Kinda OT.. yet relevant to this thread (Score:2)
OS X has it a lot easier, since anyone writing an O
Re:Kinda OT.. yet relevant to this thread (Score:2)
How bloated must that be?
Seriously, how many copies of a library does that leave you having installed?
Re:Kinda OT.. yet relevant to this thread (Score:2)
Yeah, let's talk about bloat... (Score:4, Insightful)
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?
Re:Kinda OT.. yet relevant to this thread (Score:2)
Really, who cares if there are multiple versions installed?
If there is a security vulnerability, do you want to track down all the appropriate files and patch them?
Re:Kinda OT.. yet relevant to this thread (Score:2)
I don't care about it directly. I care about the performance implications.
Think of the library version problem: we need to get developers at disparate locations and levels of time commitment all to update to a specific level of library?
No you don't. If there's a change big enough to break compatibility, you bump the major version number, and users keep both versions installed until all their apps are using the new one. It's not rocket science.
Re:Kinda OT.. yet relevant to this thread (Score:2)
Point, but it's still going to be a problem when they're loaded into memory.
b) at least you don't have to worry about needing two vastly different versions of some library or other installed. ie App A needs neatLib 2.0 and App B needs neatLib 3.0b10. What if the two versions won't co-exist with each other?
That's why you have versioning, foo.so.2 and foo.so.3 or similar (I appreciate gnu ld is not very goo
Re:Kinda OT.. yet relevant to this thread (Score:2)
On OS X, developers can easily distribute their apps directly to users with no middlemen in the way.
Re:Kinda OT.. yet relevant to this thread (Score:3, Insightful)
Re:I don't have a Mac (Score:5, Funny)
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?
Re:What this means (Score:5, Funny)
And wormii! Don't forget wormii.
Re:What this means (Score:5, Insightful)
Re:What this means (Score:2)
Re:What this means (Score:2)
Reference in the first 3 hits.
Re:What this means (Score:3, Funny)
Re:What this means (Score:2)
It is documented (Score:2)
Mac OS X ABI Mach-O File Format Reference
Executing Mach-O Files
Overview of Dynamic Libraries
Re:Interesting, but why? (Score:5, Informative)
Re:Interesting, but why? (Score:2)
Certainly. That's why there are documents such as this one [apple.com].
Re:Interesting, but why? (Score:2)
Re:How OSX Executes Applications... (Score:2)