Re: A few Windows build fixes

[Eli Zaretskii]

> From: Stefan Monnier <address@hidden>
> Cc: address@hidden,  address@hidden
> Date: Tue, 06 Sep 2011 23:29:01 -0400
> 
> >> We'd want it to have zero impact to the users who don't use cygwin
> >> (and may not even have it installed), of course.
> > They will never see such file names.
> 
> That can be argued (all file names starting with "/" are potential
> Cygwin names).

I was talking about /cygdrive/x/ file names that should be translated
to x:/ and vice versa.  This must be on the C level, AFAIU.

The "mounted" file names, if we want or need to support them, will
have to be looked up in the mount list taken from "mount -m".  But I'm
not sure we need this, as /cygdrive/x/ should be sufficient.  However,
I don't use Cygwin, so maybe I'm missing some important use cases that
do need this.

> But the issue I was referring to is that we want the
> Emacs executable to work even if Cygwin is not available, so either we
> have to re-implement the Cygwin file-name translation (as is partly done
> in cygwin-mount) or we have to dyn-load the Cygwin run-time
> when available.

I don't see how the fact that Cygwin is or isn't installed is related
to implementing the translation, except that "mount -m" will fail if
Cygwin is not installed.  We can use this failure to disable
translation, or we can translate /cygdrive/x/ anyway, because it is
unlikely that a random w32 user will have a real /cygdrive/x/
directory on her disk.

Loading the Cygwin DLL into a native w32 process is impossible, so
that's not an option.

> I thought we still had problems delivering signals to them.

You are right, we don't support sending Posix signals to Cygwin
programs.  But where is that a real problem?  Emacs does know how to
interrupt a subprocess, and the way it does that should work with
Cygwin programs as well, albeit with less flexibility.  After all,
Cygwin programs are just specialized Windows applications.