Daniel Colascione wrote:
On 10/15/2016 12:23 AM, L. A. Walsh wrote:

Daniel Colascione wrote:
One such case is Cygwin --- I'm not sure how "contrived" it is. Cygwin
has an old-fashioned non-COW fork, and to add insult to injury,
process creation generally is very slow (~100ms). It pays to eliminate
subshells in that environment.
Given what Cygwin has to work around in Windows -- it is very contrived.

Maybe the internals. From the perspective of programs like bash, Cygwin is a mostly ordinary POSIX environment, one with lots of users and that deserves full support.
   Oh?  It's a hack to bring POSIX-like functionality to allow for programs
and scripts to be run on a Windows machine. FWIW, I've used it for about 15+
years.  I use almost identical bash-login+startup scripts on my windows
box as I do on my Linux box.  The scripts do check if they are running
on cygwin and define a function for later ease-of-use:

 if ! type -f cygwin 2>/dev/null ; then
   read SYSTEM_KERNEL HOSTNAME OSTYPE <<<"$($_prg_uname -sno)"
   if [[ $OSTYPE =~ Cygwin ]]; then cygwin () { return 0; }
   else cygwin () { return 1; }
   export -f cygwin

Later I use 'cygwin' to setup a proxy for my winhost and read a few
win/cygwin specific aliases in (like mklink):

if cygwin ; then
 source /etc/local/cygwin/aliases.sh

MS has copy-on-write available to MS processes, that it's not usable in
Cygwin isn't surprising given that most of Windows is closed-source.

It has nothing to do with being closed source and everything to do with the win32 subsystem (under which Cygwin runs) not being designed to cope with process duplication.
I'm fairly sure that the win32 API is insufficient for emulating the POSIX
environment and that cygwin uses other Windows NT calls to get its job done.
CoW is available in the NT-kernel, but since windows processes don't
"fork" (they issues a request to a process-spawner to create a new process --
an expensive and clumsy task (windows has a high overhead for creating
new processes, but last I saw any statistics (some time ago), it was
faster in creating new threads compared to linux.
That's partly due to linux not having threads as a separate kernel object,
but emulating them via processes.  I.e. - a linux thread is, _basically_,
another process (though, *very* slightly lighter weight) with more common
areas shared with the parent processes than a normal fork call would share.

The fact that cygwin has done so much is a testament to the teams hard
work at looking under the covers of the closed-source OS, since much of
what they need to do, not only isn't part of the Win32 API, but isn't
officially published by MS anywhere.

But if you really want bash on your windows, use a native copy.  It's
not as likely to have the same problems

It doesn't do the same thing. Cygwin is an integrated POSIXish environment.
Nothing ever does the exact same thing as anything else -- even itself. However, if you look at the pics it shows the drives mounted under a directory
(they used /mnt) just like in cygwin (which uses /cygwin by default), but I
find better integration twixt cygwin & windows by using '/' as my prefix-dir,
putting my drives at /c, /d, /s ... and my bin+lib dirs @ /bin and /lib on

Also the MS-bash instance is running in the same file-system namespace as
Windows.  A directory listing of /mnt/c shows a permission denied error for
a few Admin-only files, and then shows the normal C:-drive root contents.

And just like in cygwin, they use '/' as the file-separator (since NT can use
either).  Note, the article says this:

 While Microsoft pitches this feature as “Bash shell” environment, it’s
 actually an underlying compatibility layer that allows you to run Linux
 software on Windows. That means you can run other shells instead of Bash,
 if you prefer them.
I.e. MS's bash will run on a compatibility layer -- just like bash running
under cygwin.

Apparently there is a Windows Subsystem for Linux that is currently in Beta
for Win10:

SFU and similar do not interact with the win32 subsystem as closely as Cygwin and so can't provide the same experience. IMHO, you might as well run a VM.
   SFU is no longer available -- and this is not using that subsystem.
BTW -- to respond to this statement:

Daniel Colascione wrote:
It pays to eliminate subshells in that environment.
   You really want bash to function differently on cygwin than it does on
any other platform? Or, you would really suggest that bash re-architect itself
on all platforms to support it running on cygwin, when, at the same time,
MS is bringing their own version of bash to windows?  That seems like
a very risky proposition with little to no payout.  There's no
guarantee that cygwin will run on Windows 11 or 12, or that you will even be
allowed to load your own SW when MS requires Secureboot for all MSWin-logo

But if you have enough funds to donate to the project, who knows, you might
be able to change their mind...

They also, usually welcome well-thought out patches or contributions to their code -- so if it is something you really want, you might consider
offering patches to bash and/or cygwin...


Reply via email to