bug#19688: [patch] add support for emacs daemon on Windows

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sun, 15 Feb 2015 01:34:48 +0900
> From: Mark Laws <mdl@60hz.org>
> Cc: 19688@debbugs.gnu.org
> 
> I gave it a try, but it doesn't work--most likely because, as you
> said, Emacs is built as a console application, so WaitForInputIdle
> simply returns immediately because of the race between emacsclient
> attempting to wait on Emacs and Emacs establishing a Windows message
> queue.

No, I think it returns immediately, period.  As I wrote, when Emacs
establishes the input queue, it's already way past the daemon
initialization.

> So, the options are either using an event or modifying Emacs to
> run under the Windows subsystem--I don't think I need to tell you
> which one is the less invasive change. :)

The latter is not invasive, it simply cannot be done without losing
some very valuable features.  So it's out of the question.

Back to the event-based method: is using a named event with a fixed
name workable?  That is, is a situation imaginable where we would need
more than one event at the same time on the same system?

If a single event is enough, I think a named event with a name
specific to Emacs (but not a GUID) is a better alternative.
Otherwise, we will have to pass the handle via the command line; using
the environment is not an idea I like, because it means complications:
possible conflict with other variables, possible overflow of the 32K
limit on environment variables, possible conflicts in nested
invocations, etc.