How can I retain the stdio channels when using a RunAs command line helper?

Because of so not so elegant distinctions between user tasks and RunAs Administrator tasks on Windows, I have an issue that I haven’t found an answer to, and the MS Developer forums are as helpful as …

If the user runs my full application as Administrator, they completely lose drag and drop because of the way MS disconnects the RunAs process from the current user’s environment. If the application is run as the user, and I use task elevation on my back end helpers, there is no communication between my application and the backend helper such that updating state is not possible.

Does anyone know of a method that would reconnect the elevated process’ stdio channels to the user space application?

Of course, declares and MBS options are quite welcome :slight_smile:

My main app runs as the user, and when I need elevation, I start a helper app (which in my case is just a second instance of my app) using ShellExecuteEX with the “runas” verb to get elevation.

I pass the helper app a string (which is the socket name) either on the command line or in an environment variable, and the two apps communicate using Xojo IPCSockets to exchange messages.

It’s a pain, but works.

I’d thought of that, but it’s so alien from the app’s implementation on macOS and Linux that I’d need to refactor a very large segment of the code.

I’m still trying to get MS to realize that the lockdown of the robot is dumb since the tape drive itself is wide open for a user in the “Backup Operators” group. The tape drive is where the security should be occurring, not in the thing that changes the tapes …