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 <[email protected]> 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é
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ macports-users mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-users
