Case: Click a URL in the browser and a video game that is currently running on user's desktop can ingest that data and do something.
I've been working on this for some time, but I don't know if I'm on the right path.
What I currently have: A clickable URI in a webpage that can have different arguments for the client to recieve. The URI scheme is registered in Windows. When clicking URI in the browser it will launch a c console 'launcher' or 'bridge' app that is already installed on the user's PC. This 'launcher' is a middle-man that parses the URI arguments and communicates them to the main 'user' app (a video game) via IPC named pipes.
How do I: In terms of UX, make the whole process discrete and seamless?
Specifically, I need to: Keep launcher hidden from the user - no pop-up. Needs to be only capable of running a single instance, even when invoked with new URI parameters. Do I just exit the current and create a new one? User can click another URI in the webpage and the launcher will process the new arguments without displaying itself to the user.
Tech constraints: Windows. Preferably needs to be C . C# could be a possibility.
Existing example: Zoom conferencing software appears to works similar to this. Clicking a URL in the browser launches a 'launcher' which starts the main app to video conference. Closing that 'launcher' will minimize it into the system tray. Clicking on a new link while the launcher is running does not start a new launcher, but it does start a new meeting.
How does something like this normally work?
CodePudding user response：
The OS automatically creates a console for /SUBSYSTEM:CONSOLE apps. It doesn't automatically create a window for /SUBSYSTEM:WINDOWS. So use /SUBSYSTEM:WINDOWS.
Then, create the named pipe before creating the main window.
If the return code tells you a new pipe was created (use
FILE_FLAG_FIRST_PIPE_INSTANCE), you're the primary instance, create main window and run normally, with an OVERLAPPED read on the named pipe to receive data from future invocations.If instead you opened an existing named pipe, write your command line through the named pipe and exit without ever creating a window.
You don't need a separate launcher at all, and actually separating the launcher from the main application creates a race condition (a second launcher starts before the first instance managed to launch the main program / before the main program is up and running, doesn't see an existing named pipe, and thinks it is the primary copy). You are better off putting both sides of the argument-forwarding logic into the main executable.