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."
yea, you got to love that mach kernel http://sekhon.berkeley.edu/macosx/and how slow it is
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 is because of specific decisions they made, but anything that fork()s a lot will run slower than on the same computer running Linux.
My only suggestion to you would be... are you running the Dashboard? As interesting as it is, I avoid it because it is a resource HOG like nothing else on the system. If you google around you can even find a way to completely disable it.
In general it is a very responsive system. The only time I can consistently cause a beachball is copying files (digital pictures) off of a CF card. This uses enough kernel time that the computer does seem to stop responding for tiny fractions of a second (and my CPU usage goes WAY up). I don't know what the computer is doing, but it has got to be able to do it faster. My theory? Hard coded uninterruptible sleep statements for timing purposes. Just a random guess though.
All that said, I regularly use a 2.3 GHz Windows laptop and I am constantly amazed at how long it seems to take some applications to launch, and how different it is. IE will come up almost instantly most times. But sometimes it takes 30 seconds to launch and show the page (then feels slow after that). Other apps can do the same thing sometimes. But most applications (IE is preloaded by the OS) take just as long as on my Mac, if not longer.
Comment forecast: Bits of genius surrounded by a sea of mediocrity.
When will we get drag and drop app install for Linux?
When it's a better solution. I use a Gentoo workstation and an OS X laptop. I prefer Gentoo.
You mention dependency handling as if it's a bad thing. Why? 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. When I try and install something on Gentoo that doesn't have the required dependencies, it installs them for me.
I seem to remember having one-click install of RPMs back in the 90s with Mandrake and Redhat, where it worked identically to what Mac OS X has now when there are no dependencies. Isn't that what happens now? What happens when you click on an RPM these days?
Have you seen Klik? Seems to me that requires even less work.
Close, but not quite the same thing. GoboLinux apps are not relocatable, for isntance. The great thing about OSX apps (and other real appdir implimentations) is that they can be installed in the users home directory, on their desktop, on a network folder, on a disc, or in any system shared folder just as easily as it can be installed in the official "Applications" folder.
Actually, the full grammar in the RFC is
So a hostname beginning with a digit is actually invalid by the RFC. Nobody actually uses that definition; it turns out it's fairly easy to distinguish a DNS name 127.0.0.com from an IP string 127.0.0.1 in other ways.
We're talking about applications here. On Mac OS X, a properly packaged application lives in a .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
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 handling applications is nice and all, it's really more suited to a closed, vertically integrated framework, whilst linux's method is more suited to an open, looser framework. (where all apps can share libraries, rather then each having their own copy of a library)
Additionally - linux apps are not harder to install. Imagine you're working in a small business, you need an application to print barcodes.
On the Mac you have scour the web deciding Free or Paid, can I trust this site? Am I downloading a trojan. Oh, this is windows only, but says I can run it using VPC. Will it work on my new macbook under rosetta? Once you've downloaded it, things are pretty sweet, but finding the download can be a PITA.
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.
Now - its easier for a binary-only software maker to distribute to Macs, but thats a different discussion.
My pics.
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.
Sorry, that's not the equivalent. Not even close.
A Government Is a Body of People, Usually Notably Ungoverned
Yeah, I realized that after I posted. What Rosetta doesn't support, and what I meant to say, was that Rosetta doesn't support certain G5-specific features. My bad.
If it's not one thing it's your mother.