On Thu, Dec 5, 2013 at 1:37 PM, GITNE gitne@gmx.de wrote:

nickm@torproject.org wrote:

...

commit b60049544143e8569e491dd30541d28127bfdb22 Author: David Fifield david@bamsoftware.com Date: Thu Dec 5 04:56:28 2013 +0000

Set CREATE_NO_WINDOW in tor_spawn_background.
    This flag prevents the creation of a console window popup on

Windows. We need it for pluggable transport executables--otherwise you get blank console windows when you launch the 3.x browser bundle with transports enabled.

http://msdn.microsoft.com/en-us/library/ms684863.aspx#CREATE_NO_WINDOW The browser bundles that used Vidalia used to set this flag when launching tor itself; it was apparently inherited by the pluggable transports launched by tor. In the 3.x bundles, tor is launched by some JavaScript code, which doesn't have the ability to set CREATE_NO_WINDOW. tor itself is now being compiled with the -mwindows option, so that it is a GUI application, not a console application, and doesn't show a console window in any case. This workaround doesn't work for pluggable transports, because they need to be able to write control messages to stdout. https://trac.torproject.org/projects/tor/ticket/9444#comment:30

Please note, that this is actually a specification problem. Tor's current PTE specification makes invalid or naive assumptions about IPC and the available methodologies thereof on Windows. The pluggable transport executables on Windows should be linked as UI applications too, not as console applications. If the PTEs need to talk to the user on the console, they should do so by detecting whether they were launched from a console, get a handle to it and in that case write to this console. However, they can write to stdout or stderr anytime they want, no matter whether they have been launched from console or any UI app. Hence, the changeset here does not fix anything substantially because Tor's PTE specification is flawed for Windows. Tor's PTE specification for Windows /must/ be revised.

IPC on Windows should either be done via clipboard, COM, data copy (WM_COPYDATA event), DDE, file mapping, mailslots, pipes, RPC, or Windows Sockets, not via console output or stdin/stdout/stderr. Please do not assume stdin, stdout, and stderr to be equivalent to POSIX pipes, simply because they are not pipes on Windows. The same applies to Windows pipes. They are similar to POSIX pipes but not equivalent, meaning they do not implement POSIX pipes' semantics.

Hi! Your message got bounced from tor-commits because that list only takes posts from people with commit permisions on our repositories. Maybe send it to tor-dev (which allows all subscribers to post), or use the bugtracker?

(As a side note, sure, I'm fine with revisions or extensions to the pluggable transport protocol for windows, but they probably won't be ones that windows programmers would like unless they are designed by a windows programmer.)

peace,