Brian Inglis writes:
>> It would be easier to review if you would split it up into smaller patches,
>> each
>> doing one thing, to the extent that this makes sense. For example, the
>> simplification achieved by using the ftcprint macro could be done in a
>> single
>> patch that's separate
Brian Inglis writes:
> For informal comparison, attached are Cygwin, WSL, and test release cpuinfo
> output, with diffs against the test release output, and the Windows registry
> CentralProcessor dump (be careful not to double click on Windows
> systems!)
The easiest way to prevent that problem
Jon Turney writes:
> 'run' is used by the start menu item which starts the X server.
>
> If that doesn't use it, a visible console window is created for the
> bash process it starts (which is the parent of the X server process
> and lives for it's lifetime).
>
> (As a separate issue, I'm not sure
Ken Brown via Cygwin-patches writes:
> If the unfinished business consists of local commits that haven't yet
> been applied upstream, then I typically do the following:
>
> git fetch # Find out if upstream has changed since my last pull. If so...
> git format-patch -n # save n local commits
>
Takashi Yano writes:
>> After noticing that we enumerate all the processes (which is an expensive
>> operation) just to skip all of the non-Cygwin ones anyway, I wonder if it
>> wouldn't be smarter to go through the internal list of cygpids and take it
>> from there, skipping the
Corinna Vinschen writes:
> Right you are. We always said that independent Cygwin installations
> are supposed to *stay* independent.
>
> Keep in mind that they don't share the same shared objects in the native
> NT namespace and they don't know of each other. It's not only the
> process table
