app-bundle vs. regular/"BSD utility" executables : what differences are there still?

[Jeremy Huddleston Sequoia]

There are really two main difference between the two cases:
  1) The app bundles have an inherent main bundle (ie: [NSBundle mainBundle]).
  2) Apps are (usually) launched by LaunchServices.  You can exec them directly, but that is not the preferred way to do it (and may not always work in the future).

It's certainly possible for processes to draw GUI elements without being bundled, but it's less trivial.

It's possible for a standalone executable to have an Info.plist.  It is embedded in the executable in an __info_plist section.  This can be done by the CREATE_INFOPLIST_SECTION_IN_BINARY Xcode build setting or by creating an __info_plist section manually at link time if not using Xcode (-Wl,-sectcreate,__TEXT,__info_plist,/path/to/my/Info.plist).

As far as spawning processes in general, please don't use system() or fork()/exec().  Please use the posix_spawn syscall instead as it is much cleaner and has less overhead.

The open utility is basically a CLI to LSOpenURLsWithRole().  It does not exec or spawn anything.  It just calls into LSOpenURLsWithRole().

> On Jan 5, 2016, at 02:58, René J.V. Bertin <rjvbertin at gmail.com> wrote:
> 
> Hi,
> 
> This is a rather technical question that in itself is only indirectly related to MacPorts:
> 
> What are the current differences in terms of what applications can or cannot do if they're built as traditional executable files ("BSD Utilities" in Apple speak) vs. as/in an app bundle?
> From what I remember, it used to be pretty clear-cut: any application wanting to put up a usable GUI basically had to be built as an app bundle ... unless you were called Adobe Illustrator (or comparable) in which case you could be built like a PEF executable or something of the sort.
> 
> Evidently a "BSD Utility" cannot have an Info.plist, but there are ways to set up that Info Dictionary programmatically (I've been doing that with the LSUIElement flag in numerous Qt/KDE daemons). Other than that, I'm not noticing any difference in the behaviour of applications built either the one or the other way, at least not when I launch them from a terminal or fork()/exec() .
> 
> I'm asking in the context of designing a cross-platform "launch-a-process" function which provides the most natural opening behaviour of the started application. In particular, something that does not cause the new application to open its windows behind those of the current process, so unlike what happens when you use system() or fork()/exec() to start an application on OS X (instead of LaunchServices).
> 
> From what I can tell, one needs to use LaunchServices in order to start an application "A" the way it would start from the Finder, i.e. in the front layer unless you bring another application to the front after starting application "A".
> 
> However, LaunchServices will not launch all applications directly; it certainly uses Terminal.app as a delegate when starting a shell script. I am less sure about GUI applications built as BSD utilities; I have the impression that the "open" command will usually launch those directly ... but then again that command probably doesn't use LaunchServices in its most basic form.
> This is probably the main question I'm looking to see answered: when/how can I use LaunchServices so it doesn't use a delegate application like Terminal.app ?
> 
> A related question: I've managed to write an AppleScript that brings a started application to the foreground from the calling application, using the "System Events" library. What SDK would I be looking for to see if I can do the same without using AppleScript?
> 
> Thanks,
> René

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4109 bytes
Desc: not available
URL: <https://lists.macosforge.org/pipermail/macports-users/attachments/20160105/784c40c9/attachment.p7s>