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

[Mark Laws]

On Mon, Jan 26, 2015 at 8:56 PM, Daniel Colascione <dancol@dancol.org> wrote:
> Inheriting an anonymous event feels a bit cleaner to me; you can provide
> the HANDLE value in an environment variable or a command line parameter.
> Failing that, the event name should at least contain "emacs" somewhere
> so as to not confuse people browsing named object directories.

It may seem cleaner in that the event doesn't leak into a shared
namespace, but it requires significantly more code. Other handles may
also get unnecessarily inherited as a result, and it would require yet
more code to ensure they don't--it's difficult to ensure that it's
doing exactly what you want. The named event method is much, much
simpler. See for yourself; I've attached the patch written three ways:
a named event (simple), an inherited event passed through the
environment (a bit complicated), and an inherited event passed via the
command line (pretty heinous).

Also, I added multiple daemon support--after another look at the code,
I saw no reason to not include it, though there's still one difference
between the Windows and UNIX implementations: emacsclient can't
provide a name to be used for the daemon when it's starting a new
Emacs (but a user could provide one if they used emacs --daemon=foo).

-- 
|v\ /\ |\ |< |_ /\ \^| //

emacs-windows-daemon-inheritev.patch
Description: Binary data

emacs-windows-daemon-inheritev-cmdline.patch
Description: Binary data

emacs-windows-daemon-namedev.patch
Description: Binary data