Time to learn. How and Why, Tim?
On the Mac, it requires a plist setting to disable the dock icon and such. The main advantage of a headless GUI app is you can display GUI elements if you wish.
For instance you could provide a floating progress window.
The app.daemonize() works?
When I launch it from via shell() can I capture and handle the stdout?
Does it run on the Linux server edition as it does not have a GUI framework present?
The StdIn/StdOut/StdErr global methods are not available in GUI apps, so no. You’d need to acquire the handles yourself via declares (at least on Win32, IDK how OS X/Linux handles this.)
Why would it need to?
No. You can use other means of communication, like IPC.
I see the main advantages as
- the helper app can use all the graphics classes (used to be a bigger issue, but console apps are still a little limited graphics-wise)
- the helper app can pop up alerts (msgbox) or even open a window if need be (I have a helper app that sends email and displays a progress indicator. It frees up the main app while still giving life signs and an error message if something goes wrong.)
- you don’t need a separate license for console
Why you need console apps? Usually to write server apps. Start server, in it’s initialization it runs your servers processes, daemons (or services). As far as I know the Xojo way to pass the app to the OS as a service is daemonize()
Now I believe I understand your POV. No, I wasn’t thinking on helper apps, I was thinking on server apps.
To be true, I hate “helper” apps. The only time I remember writing one was in the 80’s due to memory limits where the solution was spawning programs on multiple banks of 64kb of memory (preemptive multitasking with bank switching). 
[quote=39062:@Rick Araujo]Why you need console apps? Usually to write server apps. Start server, in it’s initialization it runs your servers processes, daemons (or services). As far as I know the Xojo way to pass the app to the OS as a service is daemonize()
[/quote]
If you don’t need to run as root (e.g. to serve ports under 1024), you can do just fine with a headless or headed desktop app running server code on all three platforms. One advantage is that regular people might be able to start and configure your server if you have a nice GUI.
Unattended? On the server start up? I believe that only daemonized apps will survive there.
Look, if you need a console app, spring for the license. Judging from all the activity around here discussing console-specific issues (sarcasm), they probably didn’t have many taking them up on that offer and the new pricing makes the “Pro” package look like a better value.
What I was trying to say is if you want to write some kind of server, i.e. software that listens for connections on ports and interacts with clients once connected, there is nothing that mandates that such software run daemonized. Even if you want to serve on protected ports, you can create a root GUI login user or launch the GUI app from a command line with escalated privileges. Perhaps not textbook security, but workable enough if you really can’t spring for the $300.
I have the license. The discussion was merely technical trying to figure out if was missing something. And as always I learned a bit more, so the thread was valuable for me.
[quote=39073:@Rick Araujo]Now I believe I understand your POV. No, I wasn’t thinking on helper apps, I was thinking on server apps.
[/quote]
The statement that you quoted at the top of this thread was made in the context of helper apps. Nothing more.
Yes, I know. But my mind ignored the context that time and dived in “There are ways to substitute console apps and even get extra advantages”.