Xpra: Ticket #830: win32 client GUI launcher opens extra cmd window

Windows client 0.15.0 r8892 against fedora 20 0.15.0 r8872 server.

When launching with the GUI, in addition to the start-children, I am seeing a windows style cmd window with no content (which sometimes flickers, maybe in time with server-side message output such as ** Message: pygobject_register_sinkfunc is deprecated (GstObject) - or maybe just coincidentally with similar timing).

Xpra info has no indication of a corresponding window (xpra info | grep window just gave info about my 2 xterm start child-ren).

The window will not take keyboard focus, but it can be minimized, closed, or re-sized at will.

Wed, 01 Apr 2015 21:15:53 GMT - alas: attachment set

apparent cmd window created on GUI connection, too re-sizable to be a "real" cmd window

Thu, 02 Apr 2015 00:58:03 GMT - Antoine Martin: owner changed

I'm pretty sure that's the sound process window. You can confirm this by running without sound. Can you include the full command lines you are using? Is this using one of my builds? And include -d util client side, which should log the command line used for the sound process. We have code to make sure we use the Xpra.exe for this subprocess rather than the Xpra_cmd.exe - this should ensure we don't get an extra shell window.

Thu, 02 Apr 2015 10:04:53 GMT - Antoine Martin: owner, status changed

And suddenly it hit me: I'm testing from a shell window already, and you're not.

Using the command version without a shell window is not enough, I think we also need to use the startupinfo flags as per Launching a subprocess without a console window (Python recipe). But when I try this approach (will attach patch), I get constant overruns and even crashes... oh win32, why do you need to be so flaky.

Thu, 02 Apr 2015 10:05:32 GMT - Antoine Martin: attachment set

tries to avoid showing the console window - causes more problems...

Thu, 02 Apr 2015 16:20:11 GMT - Antoine Martin: owner, status changed

Well, it seems that the overruns I am getting are not necessarily related to this patch. @afarr: can you try with r8902 which adds the XPRA_WIN32_SHOWWINDOW env var. (defaults to "0" which hides the console window, set it to "1" to restore the previous behaviour)

For the record, I've also tried setting XPRA_SOUND_EXECUTABLE=xpra.exe, but xpra.exe being a non-console application, it does not have stdin or stdout and so we can't communicate with it and nothing happens at all (note to self: I need to add a timeout for such cases).

Another problem that I have seen is that if I get too many overruns (making us kill the current sound process and start a new one), xpra will eventually crash... which is bad! (no idea why, win32 must be leaking something with each process)

Fri, 03 Apr 2015 00:45:55 GMT - alas: owner changed

Testing by launching with the GUI/icon with 0.15.0 r8904 against the same 0.15.0 r8872 fedora 20 server, I'm no longer getting any cmd window.

Launching with the airgap.exe from the command line with XPRA_WIN32_SHOWWINDOW=1 ... (xpra.exe attach tcp: ... I do indeed get the cmd window.

This looks fixed to me.

Sat, 04 Apr 2015 17:09:53 GMT - Antoine Martin: status changed; resolution set

Thanks for testing.

Sat, 23 Jan 2021 05:07:17 GMT - migration script:

this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/830