Hacker News Reader

Comment by jiggy2011 | Hacker News Reader

jiggy2011

Not familiar with the OSX installation procedure, but I assume that dragging the app into the folder runs some installer script? Are there perhaps restrictions on what can be done via these scripts that would require 2 distinct actions to install say a browser toolbar and application?

View on HN

Most OS X applications are usually a folder that behaves like an executable (has a custom icon, will run the app when you double click on it). So no, it's not running an installer script, it's just copying a folder, and the app runs with just what's in the folder, no install process needed.

For things that require changing system components, other apps etc. there is a normal install wizard.

The cool thing about Mac applications is they are self contained. Very rarely do you see an actual installer. Uninstallation is usually just deleting the application from the Applications folder.

I wish other operating systems did it that way. It's very convenient.

It isn't. Since every library the application needs is inside the bundle, you load multiple versions of the same lib on memory. Also counting the installer, the bundle and Brew or MacPorts you have a tons of way to install an app.

Well, if I'm not mistaken, Windows linking usually involves re-calculating offsets in the library code, so several versions of libraries are kept in Windows too. The only thing that is theoretically saved is disk space.

Not every. The ones that are distributed with the OS X base install usually are dynamically linked against.

My current project I'm working on links against the standard Cocoa frameworks, zlib, Core Audio, Audio Unit framework and the Accelerate framework. Yet the Frameworks directory in the app bundle is empty.

How often do you really have multiple third-party apps using multiple copies of the same third-party framework? How many third-party frameworks maintain binary compatibility between versions so that apps linked against different versions could still share a single installation of it?

The problem is it leads apps to include their own copies of libraries - which then get out of date and have bugs. I remember when a vulnerability was found in zlib and just to update all of apple's first-party programs with the fix required something like 2.6gb of updates. I wouldn't be at all surprised if there were still some more obscure third party mac programs shipping the old, vulnerable version.

Well the alternative (dynamic loaded libraries) have their issues as well. After "DLL hell" and various issues on Linux in the past, I'm not convinced one side is fundamentally better than the other. 3 gig is nothing these days.

MS-DOS did it, but on those days things were a lot simpler.

No, no setup scripts are run, you are just copying a folder inside /Applications. All setup an application needs (typically creating configuration folders and associating mimetypes) should be done the first time the application is launched.

Dragging an app into /Applications does just that: it copies a directory (hidden with an .app extension) that contains resources and executable. No script.

Some apps however come with an installer, but that's for apps that do more (e.g. need to install drivers, etc.). However, it's Apple's own installer which I think is provided by Xcode. So, no way to mess with it and install crappy things.

You can run arbitrary scripts in the installer, so you can install anything you want.

You can even (if you are iTunes 2.0, or a hater) delete the user's entire home directory!

Nope, no installer script. If a program needs installer script (to install drivers etc.), you get a package installer (like on Windows), however, they are rather rare and I've never seen any crapware in those so far.

No, it's just copying the bundle.

Reply on news.ycombinator.com