Thanks to David, Remy and Andy for comments. It helped me to step back and look at the issues from a fresh point-of-view. The solutions ended up being very simple.
Problem 1 - GUI Apps and "Session 0" Services Processes
A service cannot have UI elements or spawn a program that has UI elements. I thought this meant I couldn't use any GUI type controls, like TForm
or TWinControl
components. So I was trying to figure out how to launch a GUI program from a service (e.g., to the interactive desktop or by logging a user on and launching it to their desktop).
Turns out that as long as you don't have a dialog or some visual control that a user needs to interact with or respond to, it works perfectly fine to include GUI components in a service or an app the service spawns.
Problem 2 - "Control has no parent window"
I found one instance in my code where I created a control at runtime and didn't set its parent. Hard to track down, but fixed.
Problem 3 - External App only launched under "my" user profile
I set the service to Log On
three ways, 1) as Local System, 2) as my username/password, and 3) as another admin user's username/password (with identical rights as me).
In all three instances, the return code from within the service to launch the external app indicated it successfully launched the app. However, only when the service was set to Log On
using my username/password would the app actually run.
I found a information message in the system event log that said a BPL wasn't found for both of the other two instances. This was because I have a personal user path environment variable that includes an entry for the BPL directory. The other admin user and the Local System accounts do not have this. So of course the app failed to load the needed BPLs and therefore could not run.
Problem 4 - LocalSystem Access to File System
When we pushed the new code and modules to our production servers, the external app failed to properly launch and perform its task (but this time with no messages in the Windows event logs).
There are several parameters that the external app needs (too many to pass on the command line) so the service places all of the parameters into a uniquely named INI file and pass the name of the INI file to the external app. Once the external app finishes its task, it deletes the INI file.
As it turns out, the external app was launched using the Local System account, which didn't have access to the file system and therefore could not open/use the INI file. Once we granted the appropriate rights to the Local System account, it started working correctly in our production environment as well.
Everything works great now.