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."
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.
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
For the record (insofar as slashdot records things), the Finder is multithreaded; you can, as a matter of fact, copy two files at the same time, or format a disk while doing something else, and all those stupid things Macs were accused of being incapable of.
BUT, the Finder right now does block when it tries to access network resources, which everybody hates passionately, but blocking behavior is not the same as being "single-threaded".
>3com.com and 3m.com are technically invalid...
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".
-fb Everything not expressly forbidden is now mandatory.
Does this executable format have anything to do with the binaries being able to execute on both ppc and intel machines?
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?
6th Street Radio @ddombrowsky
Up until about 4 weeks ago I was using a 400MHz "Sawtooth" G4 with 768MB RAM and the stock 32MB video card as my main machine, running 10.4 with all the latest updates, new version of iLife, etc. I really didn't think it was that bad, and in fact when I upgraded to my new machine (a dual 2GHz G5), I was actually surprised that the UI "speed feel" didn't change all that much. Opening applications and windows are noticeably faster, but the difference wasn't as dramatically night and day as some previous upgrades I've made. This is not a criticism of the new machine as much as I think it's a credit to how well OS X performs on older hardware, at undemanding tasks. Sure, that machine was an absolute horror if you wanted to transcode a few hours of MPEG-2 video (might as well just let it run overnight), but for day-to-day stuff it really wasn't bad. I think in some ways, OS X gets a bad rap for being a resource hog. There are definitely parts of it that are (Dashboard, etc.) but in general I don't think it is.
I have a Kubuntu system running on an HP workstation (Pentium 4 Prescott, 512MB RAM, NVidia NVS 200 Quadro), which if K/Ubunutu's reputation for running on older hardware was as good as people say it is, ought to fly. (In fact this was why I bought this machine in the first place -- I thought it ought to be smoking, for the very basic level of stuff I wanted to do with it.) However, I can bog the system down by dragging a large selection rectangle on the KDE desktop: it takes probably 3 or more seconds for the selection box to catch up with the cursor going from one corner of the screen to the other, and XOrg's processor utilization goes up into the 95-98% range. I was shocked the first time I did this. Is this a big deal? No, not really -- but it sure makes the machine feel slow. I accept that the Mac/PC thing isn't a scientific comparison because the hardware is different, but really I think the advantage ought to go to the PC here (3.2GHz P4 with a 64MB display card, versus a 400MHz Mac with an ancient 32MB one?), and it comes out feeling worse.
Anyway, I just wanted to agree with you; the seemingly accepted wisdom that Mac OS X is inferior to a Linux desktop on older hardware is something I have yet to see a whole lot of evidence for. One of these days maybe I'll load Kubuntu-PPC (or Ubuntu -- perhaps KDE is the problem) onto my iBook and see how it fares, but as of right now I'd say there are a lot of valid reasons to use a Linux desktop, but UI responsiveness isn't one of them.
"Ladies and gentlemen, my killbot features Lotus Notes and a machine gun. It is the finest available."
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
How can a process ignore SIGKILL? I am not a mac user, but if it is a true BSD system, the only thing SIGKILL does is detach the process from "init", at which point it does not exist anymore. Since it is not a true "multiprocess" OS (none are), it emulates it by dishing out a certain amount of clock cycles per time period to each process. SIGKILL makes it so that a process gets no more clock cycles. At least that is true on a normal *nix system. There is no way to ignore SIGKILL in a true *nix.
The reason Apple lets you is probably more historical than anything...
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 applications anywhere, but it's too goddamned stupid to figure it out. My Applications folder was messy, so I made categories... "Media Players," "Internet Apps," etc. The first time I ran Software Update, OS X decided to re-download ALL of the apps that come with it because it thought I deleted them. So the choice is have an organized Applications folder, or don't use Software Update... pain in ass!
Behind the Finder, Software Update is probably the stupidest application on OS X.
Comment of the year